Sign in to follow this  
mastermind04

starting a game

Recommended Posts

I am having trouble comprehending how to actually start coding a game. I am reading beginning c++ game programming and i understand pretty much everything alright, but it's hard to see how one would start programming a game like what to actually do first. So any light would be appreciated.

Share this post


Link to post
Share on other sites
Before you start coding, write your ideas down. Thinking your project through will make programming a lot easier later on. Also, try to get something running right away, if you see your game running in front of you and ou can play it, it gives you a lot of motivation to continue. I typically write the resource management (sprites, textures , levels, etc) code first so that when I get some graphics running I have something to display, but thats just a personal preference. Also, just to let you know, it will probably take you a couple of projects before you really start to get the hang of it , so dont get discouraged. Good Luck on you projects, and welcome to Gamedev!

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Old carpenters rule of thumb: Measure twice, Cut once.

You start with design. Figure out what you want the game to be (if its your first, make it something simple).

Research ways of how the program would do what is needed.

Use existing resources if possible, APIs, Libraries, Tools for game data.

Start coding. Get parts actually running in stages (helps motivate you if you see actual progress). Get basic features running and elaborate on them later.

Share this post


Link to post
Share on other sites
Hey, mastermind04! On behalf of everyone here, welcome aboard! The first question you should ask yourself is: do you have a grasp on programming such that you can code your own projects from scratch? You could, for instance, code some text-based games and see how that turns out.

After that you must decide on what platform your games will be playable. Your options are Win32 / DirectX, Win32 / DirectX / OpenGL, SDL / OpenGL and other choices too. If I were a starter, I would go for the last combination I mentioned there. Try to get a handle on SDL (the basics like window management and input) - it's pretty simple and intuitive, you'll see. Then when you are ready to try 3D graphics, move to OpenGL and be amazed at all the brilliant stuff you will begin to churn out! Check out NeHe's tutorials. After that, you will need to sort out other avenues such as sound and storylines.

It sounds like a lot, and I won't say it isn't either. Just start, and encourage yourself to keep going. If you have trouble, you'll know where to post for help!

Share this post


Link to post
Share on other sites
Design is always key but you have to have a good understanding of the language you want to make the game in. You mentioned the book beginning c++ game programming. That is a great book and you should keep all the info that it gives. Learn the basics like pointers, arrays, and vectors. You might not think you will need it, but you will.
As stated above, SDL would be a nice place if you want to start programming graphics using c++. Cone3D has some great tutorials aimed at beginners. Good luck on the game programming.

Share this post


Link to post
Share on other sites
Well everyone does things a little bit differently, but I'll give a quick rundown of what normally works for me:

1. Pick your target platform. Will the game be for PC, or for some other piece of hardware, and what OS(es) would you like to support.

2. Write down a very loose overview of your game in dot-point form (or whatever best works for you - the point is to have a quick and rough but descriptive summary). I like to use a whiteboard for this, other people use notepads, or jot it down in a text-editor. What sort of game will it be, and what are the very important features. Details are unimportant at this stage, you just want the big picture. An example might look like:
- Platform Scroller
- Ninjas
- Multiplay

Now, that example is very simple, and you'll probably have a few points, but I think you get the idea.

3. Figure out what sort of features you'll need to include what's listed in step 2. Using the example above again, you can immediately tell that you'll probably want some kind of tiling engine and that you'll need networking. Write down what you figure out in this step.

4a. Look at libraries/APIs/languages (if you know more than 1) or even potential engines that will suit your needs. Decide if you want to use an existing engine, and find it, otherwise you're picking the language, libraries and APIs you'll want to use.

4b. If you don't know how to use a library/langauge/API/engine that you chose in the previous step, take a little time to familarise yourself with it.

5. Start coding. Get a window on screen, and get some kind of placeholder character in there. Get basic keyboard (and mouse if you like) handling implemented, and do anything that's neccesary for all programs on your chosen platform (such as handling window messages in C++ on windows).

6. Implement something that's pretty basic and very crucial. In a 2d game this for me will normally be either a tiling system or some other kind of terrain system.

Build from there. Think about what you want as you design things. Constantly write down notes about what you're trying to do and how you think it needs to be done. Try to design things so that they'll work well with whatever else you're planning to use.

Other people like to do more design first, and others still prefer to just get to the basic coding immediately. You'll have to figure out what works well for you, but I do recommend making at least basic notes on your design, especially as things get more complicated. As you get some practice, you'll get better at coming up with good designs the first try, but expect to do plenty of re-writes at first to make things work well - this isn't a bad thing, it teaches you a lot, and means you end up with a high quality product.

Oh, and do think about using existing engines and/or libraries where possible, it's usually more productive once you get good at it, unless you really want to do things yourself.

Hope that helps. [smile]

Share this post


Link to post
Share on other sites
Thanks all for your replies, i'm wondering again (sorry do this a lot), when i start coding say i'm doing a game about oh let's see like a simple game like the old zelda game for example, i just threw that out there, how would i begin the actual coding process?

AIM - Lilhavs, i know it's faster to explain that way

Share this post


Link to post
Share on other sites
Quote:
Original post by mastermind04
Thanks all for your replies, i'm wondering again (sorry do this a lot), when i start coding say i'm doing a game about oh let's see like a simple game like the old zelda game for example, i just threw that out there, how would i begin the actual coding process?


Well, normally what I'd do is I'd write the main() function, and make sure that my compiler is set up right. Then, I'd compile it just to make sure that it works. Then, I'd probably write a wrapper class for SDL video (I use SDL a lot), which does things like plot pixels, blit stuff, etc. Then, I'd write a simple test demo (still using my main project) that plots pixels and blits stuff. Then, I'd write a tile class and a map class, and get those working and being displayed. Then I'd do characters, and take it from there.

Share this post


Link to post
Share on other sites
Really, you should start making outlines and plans for the game and fully decide, develop and agree on what it will bring to the user.

From there you can start thinking about code and I'd then recommend breaking things down as simply as possible before you start writing the script. By this I mean identifying the functions you will use and what they will perform and so on. From there I would start putting in the script.

It's hard to say though because I'm not sure if this game will be text-based, graphical, using a lot of click buttons and so on, which would also effect the best way to go around making the game. For example, a game that I'm looking to make it a football management game. There will be a lot of button and user interactivity through mouse clicking. I'm therefore going to sort the design of the game out first and then code what the program is to do if buttonA is clicked.

I hope this helps.

Share this post


Link to post
Share on other sites
Quote:
Original post by mastermind04
what i would really like is for someone to show me some code of a game already made, i think that would help a lot..if anyone could


I'm releasing the source code of my 4e4 project along with my project, so once that's out you'll be able to see how to implement tile graphics, maps, etc. Of course, since it's an RTS it may not apply to you (you said you wanted to do a Zelda game), but using the same techniques my game uses you could write a simple Diablo clone.

Share this post


Link to post
Share on other sites
WoW!!using your technique applied to you game will able to make a diablo clone?I was wondering diablo 1 or 2?If you are releasing it,I would like to have sort alike article about your game to be post on gamedev,even that actually everyone could learn from your technique.Hope to hear from that stuff you will be releasing soon.!!

commy

Share this post


Link to post
Share on other sites
Ok, I'm no expert on this, but I do have a *little* bit of experience making games.
I use SDL and found bothe the Cone3D and Sol's SDL tutorial very helpful.
What I do first is get something on the screen. I'd just stick to basic 2d stuff for now, especially if its for a Zelda or Diablo clone, 3d isn't necessary for those games. So what you should do is just get an image loaded onto the screen that you can move around with, say, the keyboard. Thats always a good start. If youre going to use a grid type system for movement(like the first Zelda game), program that out first too. Then just add stuff onto it. Make some blocks that you can't move through, add some randomly moving enemies, make the enemies move intelligently, add a health bar-type thing, etc. Pretty soon you'll have the start of a game. Just make sure to write it well. Messy code is BAD(and hard to fix)!! Not that my code isn't messy...

For some source code of games, well you can check out my two games and the example games in both of the afformentioned tutorials. I can't remember the URls for the tutorial, but just google for them and you should find them pretty easily. My games are both at web.meganet.net/dbrooks I warn you though, I'm not an experienced game writer so my code is not, shall I say, ideal to copy off from. Red Tides should be an especially good game for a beginer to look at, as it is incredible simple.

Good luck with your game,
-Ezbez

Share this post


Link to post
Share on other sites
Quote:
Original post by commy2005
WoW!!using your technique applied to you game will able to make a diablo clone?I was wondering diablo 1 or 2?If you are releasing it,I would like to have sort alike article about your game to be post on gamedev,even that actually everyone could learn from your technique.Hope to hear from that stuff you will be releasing soon.!!


The engine itself is very simple, all that you would need to do would be to replace the graphics to make it isometric (it's top-down for my game). The characters can move in 8 directions, but that could be changed to 16 quite easily after a few changes to the animation code (which isn't particularly long, only about 100 lines of code total). And yes, I am planning to write an article on the subject, probably as a post-mortem more than anything. I'll probably also clean up the engine quite a bit and release that as well. I was planning to anyway, but this gives me a better reason than I had before.

Actually, I'll probably start writing a series of tutorials that walk you through writing my game, which is an RTS, but you could take the engine and use it to make a Diablo clone with some revision of the code. Understand, you won't be able to use the existing code to make Diablo without SOME code revision, but it would be easier than starting out from scratch. I'll probably work on the tutorials in between working on the game and playing other games [grin]. I'll release the tutorials with the source code so you can see exactly how it was developed, and maybe I'll send it in to the GDNet articles place.

[Edited by - Oberon_Command on July 12, 2005 11:38:18 AM]

Share this post


Link to post
Share on other sites
When I wrote my first game I made a console-app( command-line program, that is! ) based on a RPG AD&D style book( it was R.Talsorian's Bubblegum Crisis game).

I didn't have to worry about graphics an'all, just simple text menus. With simple stats and a random-number-generator, I was good to go.

Its funny, but when I look back at it( I've wrote at least three directx games since ) that simple console-app was the best one I had ever done - and without a doubt the most enjoyable. Here's some rules I went by...

1) How do you expect the game to play? For my game I had three sections; Selecting a location, doing something at a selected location and a turn-based battle sequences. I thought about how these three element would be linked together to form the basic programming structure and went from there...

2) Ditch anything that made the game too slow( in the gameplay sense - gamers hate waiting for the game to get to the "meat & potatoes"...) or too complex( its your first game, dammit!). Save the flashy features for another day...

3) When you hit a bug or something difficult - don't freak out! Take a 15min break and then take a look at the problem. Write down what the bug is and then look it up in the books. Take your time and don't be impatient. If all else fails - post on Gamedev.

4) Never let the storyline get in the way of good game design! If a certain piece of the plot is proving too much hassle to implement in the game - nuke it or just display some text as to what has happened. In a few years down the line and you're a professional programmer - you ain't gonna lose sleep over it!

5) If you find the work load over-whelming, don't give up. Just do a simple job such as cleaning up your commenting or writing a small, but useful function. Better to do something than nothing at all!

6) You are going to make mistakes. You are going to bang your head on the wall. You are going to cry. But just remember that five years down the line, you'll find that you'll be here saying "Gawd - I remember when I first made my first game...I made so many cock-ups, but I learned a helva lot!"... ^_^

Best of luck, mate!

Share this post


Link to post
Share on other sites
Hey,
I am about to start my very first game and that helped me. I know I am going to be fustrated and everything. I am ready for them! My saying is....."I will never give up damnit!" Everything you say I was going to follow. TAke breaks. YES! I do that alot in creating programs.

My first game is also going to be a text game. It will be a text based wrestling game.


Anyways,
I am gonna get started on it. I just wanted to read some post before I tackle something hard! I hope I come out alive! lol.

Chad

Share this post


Link to post
Share on other sites
I've read through this post multiple times, and each time I read I end up with the same question in my mind.

mastermind04, What exactly is your experience in making games up to this point? Have you any experience in programming? If so, how much?

For us to completely help with your problem, we need to know where you are at. Anyway, it seems to me that a Zelda game should probably not be your best choice right now.

Share this post


Link to post
Share on other sites
Ok, now I and the rest of these people, can properly recommend what you should do. You should really start out by trying to make a text game of some sort. That way you can become familiar with the language. After that try and tackle some sort of remake of a classic arcade game of your choice.

EXAMPLE:

#include <iostream>
#inlcude <stdlib.h>

using namespace std;

int main() {
char* b;
char a;
do {
cout << "Enter your name..." << endl;
cin >> b;
cout << "Your name is: " << b << endl;
cout << "Press q to quit..." << endl;
cin >> a;
} while(a!='q');

return 0;
}

Share this post


Link to post
Share on other sites
I suck at programming, so don't blame me for anything I say here:

Do you understand the Game Loop concept? Basically, as I understand it, you have an infinite loop while(1) and then in the loop you have your game fuction routine thingies, like getInput(); setPositions(); draw();, and then those functions repeat themselves until getInput() calls a break or a return or something.
I would suggest you check out this site. They have some really good examples, and if you want to move on to graphics in the future, they have some good beginner Allegro tutorials.
Good luck to ye.

Share this post


Link to post
Share on other sites
I want to add my two cents to this. I'm still kinda a beginner, but I'm now developing a 3D game complete with networking and all those nifty features, a far cry from the first game I made, PACMAN in DOS!

I will guide you from an absolute beginner to an experienced beginner, if you choose to accept the mission.

First of all, get a basic understanding of functions, classes, ability to put classes and functions in seperate files (I just had problems with this, but was able to solve it!) Those are vital to games.

Then learn how to use breakpoints and debugging features, take a day or two to practice it. It's very helpful in locating those troublesome pointers or data or whatever's plaguing your game.

Now with basics of programming mastered (you don't need to master all of the language), you're ready for your first console game/application!

My teacher made me make a few business programs in DOS, they're simple, such as storing employees' info, or calculating leap years, etc. That helped in the beginning. You can do likewise.

Then after all those is done, you should be beginning to feel confident in your skills as a programmer. Remember this VERY important tip: You learn as you go. I still don't know how to program templates, namespaces, linked list (not too good at that one), etc. But when the need arises, I take the time to study those, then apply it in my program. That's one reason why many people here fail to make a game, they focus too much on learning and applying neat features in their engines, they fail to focus on the game. They should have focused on the game, THEN add features to engine as NEEDED.

So, with those advices in mind, make a simple PACMAN game, Tetris, Pong, whatever, in DOS. Learn how to position text on the screen so that you achieve a semi-graphic look with characters. This will help you when you step into the 2D programming field. Once you've finished a game like this, make a more complex game, but still in DOS. By now you should be a master of DOS game programming.

Then the next step is to learn how to program in Windows. I'm not talking about DirectX, OpenGl or anything. Just windows. Learn how to make a window box, how to manipulate the color of background, display text, etc. This will assist you greatly, as you will learn more about pointers and how to handle with APIs (DOS doesn't really have anything between you and the screen, you have direct control.) Maybe learn how to use Windows method to blit a picture to the window. If you want, you could make a simple game in this, before proceeding to DirectX or OpenGl world. You should be compentent at debugging and finding answers to your questions by then.

Now, the next step is to decide whether you want to use DirectX or OpenGl. I'm not going to discuss the differences, just pick one. It tend to happen when you learn one, you can learn another quickly, since both have similar methods and functions.

At this stage, you could try and clone a simple NES/SNES game like Zelda, Final Fantasy, etc. Or make a simple sidescroller like Mario Bros.

Once you've mastered the 2D part of game programming (including physics), you're ready to step into the 3D world.

I admit the game I'm working on is actually 3D in 2D, meaning there's 3D models, but all on 2D platform. I havn't started on FPS or 3D world yet. I'm not ready for that yet.

I hope this helped. I wish you the best of luck, I was once like you, and I can see a lot of potential in you. Go, do your best!

Share this post


Link to post
Share on other sites
Zeraan, I have to disagree. I decided to learn Windows programming before I learned Allegro or SDL. So I get a book, sit down, open it up, and was totally confused. It's hell. Don't frustrate yourself needlessly yet. I would learn Allegro or SDL first, and take care of the Windows stuff later.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Most of the windows stuff isn't necessary for game programming, and very useful things like multi-threading are often just a few pages at the end of a windows programming book. So I would recommend to skip the windows part and begin coding a game if you have experience with C. That way you can learn / will learn only the things you really need as a game programmer.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this