Getting Started*Programing phase*
by Andrew · in General Discussion · 04/30/2004 (6:44 pm) · 7 replies
Hello again...I am familiar with the design of business applications and such...but I like to have more information on the layout of a Game.( as far as programing) Is there any particular area of the game that you recomend coding first... for example the main user interface..or should I start with the individual classes. I was tought previously that the traditional approach to writing large programs such as a game, would consist of writing indiviual classes for things such as character creation and such...and divide these classes into individual modules at which u can test and debugg. Im wondering if I should take a different approach i coding my RPG, or expand on the traditional approach.
Thanks for your input,
Phoenix117
p.s- if you have any information/resources that I could use in coding and creating this game world PLEASE feel free to let me know :D.
Thanks for your input,
Phoenix117
p.s- if you have any information/resources that I could use in coding and creating this game world PLEASE feel free to let me know :D.
#2
Go to www-cs-students.stanford.edu/~amitp/gameprog.html and follow his advice on practice games to make. Then make some sort of action game or something. THEN start working on an RPG.
Also, it is usually best to join an experienced team as a sort of helper before you start on some big project (but after you do the easy junk). This way, you can learn from their experience. The hard part is finding an experienced team that needs help. :(
When programming a game, start by doing something that will run. First, write a program that sets the screen resolution (if applicable) and then display a white screen.
Second, make a temporary image for the ground. Have that be drawn on the screen in the same way as it will be drawn in the game. It should be in some sort of "drawScreen" function. Keep everything modular.
Third, make some sort of map file. Optionally, you can make a map editor to make the map files.
Fourth, put an object of some kind in the map. Draw an image for it. Make a "GameObject" class in your program that loads and draws the object. Add code to create the object and draw it. Then run the program so that you can see the object.
Fifth, add the player (have something in the map file or another file to say where the player starts). Make it so that player can move around. Add screen scrolling and things like that if you need them.
Continue working on the CORE parts of the game. By "core", I mean drawing the stuff on the screen, making the player able to move around, and making the Npcs move.
Then start to do less "core" things. For instance, make your game support multiple levels or maps or whatever. Add a status bar if you want to have one in the final game.
Try to do the really hard things that you know you HAVE to do to make the game early on. On the first RPG I tried to make, I kept putting off working on combat and then realized that I couldn't do it the way I wanted to. I never finished that game, though I am now working on vaguely similar game that is already much farther along.
You shouldn't waste time doing things like title screens until you need them so that you can select various options in the game (like game saving or whatever).
05/01/2004 (9:49 am)
Don't make an RPG first. I tried making an RPG without making any games except for some simple puzzle games. It didn't work. There were parts of the game that I just couldn't figure out how to do.Go to www-cs-students.stanford.edu/~amitp/gameprog.html and follow his advice on practice games to make. Then make some sort of action game or something. THEN start working on an RPG.
Also, it is usually best to join an experienced team as a sort of helper before you start on some big project (but after you do the easy junk). This way, you can learn from their experience. The hard part is finding an experienced team that needs help. :(
When programming a game, start by doing something that will run. First, write a program that sets the screen resolution (if applicable) and then display a white screen.
Second, make a temporary image for the ground. Have that be drawn on the screen in the same way as it will be drawn in the game. It should be in some sort of "drawScreen" function. Keep everything modular.
Third, make some sort of map file. Optionally, you can make a map editor to make the map files.
Fourth, put an object of some kind in the map. Draw an image for it. Make a "GameObject" class in your program that loads and draws the object. Add code to create the object and draw it. Then run the program so that you can see the object.
Fifth, add the player (have something in the map file or another file to say where the player starts). Make it so that player can move around. Add screen scrolling and things like that if you need them.
Continue working on the CORE parts of the game. By "core", I mean drawing the stuff on the screen, making the player able to move around, and making the Npcs move.
Then start to do less "core" things. For instance, make your game support multiple levels or maps or whatever. Add a status bar if you want to have one in the final game.
Try to do the really hard things that you know you HAVE to do to make the game early on. On the first RPG I tried to make, I kept putting off working on combat and then realized that I couldn't do it the way I wanted to. I never finished that game, though I am now working on vaguely similar game that is already much farther along.
You shouldn't waste time doing things like title screens until you need them so that you can select various options in the game (like game saving or whatever).
#3
But my advice about programming the "core" parts of the game first is important no matter what you do.
05/01/2004 (9:51 am)
Don't let it get you down when people tell you to do easier games first. We were all told the same thing, ignored it, and then tried to do some huge project and screwed up.But my advice about programming the "core" parts of the game first is important no matter what you do.
#4
You will very very very soon find that making a game is a very much larger project than you thought initially, and you will find it hard to even complete a simple game. Dont give up though!!! Thats how we all started.
(I started by trying to code my own 3d engine to make a Warhammer 40k epic battle game in OpenGL - you might laugh now. It was way over my head)
Oh - and do find a framework to make your game. A 3d engine (like Torque) or some of the SDL frameworks that give you high level IO, gfx, sound, state machines, scene graphs etc.etc.
Good luck!! Dont give up.
05/01/2004 (10:12 am)
Same advice as anyone else. Start small - very much smaller than you would think. Make pacman, frogger, space invaders - anything extremely simple (gameplay wise). You will very very very soon find that making a game is a very much larger project than you thought initially, and you will find it hard to even complete a simple game. Dont give up though!!! Thats how we all started.
(I started by trying to code my own 3d engine to make a Warhammer 40k epic battle game in OpenGL - you might laugh now. It was way over my head)
Oh - and do find a framework to make your game. A 3d engine (like Torque) or some of the SDL frameworks that give you high level IO, gfx, sound, state machines, scene graphs etc.etc.
Good luck!! Dont give up.
#5
Again, start with something simple. Make a fighter, a mage, and a thief. Go with simple stats. Make every attack roll, every defense roll, every damage roll determinable from an ordinary six-sided die. Create a random maze, a MacGuffin to go after, and turn it loose.
If and when you're ready to build a more robust RPG system, don't be afraid to write it out on paper. Don't be afraid to actually game it out with a bunch of friends over pizza and munchies. With the increase of games using pen-and-paper RPG systems, designing a system initially through pen-and-paper doesn't seem like a silly idea at all.
PLAY RPG GAMES! Not just PC-style games. Pen-and-paper, console style games, LARPs, whatever. Immerse yourself in the systems. Learn the strengths and weaknesses of different systems. See what went right and what went wrong.
Whatever you do, DO NOT try to use an existing RPG system license like d20 or GURPS or BESM, at least not without contacting the companies involved. As indies, we lack the clout to get a license for an established and commercially published ruleset. Read the following FAQ to see how much of a practical impossibility it is to do an indie game using the d20 system.
www.wizards.com/default.asp?x=d20/oglfaq/20040123i
Thus speaketh the DM. Roll for initiative.
05/01/2004 (12:33 pm)
I hate to buck the trend, but it is possible to do an RPG at first, PROVIDED you don't expect it to be something as grandiose as Final Fantasy or Neverwinter Nights.Again, start with something simple. Make a fighter, a mage, and a thief. Go with simple stats. Make every attack roll, every defense roll, every damage roll determinable from an ordinary six-sided die. Create a random maze, a MacGuffin to go after, and turn it loose.
If and when you're ready to build a more robust RPG system, don't be afraid to write it out on paper. Don't be afraid to actually game it out with a bunch of friends over pizza and munchies. With the increase of games using pen-and-paper RPG systems, designing a system initially through pen-and-paper doesn't seem like a silly idea at all.
PLAY RPG GAMES! Not just PC-style games. Pen-and-paper, console style games, LARPs, whatever. Immerse yourself in the systems. Learn the strengths and weaknesses of different systems. See what went right and what went wrong.
Whatever you do, DO NOT try to use an existing RPG system license like d20 or GURPS or BESM, at least not without contacting the companies involved. As indies, we lack the clout to get a license for an established and commercially published ruleset. Read the following FAQ to see how much of a practical impossibility it is to do an indie game using the d20 system.
www.wizards.com/default.asp?x=d20/oglfaq/20040123i
Thus speaketh the DM. Roll for initiative.
#6
After doing that, you could gradually expand the game into a more modern RPG.
But I think it would be easier to do some non-RPGs first. With each consecutive project, my code gets a little cleaner, and I have a larger library of useful functions to draw upon. If the code for the Dragon Warrior quality RPG is messy, you'll probably have to rewrite the whole thing before expanding into a modern-looking RPG.
05/02/2004 (5:52 pm)
Well, you could do an RPG of the quality of the original Dragon Warrior or Final Fantasy with no trouble - assuming you've figured out how to put graphics on the screen and play sound already.After doing that, you could gradually expand the game into a more modern RPG.
But I think it would be easier to do some non-RPGs first. With each consecutive project, my code gets a little cleaner, and I have a larger library of useful functions to draw upon. If the code for the Dragon Warrior quality RPG is messy, you'll probably have to rewrite the whole thing before expanding into a modern-looking RPG.
Torque Owner Badguy
eg:
you will need some windowing methods.
some input methods.
and you will need some draw methods.
and you will need some I/O methods.
that will get you started.
if you are past that.
then you should indeed setup the user interface.
creating the overall look and feel of the game is the first step I take.
once that pass's the designer's then I can begin setting functionality to the components.
I would definately Not Start with an RPG. that is insane.
you need to take a Big step Back.
and create a simple simple game.
and use that to explore the beginning of game development.