Programming Language / Development Questions
I'm currently working on a strategy/simulation game, and as development continues on it, I'm finding myself wondering if I'm at a crossroad. Originally, I was developing it in VB6 using basic VB6 forms because of its genre and nature. My thinking was to get some kind of prototype out to finalize my plans and thoughts before I start the "real" development, but as time goes on, I'm finding myself fighting with the various aspects of its development: Visual/Presentation and Multimedia. At this point, I was thinking that I should take a step back and start redoing the presentation layer in DirectX--No experience tho. Using DirectX, I would already have the tools in place to add the audio and network functionality as the project proceeded.
Then, I found myself thinking that if I'm going to re-implement the foundation of my program that I may want to also port it forward to VB.Net. Now, I'm looking into rewriting my game using VB.Net and DirectX--both of which I have little/no experience. Ultimately, I just want to Git 'R Dun, but as the complexity of the project grows, I'm wondering if I'm digging myself into a pit due to VB 6.0** and not something more modern or something specifically designed for game programming. Which leads me to the ultimate debating question:
Should I continue the path to complete my task and revisit the rewrite in the next version--assuming this project is seen to completion--or would I be doing myself a favor now by doing the ugly grunt work of changing architectures for the benefits of easier development/maintenance? I just want to work on my content and not so much on the underlying fundamentals. :sick:
( Heck, would I be better off just dumping $3,000+ USD on a gaming engine license and leave this bare-metal work to the real professionals and just focus on the content development? )
** - I've worked with VB 6.0 in complex business and commercial applications, and I'm not knocking it for performance or usability. I am knocking it since it is becoming a deprecated language.
Re: Programming Language / Development Questions
Normally I would say rewrite it in the next version, but if its really becoming complex, for maintenance and structural issues, port it to .NET now. VB6 really cannot simulate OOP as best some people seem to think it can, and having that in the .NET languages is great (not being a fan of VB.NET I'm pretty sure Inheritance and the like are available in it).
I'm not sure how many games you've made in either language, but let me tell you that maintenance is around 400 times faster in a proper OO language than it would be in VB6.
As for DirectX, it depends. You really haven't said if this is 3D game or not. If it is, go with DirectX, but if its 2D and you port the game to C#, you won't need DX or OGL if you don't want to. The use of pointers through the unsafe code option makes 2D graphics stuff incredibly fast. I've said it before and I'll say it again, never in VB6 would I have been able to "Solarize" a 1900x1600 Digital camera image in < 50ms like I can in C#.
:D
chem
Re: Programming Language / Development Questions
@chemicalNova: Thank you for your response. I'll try to provide some more detail in regards to the issues you have raised.
Maintenance and Structural Issues: While I've tried to keep most functionality out of the forms and in Modules & Classes, there is still enough leakage that I'm having this problem: I'm starting to work on a Game Development Editor to make content creation/editing simpler for my game. In my mind, I could just easily share the Modules across projects, but some of my implementations aren't as clean as they should be. This problem presented me with the thought of rewriting those sections to tighten it up and ensure everything is cleanly separated as much as possible. If I'm rewriting parts of the game, then it led me to think that I should port the game forward to another language that might be more accommodating. Hence, this post.
I guess that I'm only at 25,000 - 35,000 lines of code, and it is already getting troublesome in its structure and maintenance. :(
How Many Games I've Made: 2 MUDs (C and HourGlass), Snakes (VB 6.0), Simple Text-Based Number Guessing/Card Games (Java & C++) This game is many, many, many more times complicated than these games as I'm discovering.
DirectX: The game is only using 2D graphics, but since I'm currently using BitBlt and TransparentBlt to impose images on forms, I'm running into scability issues. Things start getting messy if you resize/minimize/maximize the form which led me to make it a fixed single window, but then you run the risk of too much waste screen real estate to too much data crammed together or spending tons of time working on these technical details/infrastructure and not creating game logic/content.
I was thinking more of DirectX as a way to set a screen mode and make the visual/presentation layer more consistent regardless of resolution. Am I approaching the issue from the wrong angle using DirectX? Would C# allow me to overcome this kind of problem?
(Add. Info)
Graphics: If you are familiar with any KOEI simulation/strategy games (Japanese Gaming Company) on the NES, SNES, then you have seen what kind of game I'm trying to make. In my mind, the graphics and game play would be similar until I get a better grasp of the concepts that I thought I knew. Fortunately, the overall graphics of the project are rudimentary/simple, but unfortunately, getting everything to work in VB 6.0 forms is making me think that it is much harder than it should be? :confused:
Re: Programming Language / Development Questions
Quote:
Originally Posted by Fedhax
@chemicalNova: Thank you for your response. I'll try to provide some more detail in regards to the issues you have raised.
Maintenance and Structural Issues: While I've tried to keep most functionality out of the forms and in Modules & Classes, there is still enough leakage that I'm having this problem: I'm starting to work on a Game Development Editor to make content creation/editing simpler for my game. In my mind, I could just easily share the Modules across projects, but some of my implementations aren't as clean as they should be. This problem presented me with the thought of rewriting those sections to tighten it up and ensure everything is cleanly separated as much as possible. If I'm rewriting parts of the game, then it led me to think that I should port the game forward to another language that might be more accommodating. Hence, this post.
I guess that I'm only at 25,000 - 35,000 lines of code, and it is already getting troublesome in its structure and maintenance. :(
See, a proper OO language would simplify that. Theres really no substitute when it comes to game programming..OOP is a must. You'll probably end up writing less code when structured correctly in an OO language like C#.
Quote:
Originally Posted by Fedhax
How Many Games I've Made: 2 MUDs (C and HourGlass), Snakes (VB 6.0), Simple Text-Based Number Guessing/Card Games (Java & C++) This game is many, many, many more times complicated than these games as I'm discovering.
I think you'll find alot of the theories you'll come up with are alot harder in practise than you thought :p
Quote:
Originally Posted by Fedhax
DirectX: The game is only using 2D graphics, but since I'm currently using BitBlt and TransparentBlt to impose images on forms, I'm running into scability issues. Things start getting messy if you resize/minimize/maximize the form which led me to make it a fixed single window, but then you run the risk of too much waste screen real estate to too much data crammed together or spending tons of time working on these technical details/infrastructure and not creating game logic/content.
I was thinking more of DirectX as a way to set a screen mode and make the visual/presentation layer more consistent regardless of resolution. Am I approaching the issue from the wrong angle using DirectX? Would C# allow me to overcome this kind of problem?
You're looking at alot of memory issues there. TransparentBlt is known to have a few memory issues when used over large amounts of time. From what I can understand, your game has no "outside of the screen" elements? It all takes place in front of the user and thats all? If this is the case, I'd look into creating a proper tile engine, so the game world is alot bigger and more flexible. It may even ease up the CPU usage, where you only draw what needs to be drawn on the screen.
When I mentioned C#, I meant that direct memory editing of the Bitmaps makes it much quicker than using Bit/TransparentBlt. Also, if you wanted to have your game at a certain resolution, its possible to draw to a backbuffer bitmap created at the specified resolution, and stretch it to your liking over your visible area...it'd be pixellated, but would achieve what you wanted..
Quote:
Originally Posted by Fedhax
(Add. Info)
Graphics: If you are familiar with any KOEI simulation/strategy games (Japanese Gaming Company) on the NES, SNES, then you have seen what kind of game I'm trying to make. In my mind, the graphics and game play would be similar until I get a better grasp of the concepts that I thought I knew. Fortunately, the overall graphics of the project are rudimentary/simple, but unfortunately, getting everything to work in VB 6.0 forms is making me think that it is much harder than it should be? :confused:
I'm not familiar with those no :/ It is alot more work (IMO) to get something to work with VB forms than it is in any other language.
To sum up, I would personally switch to a proper OO language, even with that amount of code. With inheritance, virtual methods, etc, you would be looking at reducing the code immensley when structured properly. If you can't grasp the unsafe side of things, using pointers and bitmaps in C#, then I'd definately use DirectX with either C# or C++.
Sorry I can't be of more help :(
chem
Re: Programming Language / Development Questions
Quote:
Originally Posted by chemicalNova
You're looking at alot of memory issues there. TransparentBlt is known to have a few memory issues when used over large amounts of time. From what I can understand, your game has no "outside of the screen" elements? It all takes place in front of the user and thats all? If this is the case, I'd look into creating a proper tile engine, so the game world is alot bigger and more flexible. It may even ease up the CPU usage, where you only draw what needs to be drawn on the screen.
For some strange reason, as soon as I read "tile engine", things started clicking in my head as to what I could be doing in making my life easier. How do you handle the UI aspect of the game? Would it also be tiles that would cover a different layer or a separate part of the presentation layer completely? Either or And?
The current version of the game is strictly "on the screen" because of the nature of VB Forms and the way forms are generally used. I could easily have a use for additional "off screen" real estate, but I didn't have a way to utilize it.
Quote:
Originally Posted by chemicalNova
When I mentioned C#, I meant that direct memory editing of the Bitmaps makes it much quicker than using Bit/TransparentBlt. Also, if you wanted to have your game at a certain resolution, its possible to draw to a backbuffer bitmap created at the specified resolution, and stretch it to your liking over your visible area...it'd be pixellated, but would achieve what you wanted..
Pixelation (sic?) is the least of my concerns when it comes to presentation layer. My primary concern is just having something that will actually work, much less work better. Will C# handle the double buffering if I'm not using DirectX, or will I have to handle those aspects on my end?
Quote:
Originally Posted by chemicalNova
To sum up, I would personally switch to a proper OO language, even with that amount of code. With inheritance, virtual methods, etc, you would be looking at reducing the code immensley when structured properly. If you can't grasp the unsafe side of things, using pointers and bitmaps in C#, then I'd definately use DirectX with either C# or C++.
Time for a quick Pro v Con list: This section almost reads like an Pro-DirectX statement, but I'm not sure that was your intention? :confused:
Quote:
Originally Posted by chemicalNova
Sorry I can't be of more help :(
You're being more than helpful. Get back here! I'm not done with you yet! :bigyello:
Re: Programming Language / Development Questions
Quote:
Originally Posted by Fedhax
For some strange reason, as soon as I read "tile engine", things started clicking in my head as to what I could be doing in making my life easier. How do you handle the UI aspect of the game? Would it also be tiles that would cover a different layer or a separate part of the presentation layer completely? Either or And?
It would be a different layer altogether. It really depends. You could not have it "layered" over the game viewport at all, just have it by itself on the side/bottom/top, etc. But, again, if you wanted it layered over the top, with some kind of transparency, then C# or DirectX is the way to go.
Quote:
Originally Posted by Fedhax
The current version of the game is strictly "on the screen" because of the nature of VB Forms and the way forms are generally used. I could easily have a use for additional "off screen" real estate, but I didn't have a way to utilize it.Pixelation (sic?) is the least of my concerns when it comes to presentation layer. My primary concern is just having something that will actually work, much less work better. Will C# handle the double buffering if I'm not using DirectX, or will I have to handle those aspects on my end?
You will have to handle those aspects on your end, but even then, if you're handling it all through the use of pointers and bitmaps, etc, then you won't have a need for a backbuffer (I haven't actually extensively tested this), as it shouldn't flicker.
Quote:
Originally Posted by Fedhax
Time for a quick Pro v Con list: This section almost reads like an Pro-DirectX statement, but I'm not sure that was your intention? :confused:
To be honest I'm not quite sure. I would personally be going the harder route and trying to get everything I could done with unsafe code...thats just who I am :p But then, I'd also suggest DirectX because it would be alot easier to use, and would also cut your code size alot. It really is upto you to decide, I'm not trying to be bias at all :p
Quote:
Originally Posted by Fedhax
You're being more than helpful. Get back here! I'm not done with you yet! :bigyello:
I'm glad my once useless blabbering is now actually useful to someone :bigyello:
chem
