Sorry your browser is not supported!

I was wondering if anyone would please take the time to tell me or maybe post a link to a site where it will explain how to go about the process of making a basic game. all i really wanna know is how everything goes together this maybe a dumb question but its quite confusing to me..
i dont know excatly how to explain my question but if anyone knows what i mean and knows how to answer i would love to hear from you.
Thanks

code:

Do
Draw stuff to the screen until health runs out or completion()
Loop (go back to Do)

Also, wrong forum

there is no straight answer to this. for the most part we can tell you things not to do and things that are helpful to us. but in the end like most things it ends being what you prefer. (BTW i think this would fit better in the game design section but i'll help you a little)

well for one you need to know what type of game your going to make.
maze, platform, maybe even just a game that you click a button and something happens. that part us up to you to decide.

the next step is to create a story. say your making a game based around a dragon mind controlling a city and you have to fight your way through a mountain and into a volcano dealing with any enemies or traps you encounter.(this was made on the spot)

the next thing is to decide is what era or time frame this game will be set in. will it be medieval fantasy or futuristic si-fi. this will help decide the style of weapons that the player would encounter as its not impossible to find swords in a si-fi game its not as common as guns. like wise in a medieval fantasy style game.

now the next thing is to design the monsters, classes traps, ect.
by this i mean what types of monsters will you encounter in the game will the player be able to select a different class. and what types of traps will there be.

the next is to design a map. this is not difficult this is really just the path the player will take in his journey.

the next is coding everything in. generally this is taken slowly adding each feature in so that it works before placing it around in a map.(coding in the monsters the traps and everything making sure they work properly to the way you want ect.

this may be rearranged in any order but these are some basic steps to making a game. although i suggest keeping the coding to a later step other then maybe a basic engine. just so everything runs.

also felting shadow he doesn't specify a specific coding language.

I've taken to working on the bulk of the game, inside the level editor - so it can be tested straight away, and you get all your issues sorted out in one place. It depends on the type of project, but for a lot of genres this can save a lot of time.

I'm working on a platform beat-em-up called Bruce, as part of a platformer tutorial series in the newsletter. After 11 installments the game is only now being split from the editor, and this took probably less than 1 hour to do.

So I suggest you take a while to decide what sort of game you want to make, don't start on it straight away or it's doomed - let it fester for a bit, let it stew, then if after a few days you still think about it, start work. Game loops, media handling, setup files, particles... it's all scary stuff to the un-initiated, but I cover a lot in the tutorial series, so I suggest reading up on that to get an idea of how things all work together.

I'll just simplify it..

You come up with an idea for a game.

You make a graphic, either 2D in an art package, or 3D in a modelling package.

You put the graphic on the screen.

The graphic has coordinates X/Y and maybe Z in 3D.

You move the graphic around by increasing any of those values.

Moving objects usually meet other objects. This is usually you main gameplay right here. Bat meets ball, spaceship meets missile, Zombie meets bullet, Pacman meets food, or ghost.

So basically a game is an interaction between objects, and the player.

Next you have the game control, which is usually some form of physics, or intelligence, or calculations. The complexity of the game is down to your knowledge of maths. Often the speed of the game is down to the tiniest code that can complete the job.

When everything has moved a tiny bit, and you have checked for collisions, or performed your mathematical sections you update the screen with a sync. This is basically an optical illusion of movement, a sudden change of picture.

Then the game often has an end result. You are dead, you have won, you are home, you have completed a task.

That's about it.

actually, i'd say to do it a different way:

1) Design your game and write it down on paper. Failing to do this will most likely result in a failed project. Trust me, it helps a TON. The more you write down, the easier development becomes.

2)Build a basic game engine using only placeholders. There is no point in making the media now. This is because you may find that you want to change some aspects of your game while you are building the core engine, which often leads to cuts and/or additions of content. Building the game engine has some steps of its own:

A) Deside how your code is going to be broken up and organized. (Ex: you might have functions that handle terrain, player movement, enemy AI, ect.)

B) Program each of these code segments and test regularly. So, at first you may want to get the terrain working, which would mean you have to load it, position/rotate/scale/ect, then explore/test for errors such as holes and such. After this is completed, you move onto the next segment.

C) Debugging/Testing. This step is HUGE. Not only is it incredibly important, it takes a lot of time. During debugging, you want to test every possible outcome of playing your game. Sometimes this requires really out-of-the-box thinking, especially if the game is online (Human players can be very unpredictable). Also, you will want to test your game on multiple computers to ensure that others can play it without incident.

D) Optimization. Even though your game works just fine on your computer, doesn't mean it will on others'. Optimizations can help reduce the amount of work your CPU and GPU do, allowing a wider audience (aka: people with slower computers than you). Optimization may also cover fixing laggy parts of the game that occur do to poor resource management.

3) You've finished the core engine, so now you can work on media. This step is quite large, but I don't really need to break it down too much. Basically, this will encompass: 2D Artwork (like GUI, or if your game is 2D, then just about all visuals will be covered here), 3D Artwork (if your game is 3d, you will need models, textures, shaders, ect), music, sound effects. Also keep in mind that you are going to want to work on media before your project is ready. Don't do this! Changes in your game's design can lead to, as i've already mentioned, cut and/or added content. So, if you made your media first, that means you could be chucking a lot of your hard work away because it no longer fits with the core engine.

4) Tweaks, quick addons, touchups, and polish. Your game is almost done and just needs some sparkle now. This could include: credits, adding extra AI dialog, extra media, ect. Just remember that all of the EXTRA stuff means it is NOT required and that you are adding it just for fun or to make the game a bit longer/more enjoyable. You may also want to go through a few more play tests as well to make sure everything is working as designed.

There you go! A quick and simple guide to making a game. Obviously the specifics are out, but you can probably get those from internet resources and books

I have to disagree about the media thing Jason, for one thing I find that a large chunk of game development is coding the media - animation handling, collision, appearance... I think that a lot of aspects can only be proven once media is in place.

I'm not saying people should make media first of course, but adding media as you go can help keep a project in perspective. Media should be well planned, decide on what you need an object to do before starting on it, and make sure you know how to make the object do what you need. Media creation to the un-initiated can be a project killer, people often bite off more than they can chew with media.

This is really more of a factor with bigger projects, if the project is relatively small then media might just be a secondary concern - but if you start with smaller projects then the whole process or workflow will establish itself. It's a learning process when you start out, and as you get more experienced it's still a learning process, but it quickly becomes more about producing good media in a reasonable time. I couldn't imagine writing a whole game with only stand-in media these days, I'd probably just end up being overwhelmed by the amount of media needed.

It is always a good idea to go over media again when your done though, textures and effects can always be tightened up later once you know the media works in-game.