How to make a game

Pages: 12
May 7, 2011 at 1:51am
Last edited on May 16, 2011 at 10:09pm
May 7, 2011 at 2:35am
this has been needed for a long time :-) kudos for actually getting around to it. im sure theres a large number of aspiring game developers on this forum who need something like this :)
May 7, 2011 at 2:57am
Making graphics and music before you make the engine seems completely backwards to me.

Make the engine first, then fill in media later.
May 7, 2011 at 3:01am
Thanks! Will switch.
May 7, 2011 at 2:22pm
This article is good and will likely be quite useful, but I think that it could use more detail.
May 7, 2011 at 4:54pm
closed account (3hM2Nwbp)
A good start, needs some well formed working examples.
May 7, 2011 at 7:05pm
@chrisname: Agreed, I plan on adding more when I get some time. Just put together this summary for now

@Luc Lieber: examples of what? This is more on the process of what needs to be done to make a game, not how to code a specific type of game.
May 7, 2011 at 7:23pm
man this was fast! I agree with chrisname though it could do with some more detail, first thing that springs to mind is a list of graphics and sound APIs
May 7, 2011 at 7:26pm
graphics and sound APIs

I'm going to get in first and do the good work of suggesting SFML as a prime choice :D
May 7, 2011 at 7:26pm
closed account (3hM2Nwbp)
Games are often very similar in design. You might consider:

*A resource management example with (a/some) popular API(s).
*An example showing ways to get user input (and network input?)
*A game loop that makes use of the OO game structure. All of the examples I've seen so far on any sites are set up in a huge block in a procedural-like way.

This article has the potential to grow into something amazing, as chrisname said, it just needs the details rather than a broad overview.
May 7, 2011 at 9:49pm
Luc Lieber wrote:
All of the examples I've seen so far on any sites are set up in a huge block in a procedural-like way.

What do you mean?
I do it like this:
C# (Game.cs)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
	...
	/**
	 *		Run the game
	 * \return	On success, true is returned. On error, false is
	 *		returned.
	 */
	public static bool MainLoop()
	{
		new LogEntry(String.Format("Game start - Press {0} any time to quit",
					Controls.ToString(Controls.Exit)));
		Game.Running = true;

		while (Game.Running) {
			Game.Window.UseVerticalSync(Game.UseVerticalSync);
			if (Clock.GetElapsedTime() >= 500) {
				Game.FrameRate = Game.FrameCount * 2;
				Game.FrameCount = 0;
				Game.Clock.Reset();
			}

			Game.HandleInputs();
			/*
			 * There's no UpdateObjects() function because that's done in
			 * HandleInputs (this is a spaghetti game engine, the "Game" class
			 * is quite neat and tidy (mostly) but when you get to the internals,
			 * none of it makes sense)
			 */
			Game.UpdateWindow();
			Game.FrameCount++;
		}
		return true;
	}
	....
Last edited on May 7, 2011 at 9:59pm
May 7, 2011 at 10:10pm
I put in a small example of what a game loop is like. I haven't had much time to work on this today. I plan on adding much more though, just not all at once.

EDIT: AAAHHH!!!! My changes weren't saved! uuhh.
Last edited on May 7, 2011 at 10:12pm
May 7, 2011 at 10:52pm
closed account (3hM2Nwbp)
What do you mean?


There aren't many tutorials out there that actually show how concepts are used in an actual game. There are many "dumbed down" tutorials that only show how the API's work, but nothing showing how to neatly tuck the concepts away in a maintainable object oriented unit. It's ultimately up to the game developer to figure out how to do that, but why not have a few examples of this as well?

A few examples of what I mean:

http://irrlicht.sourceforge.net/docu/example007.html <-- Great for learning API, but...
http://www.sfml-dev.org/tutorials/1.6/audio-sound.php <-- Great for learning API, but...
May 7, 2011 at 11:42pm
@Luc Lieber: I know what you mean. I just updated the article, again. It saved this time though, and I made a backup :)

p.s. Only 1100 characters left
May 8, 2011 at 12:01am
I looked at your example game loop and I can't think of a single game I've made which updated every loop. My game loop always goes something like this

1
2
3
4
5
6
7
8
9
long currentTime = clock();
if ( currentTime - m_prevTime > m_tickRate )
{
    UpdateGame(); // update game if one tick has passed
    CheckCollisions(); // also only need to check collisions after movement
    m_prevTime = currentTime;
}

DrawGame(); // but draw as often as possible, to achieve the highest possible fps 


that's missing a lot of stuff like input, but you get my drift, you shouldn't be updating a game every game loop or the speed of the game will depend on how fast your computer is
Last edited on May 8, 2011 at 12:01am
May 8, 2011 at 12:14am
closed account (3hM2Nwbp)
@quirky
I'm not experienced in game design, but isn't there a point at which the frame-rate should be capped so your game isn't eating up the whole CPU? Putting the thread to sleep for X milliseconds per iteration seems like a good idea in my head. X milliseconds changing with how quickly the last frame was displayed to keep a stable FPS.
May 8, 2011 at 12:18am
That's a good point, actually. I never thought of that. Edit: But how do you define the tick rate? What are good values?
Last edited on May 8, 2011 at 12:24am
May 8, 2011 at 12:20am
ah i didnt spot that call to sleep, ok that makes sense, but still it only draws once per update so it doesnt leave room for movement interpolation for example. Whether you want to limit the framerate will also depend on platform i guess.
May 8, 2011 at 12:20am
@quirckyusername: I see what you mean, but if nothing moved, why redraw anything? I could understand if you had some animations running in the background, but as noted, my example is just the basics.
May 8, 2011 at 12:32am
closed account (3hM2Nwbp)
@chrisname
Perhaps a target FPS that the player can select? I don't know what kind of repercussions that might have on a game though.
Pages: 12