quote:Original post by RowanPD You may know some of what I'm about to say but I think I should spell it out anyway.
No, that's good. The reason why I'm asking about these things is because I want to learn, and you've been very helpful so far (thanks).
Re-writing the breakout game from the ground up I suspect might be a good idea, I'll have a think about that one. The reasoning behind our current design for the RPG is for a relatively small project - I don't want it to turn into a huge epic (1000 playable characters lolol!!!11), in fact our storyline's fairly simple (and very linear, for a reason - I don't want to have 300 subplot sidequests going on at once), e.g. we're not using NPCs for more than just talking to - I've had a long think about various projects that I've seen on the net that've just been basically FAR too much for 1 or 2 people to handle. At the moment we have about 3 or 4 programmers (it's an informal arrangement, we aren't a software house or anything, just a group of friends who happen to like making games), who are fairly proficient at what we do (again, I'm under no illusions, we've got a LOT to learn, which is one of the reasons I'm asking so many questions), a graphic artist and a modeller.
As an honest question, is that too big a chunk to start with?
quote: That's why I say to forget the term 'game engine'. Focus on 'game subsystems'. Input, audio, graphics, network, resource management... all of these will be separated from the game itself, and the game will make use of all of them. But I think the most important thing is to keep them independent of each other. It should be possible to rip out one of the subsystems and replace it with an entirely different implementation. As long as you have a clear interface defined, it becomes easy. In essence, this is a game engine, but how you mentally approach the design will truly influence the outcome.
If we were to redesign our breakout game from the ground up, with the idea of these game subsystems, would it be a feasible idea to create the systems (input, sound, graphics, etc), then reuse them along with this RPG I mentioned? Or would it be better to recode them for the breakout clone and then recode them again along with the lessons learned from the first recode? Again, I'm not aiming to create an 'engine' but to be more specific to our game(s).
Again, thanks a lot for the input, I really appreciate it.
quote:Original post by Lessa ... would it be a feasible idea to create the systems (input, sound, graphics, etc), then reuse them along with this RPG I mentioned? Or would it be better to recode them for the breakout clone and then recode them again along with the lessons learned from the first recode? ...
It depends - if you recode them, and they seem like they''re good and usable, then see if they meet the requirements for your RPG, if they do, use them, if not, rewrite. As a trivial example, suppose you wrote your sound system to output 2D audio, and then in your RPG you had a requirement that said 3D audio, it''s obvious that your sound system needs upgrading or rewriting.
Inevitably you''ll probably end up doing upgrades/rewrites because of requirements changes, or because of changes in your thinking (which will happen quite a bit when you''re new to a language or paradigm). You can either fight the urge to rewrite (because it can take lots of time and you might end up doing it a lot) or you can just put in upgrades to systems as necessary, promising yourself "I''ll rewrite this nicely if there is time". If you spend all your time writing and rewriting components no progress is made (this has been the downfall of many programmers and teams, myself included, in the past).
About 2 years ago I decided to program a small turn-based strategy game as a hobby. Starting with no game programming experience I jumped in head first and now, several false starts later, I finally made first-playable. During that time I went to great pains to teach myself OOP largely for the reasons that have been discussed, as my code was always a mess, but I was determined to ''do it right''. Based on what little I learned in that time, some of the comments in this thread contain excellent insights:
1. OOP is not a programming language. While languages like Java and C++ attempt to ''enforce'' good OOP, that doesn''t prevent people from creating hideous designs. OOP is a way of thinking about the design of your code that can be applied, for the most part, to any language.
2. A highly reuseable game engine, or reuse in general for that matter, is not the holy grail, finishing the game is the holy grail. Opportunities for reuse will, however, be more likely to emerge naturally from a good OOP design.
3. Start with what you know. This is critical. I started out knowing very little about game programming and my first attempt was a horrible mess. I tossed it out, bought a book on OOP and started over. From scratch. I had learned enough about programming on the first attempt to understand the basics of OOP, but they say that if all you have is a hammer then everything looks like a nail, and that was the mistake I made with inheritance. I tried to do EVERYTHING with inheritance and my second attempt also quickly turned into a big mess. I tossed it out, bought a book on design patterns and started over. From scratch. I had learned enough about OOP on the second attempt to understand the basics of design patterns and finally, after months of programming the same game over and over, I hit on a code design that I liked and finished the game. Don''t be afraid to jump in and make mistakes, and when it gets ''messy'' don''t be afraid to toss it out and use what you learned to do it better the next time.
4. Design on paper. This is extremely critical. It might sound boring, but if you take the time to sit down and figure out how things work together on paper first, then the code will practically write itself. Not to mention it also serves as a document that clearly describes your thought process behind the code. This is something that isn''t easy to do with comments in the code, and something that will be worth it''s weight in diamonds if you ever have to rework code that you haven''t touched for several months. For my little hobby game I built up a stack of design papers the size of a phone book, a fitting testament to the fact that even small games can quickly become extremely complex.
5. Design by decomposition. This is a highly useful concept and has served me very well. Almost any program (or any THING for that matter) can be defined as a few major components: interface, display, network, etc. And any component can be broken down into sub-components. Components can be developed independently of each other and, using a well defined interface, can be easily ''plugged-in'' to the overall framework of the application. It follows that they can also be ''swapped-out'' at any time as improvements are made, leading to very flexible code and an agile development process, but it''s critical that components have as few dependencies as possible, which leads to:
6. Decouple, decouple, decouple. This is probably the single most valuable lesson I learned from my experience. It is the clear intent behind almost all of the design patterns, and it is at the very foundation of OOP because it is the essential concept behind encapsulation, or ''programming to an interface''. I think the single biggest conceptual breakthrough for me was when I realized that OBJECTS DO NOT WORK TOGETHER. Sound strange? Think about it, if two objects are working together it implies that they know about each other and right away you have a dependency. Change one object and there''s a good chance you will break the other one. After working with design patterns for awhile I eventually realized that the ultimate goal in OOP program design is to create objects that know absolutely nothing about any of the other objects in the program.
The trick is to stop thinking about objects that ''use'' other objects by calling their interface directly. Instead, think about objects that are completely isolated, sitting alone in a dark room. An object knows how to broadcast events by shouting into the dark, and it knows how to listen for events that come out of the dark, from who knows where, but that''s all it knows. When an object hears an event it has everything it needs right there in the room to do it''s thing (including data, helper objects, and sub components), it doesn''t need to know anyting about where the event came from, or from who, it only knows what it''s job is when it hears that event. Sometimes doing it''s thing involves shouting it''s own events out into the dark, but again, the object doesn''t need to know anyting about who, if anybody, is out there listening, it just knows that it''s job is to shout that event out. I have found that this conceptual trick forces me to think through designs that have a very high degree of encapsulation and leads naturally to very flexible, and yes, reuseable code. This concept is the intent behind the ''observer'' and ''mediator'' design patterns.
A slightly less flexible arrangement, but one that arises naturally from designing by decomposition, is to think of programs as offices full of cubicles. Each object toils in it''s little cubicle and doesn''t speak directly to the other objects. Instead, it passes it''s work up to the floor manager who, in turn, decides to either pass the work up to the next level in the heirarchy, or to delegate the work to one of the other cubicles on that floor. This concept is the intent behind the ''composite'' and ''chain of responsibility'' design patterns.
And finally:
7. Seperate content from code. This is a no-brainer and is already widely practiced in the game industry, as evidenced by the mod scene. Game engines are increasingly becoming fancy front-ends to what are essentially content databases.
Good post, a little observer/listener-centric, but good none the less.
For more info on design patterns google for "Thinking in Patterns" by Bruce Eckel. The code is in java but the syntax a really close to c++.
Read other peoples code. You learn alot. There is alot of really horrible code out there (thinking of the freecraft source here). Alot of people have absolutely no clue.
