How do I start ?
Hi!
I'm thinking about writing a remake of an old DOS game. However I haven't played around that much with graphics and sound before. I have basic knowledge of how 3D graphics works (linear algebra, goraud shading etc.). I'm also fairly aquainted with, C++ and Java. The largest projects (in terms of code) I've done before this is a Yahtzee game in Java and some router logic (P-queue, tables + other abstract data types). I was thinking abóut doing the graphics in OpenGL and having SDL for an interface. The game will be in 2D, so maybe OpenGL is overkill ? I want the game to look nice.
Problem is that I'm not sure how to begin. Do I start with the graphics/engine or do I do the "meat" first? I'll probably split it up with a few milestones along the way, but I'm not sure in what order it would be best to do the parts in?
Welcome!
Sounds like you're no stranger to programming, so you don't need to worry about that end. :)
Everyone's got their own take, but I personally believe in getting the graphics up ASAP. If you can visually see things happening, then I believe that you won't give up finishing the game.
In my experience, the quickest path to an uncompleted project is spending oodles of time on the "backend" stuff that you don't see.
I'd recommend just making really small project "targets" that you can hit with almost every compile of the project. Making them small and minute enough, that it feels like you're progressing!
ie.
target 1: get opengl device up
target 2: get text up
target 3: put some simple state mechanics in
target 4: use the text to display which state the game is in (create a "cheat key" to flip through them)..
etc..
Just my 2 cents..hth,
Sounds like you're no stranger to programming, so you don't need to worry about that end. :)
Everyone's got their own take, but I personally believe in getting the graphics up ASAP. If you can visually see things happening, then I believe that you won't give up finishing the game.
In my experience, the quickest path to an uncompleted project is spending oodles of time on the "backend" stuff that you don't see.
I'd recommend just making really small project "targets" that you can hit with almost every compile of the project. Making them small and minute enough, that it feels like you're progressing!
ie.
target 1: get opengl device up
target 2: get text up
target 3: put some simple state mechanics in
target 4: use the text to display which state the game is in (create a "cheat key" to flip through them)..
etc..
Just my 2 cents..hth,
I agree with what TheOther said, Seeing is Believing. If you can see your project coming together then you believe that it will come together.
Also, if your game is something like an RPG that has maps and characters to load, I would reccomend making tools to make your maps and come up with a way to load that into your game. That way you can quickly create better maps and start "seeing" your game come together and it really gets you motivated to finish.
The tools don't really have to be very complex. You might even be able to load in a tiled map from a bitmap and have the pixel information be tile information.
Also, if your game is something like an RPG that has maps and characters to load, I would reccomend making tools to make your maps and come up with a way to load that into your game. That way you can quickly create better maps and start "seeing" your game come together and it really gets you motivated to finish.
The tools don't really have to be very complex. You might even be able to load in a tiled map from a bitmap and have the pixel information be tile information.
Take a look at Photon for a well-designed engine. You can get some ideas for your engine and you might even end up using it for your game.
i will tell you this from a prespective of someone that just trashed his last project , i became very bored every time i needed to add something to the game i would need to put it in the header then in the implemention then in the main game file , it was so frustrating , so try to avoid complex code in your game , what your saying is do you add the "meat" or the Graphics , first things first Graphics is a very vauge word , basic graphics handling is neccessary before starting just to do the basic stuff then you add the real game then make it look sexy so here its
1. Basic Graphics
2. Game Routines
3. Advanced Graphics
First you draw the grenade , you throw it , you blow it up.
and try to write every thing you gonna do in the game down belive me this is really valuable advice, cause at lots of time you wont have any idea on what to next , try as much to avoid complexity it kills projects and most of all HAVE FUN.
1. Basic Graphics
2. Game Routines
3. Advanced Graphics
First you draw the grenade , you throw it , you blow it up.
and try to write every thing you gonna do in the game down belive me this is really valuable advice, cause at lots of time you wont have any idea on what to next , try as much to avoid complexity it kills projects and most of all HAVE FUN.
My two cents...
Id work on the basic engine, Load the images, display the images and play some sounds, then id start to add in some game elements, then add the finishing bells and whistels.
One thing that will help you out in the long run is to plan before coding, that has saved me quite a few times, lay out your engine/game, then code it, it will hopefully prevent the discouraging rewrite of something.
And lastly don't give up, yeah thats cliche.
Id work on the basic engine, Load the images, display the images and play some sounds, then id start to add in some game elements, then add the finishing bells and whistels.
One thing that will help you out in the long run is to plan before coding, that has saved me quite a few times, lay out your engine/game, then code it, it will hopefully prevent the discouraging rewrite of something.
And lastly don't give up, yeah thats cliche.
I agree with Jemburula. Unless your doing some whacky rotations of images or other things that a DOS game probrably didn't use, you'll find it easier to use SDL alone.
You sort of have to compromise between graphics and the 'meat' code. Neither is much use without the other, so you'll just have to do whatever works for you and your project. Starting with graphics is *probably* the way to go, but who knows.
You sort of have to compromise between graphics and the 'meat' code. Neither is much use without the other, so you'll just have to do whatever works for you and your project. Starting with graphics is *probably* the way to go, but who knows.
Quote:Original post by Jemburula
If the game will be 2D why not just use SDL and forget OGL for now?
Mainly because I suck at drawing on the computer and I'm not sure how to do my own art. I didn't know SDL provided graphics. I thought it was more of an interface to the hardware?
Quote:I agree with Jemburula. Unless your doing some whacky rotations of images or other things that a DOS game probrably didn't use, you'll find it easier to use SDL alone.
Not whacky rotations, but I want to create a better looking DOS game with nice explosions and a dynamic terrain. I'm not aiming for something with Oblivion's graphics, but I don't want EGA either ;)
I'm going to look into SDL and the possibilities of it. No point in using OpenGL if I can do the same effects with SDL ;) I want something that's easy on the eyes, not look "old" and can make one go "ooooh nice one!". I'm not sure if it's realistic with my skills, but the whole point is doing something and complete it. I'm doing this for fun and to learn some ropes along the way.
[Edited by - MdaG on January 2, 2006 7:25:04 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement