Jump to content
  • Advertisement
Sign in to follow this  

Your games, Your Development Methods

This topic is 5102 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

Some of you have developed some really awesome games, or are in the middle of developing them, From what ive seen im not too sure if you use engines to help you develop your games, or you write all your code yourself from scratch, Id like to compare them, because im always always ALWAYS stuck inbetween writing an engine for a game and actually writing a game, Ive written simple engines before, mostly half finished ones, and ive written games before. Yet i still havent written a game thats really pleased me..So Im considering using somone elses engine so i can concentrate on the game.

Share this post

Link to post
Share on other sites
Some people will call my method ass-backwards, but it's working for me thus-far:

1) Think about game. Write it down on paper, whatever.

2) Spend some time thinking about features for the game - go all out with this. Mabe about a week or two of just features you'd like to pack into a game.

3) Once that time period is up, stop adding features. Now it's time to modify/remove features from that list, like stuff you know you will not be able to do.

4) Start to outline the engine code. Will you use an existing engine, or build one from scratch?

5) If you're going to build one from scratch, then you'll need to make a list of what the engine needs. In addition to the in-game features you've written down, the engine will need additional features, such as in-game editors (map, etc ...), a file I/O system (loading/saves/modifications), networking, etc ...

6) After you're done writing down what the engine NEEDS, build it. Take a few months and actually build the engine. It's alright if it's buggy. Also, during this time you may think of other ideas you'll want to add to the game. They're probably good ideas, so don't throw them away, write them down, but do not program them, yet. I always put a strict limit on what I can put into my game until I reach my first milestone (a "working" engine).

7) Once you've reached the first milestone, step back from programming the engine, because it's time to think about your game: the story, character/npc interaction, etc ... I know this is really late in the game, but for a novice like me, I usually have a story in my mind already, but since I don't have a studio behind me, I like to look at the engine I have (either bought or created) and decide what it is I can actually do with it, and work the story around the engine (not the other way around, as every book will tell you).

8) Here I'll actually go through the story. More writting. another few weeks of it, too. Then I'll go through the story and write down how I'll make certain stuff happen with the engine (pseudo-code).

9) Programming the actual game goes here. As you can see, it's _really_ late in the process for me, but I feel it's much easier to program a game once everything is behind you. At this point, I program the game with the rough engine, and make sure it's playable the whole way through.

10) This is the step where I'll add little features to the game that were not in the original plan, but were thought up later. This is also the phase where I would take the rough engine and start to smooth it out for public consumption. You may think these are two seperate things, but actually adding small features help to smooth out edges in a game.

There you have it, my 10-step plan for actually building a game, ground up.


Share this post

Link to post
Share on other sites
My method is:
1. Think about what kind of game it is, and what the requirements are.
2. Implement those requirements
3. Hack the game logic on top of step 2.
4. Go to step 3 many times, because of fundamental design flaws (ie. no concrete game design plan).

This is how Eteranl Lands was built, and it shows :D Ok, now it shows less, because I repeated step 4 many times.

Share this post

Link to post
Share on other sites
My method has been thus:

1) Receive partial spec of immediate functional needs
2) Meet some of those needs (currently I'm in a learning phase, so I code from scratch, but in times past I have usually taken at least 5 hours to look for a pre-made solution)
3) Deliver to the other team members, solicit feedback
4) Receive no feedback, so continue to next functionality stack

This style has served me reasonably well in several different projects in different environments, including Unreal engine mods and my current project, a 2d wargame in C# with Managed DirectX. I find early delivery of working code is key, as the designer can usually point out several things which don't work as desired.


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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!