Jump to content
  • Advertisement
Sign in to follow this  
Schwartz86

Help With Game Software Design

This topic is 2369 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am requesting some advice/input as to how I should move forward.

First...a bit of background is necessary. I am currently employed as an entry level software engineer. I work on flight simulators (which are similar in many ways to video games). I am fluent in C++ (as I code in it everyday) though not an expert by any stretch of the imagination. I have been learning game programming as a fun way to test myself and improve upon design skills. Unfortunately, my current position involves mostly following a set of requirements to modify existing code more so than designing new features/systems within our software base. I thought that game design/development would be a fun way to practice some common design patterns and challenge myself. After all, practice makes perfect!

I plan on trying to develop small "simple" games (probably starting off with tetris). From there I would like to move up to a 2D arcade style game similar to Dino Riki for NES (for those who are unfamilar, its similar to a scrolling space shooter). I like the idea of making game "clones" initially as it is very easy to derive requirements and it allows me to get a complete picture as to how the final product should behave.

Below is a list of what I am looking to gain some insight on. If anyone knows of any good books or references that might help I would greatly appreciate it.

1.) Initial design - getting a "good enough" initial design layed out to draw requirements from...creating a good design document...hashing out "enough" of the details before writing a single line of code and determining when this coding should commence

2.) Software structure - choosing/identifying necessary design patterns to use effectively. How to best create objects/classes to allow for neat and maintainable code.

3.) Working/designing larger non-trivial applications from the ground up.... unfortunately, most of the programs outside of work that I have created from scratch have been rather small in scope (probably averaging 1000-2000 lines of code).

4.) Following a project through from start to finish while creating universal code that can be used in other projects.

I realize that experience/practice is a requirement to accomplish most of this, but if anyone has any advice/reading material that might be helpful I would be extremely grateful.

Thanks!

Share this post


Link to post
Share on other sites
Advertisement
[font=arial, verdana, tahoma, sans-serif][size=2]

1.) Initial design - getting a "good enough" initial design layed out to draw requirements from...creating a good design document...hashing out "enough" of the details before writing a single line of code and determining when this coding should commence


For a lot of programming tasks, simply identifying genre is sufficient to get started coding: FPS, third person shooter, MMO, 2D isometric. Just choosing a genre defines pretty solidly a huge majority of programming decisions: rendering, physics, networking, basically everything except for a small amount of gameplay systems. Typically you'll need some kind of fairly complete engine working before you can try out any of the game design ideas and start iterating on the design that separates you from the genre.




2.) Software structure - choosing/identifying necessary design patterns to use effectively. How to best create objects/classes to allow for neat and maintainable code.
[/font]

Small trigger point.... Starting by choosing a design pattern wasn't really the intention of the Design Pattern book [smile] It's a way to talk about things that you've build. But if you are writing an engine from scratch (which almost no one does anymore) there are some fundamental decisions to make: hierarchical object inheritance or a component based architecture, etc.


3.) Working/designing larger non-trivial applications from the ground up.... unfortunately, most of the programs outside of work that I have created from scratch have been rather small in scope (probably averaging 1000-2000 lines of code).


As mentioned above, almost no one writes things from the ground up anymore. There are certainly amazing physics SDKs that you should be using, at the very least (Bullet, PhysX, Havok, whatever). At a higher level there are great complete engines available from which to start: Epic's UDK, Unity, Torque, etc. Definitely look into this if you're interested in "making games, not engines"


4.) Following a project through from start to finish while creating universal code that can be used in other projects.


Ignore anything to do with "creating universal code that can be used in other projects". Focus on completing a game. Once you have you can decide if you want to re-use any of the code. Then and only then, should you consider stripping the old game down into a functional core. After a few game iterations you'll have a nice codebase. Trying to predict how you'll use the code later is a waste of time because (1) it will probably be over-engineered and perform poorly (2) when you're done with it you'll realize ways in which you fundamentally want to rewrite it.

-me

Share this post


Link to post
Share on other sites
Thanks for the response. It seems that your of the opinion I should "just do-it". I think this would be very appropriate for the small projects I mentioned above. However, what about larger projects? I believe my original post was a bit unclear. My plan is to approach these smaller projects in the same way as if I were starting a larger project. (mostly for practice with design) So, while I may be "over-engineering", I would like to get in the habit of thoroughly designing before starting implementation. Perhaps this is the wrong mindset?

Share this post


Link to post
Share on other sites

Perhaps this is the wrong mindset?

Designing before writing code is absolutely not the wrong mindset. But designing software needs quite a lot of practice. The only (or say the best) way to gain that experience is by starting and finishing a project. You can over-engineer as much as you like, but if you get stuck in the software design process and never get to finish the project, you don't have a clue whether your design was workable or not. Anticipated experience gain missing.

So, do exactly as you planned: make a tetris clone, work up the ladder, get experience. There are some great books on the topic, but all of these have one thing in common: they say, "go out and make games - don't just read about it"! Nevertheless recommended reading:

  • Game Engine Architecture by Jason Gregory
  • Game Coding Complete by Mike McShaffry / David Graham
  • Design Patterns by the Gang of Four (already mentioned)


    Some links that might be helpful:

    • Shandy Brownhas a kinda extensive article, giving examples for the use of various design patterns
    • Fabien Sanglard explains the "deep magic", for example with a Doom 3 code review (!)
    • Overview of the C4 Engine, a game engine "highly regarded in the industry for its well-designed architecture". You may want to read the creator Eric Lengyel's post roughly explaining the notation used.
      Edited by Daerst

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!