How many times do you rewrite you game/engine?
Author
When ever I start making a game I usualy just jump into it, little planning. Then I end up with cargame1, cargame2, cargame2, cargamethisistheone folders in my projects folder.
Does anyone else do this or do you stick with the same project or do you just plan it all out first?
I usualy make a new project cause I want to test a peice of code. But then that project has more progress the previous.
Yeah, I have Game and GameWithBatching. I just copied it into a new folder incase I really screwed up, and I could go back to my old code.
I''m an amateur, but everytime I add something to the code I save a copy of the last working version so I have dozens of the old versions of my project.
Let's see, I wrote one in MFC to get an outer space shootemup going in OpenGL.
Then I wrote it again with updated graphics and more effects for both OpenGL and Glide, still with MFC as a base. Two completely separate main program sources, one for each rendering API, with a shared directory with classes that I knew wouldn't change.
From the main sources I determined which parts were the GAME and which parts were the GRAPHICS, and separated Graphics out into commonized function calls. Still in MFC.
Then I started writing an engine without MFC that was attempting to allow the programmer to write their own customized game specific classes for the primary components, and use polymorphism to make their integration in the base classes easy. That version never really got off the ground because I realized there would be at least as many new classes in the game specific stuff as there would be in the base game engine, and the idea of organizing it all was overwhelming. Plus I didn't use STL for the base dynamic storage structures. And there were a LOT of them being used.
You learn a lot doing things on your own. I never really thumbed through a book that illustrates this kind of problem solving. I can design methodologies for handling the mechanics of the game world and the rendering, but when it comes to class design and coding organization, I have more work to do.
[edited by - Waverider on January 25, 2004 9:16:28 PM]
Then I wrote it again with updated graphics and more effects for both OpenGL and Glide, still with MFC as a base. Two completely separate main program sources, one for each rendering API, with a shared directory with classes that I knew wouldn't change.
From the main sources I determined which parts were the GAME and which parts were the GRAPHICS, and separated Graphics out into commonized function calls. Still in MFC.
Then I started writing an engine without MFC that was attempting to allow the programmer to write their own customized game specific classes for the primary components, and use polymorphism to make their integration in the base classes easy. That version never really got off the ground because I realized there would be at least as many new classes in the game specific stuff as there would be in the base game engine, and the idea of organizing it all was overwhelming. Plus I didn't use STL for the base dynamic storage structures. And there were a LOT of them being used.
You learn a lot doing things on your own. I never really thumbed through a book that illustrates this kind of problem solving. I can design methodologies for handling the mechanics of the game world and the rendering, but when it comes to class design and coding organization, I have more work to do.
[edited by - Waverider on January 25, 2004 9:16:28 PM]
Version control was my first thought also, but it sounds like you are suffering from a mild case of "Featurus Creaputus", known as feature creap in lamen''s terms.
You have an initial vision, learn a lot from doing a little of it, and start over with that new found knowledge.
There is nothing wrong with it. You just need to realize that there is more to learn by completing the project.
Set your goals. Make notes of things you learned so you don''t forget them for the next project. Finish your project. Save and burn it for your portfolio.
Writing your design down IS important so you don''t loose focus. If there ever is a time you want to add to that initial design doc, put it in the sequal instead.
You have an initial vision, learn a lot from doing a little of it, and start over with that new found knowledge.
There is nothing wrong with it. You just need to realize that there is more to learn by completing the project.
Set your goals. Make notes of things you learned so you don''t forget them for the next project. Finish your project. Save and burn it for your portfolio.
Writing your design down IS important so you don''t loose focus. If there ever is a time you want to add to that initial design doc, put it in the sequal instead.
I''ve rewritten mine many times, but with each time it gets better.
MindEngine Development
http://medev.sourceforge.net
MindEngine Development
http://medev.sourceforge.net
I''ll probably end up writing your engine a couple of times, but making a design document really cuts down on stupid mistakes, and useless rewrites.
quote:Original post by Taulin
Version control was my first thought also, but it sounds like you are suffering from a mild case of "Featurus Creaputus"
you mean:
"lacuna consisto contineo"
Or:
"Lacunasistotineo"
| C++ Debug Kit :: GameDev Kit :: DirectX Tutorials :: 2D DX Engine | TripleBuffer Software |
| Plug-in Manager :: System Information Class :: D3D9 Hardware Enum | DevMaster :: FlipCode |
You might also benefit from the process of Refactoring. It''s the process of taking badly designed code and making it better. If you find that your engine is going out of control, stop and see how much you can refactor it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
