Best way to start a Tile-Based game?
Alright, after my finished Pong game (6 days with 1000+ lines of code) I''ve decided to move on to some harder stuff. I''ve seen a 2D side scrolling shooter''s code and it seemed too simple, that''s another project I could have blown off in another week. So, I remembered an old NES game I always played (it''s called Zelda, ever hear of it? :D) and I thought to myself, hey, it would be cool to have a game like that but with guns instead of swords and other stuff since it''s already been done.
So, my question to you - the community of GameDev.net, what would be the best way to approach this? I am quite proficient in C/C++ and I''ve got the SDL documentation on my hard drive in my E-Books folder.
I looked through the Isometric & Tile Based Games part in the Articles and Resources section and found nothing that would have been of use to me. I haven''t looked through Google yet, I plan on doing that tomorrow but I figured here would be my best bet.
Who knows, maybe I''ll be making a topic in the Help Wanted forum if I ever need some extra help creating this, hopefully, to be work of art.
R.I.P. Mark Osback
Solo Pa Mi Gente
VG-Force
Ekim Gram Productions
I can see that your joking but I''m really serious. I really should have mentioned that Pong isn''t the only project I''ve done. I''ve worked with a few teams but Pong the only project I''ve done alone, mind you. ''sides, with everybody else working on MMO''s, my idea would probably used already
R.I.P. Mark Osback
Solo Pa Mi Gente
VG-Force
Ekim Gram Productions
R.I.P. Mark Osback
Solo Pa Mi Gente
VG-Force
Ekim Gram Productions
just a few ideas,
if you are serious of stepping up your games, a good design document is a necessity. Something that will give you a clear and concise idea about the game, gives you focus. A pong is easy, because the design is simple, but for a Zelda game, or even a shoot''em up, that''s a different story. I''m no game designer (hell, haven''t seen a design doc in ages, that''s what I hate mostly about my job), but for example, and in no order,
what it''s story is,
a complete script of the story, main characters and their interactions, quests,
characters design,
playable charaters,
non playable character (NPC),
their behaviour,
AI,
scripts,
game flow,
interaction with the environment,
interaction with NPCs and enemies,
interaction with the user,
menus,
weapons,
environment, variety of environment, their design,
buildings and cities,
multiplayer aspect supported? On several machines? What''s the network architecture? (Server / Client)?
cooperative mode (for a zelda game, that can be interesting, but bring a LOT of complications),
what''s the competition and their pros/cons,
the graphics and look of the game,
the scale of the game (how populated, size of the world, cities),
the save / load system, automated, at user request, ect...
the sounds and ambience,
special effects,
things that will hook a player to the game and set your game a class apart,
the replayability and minimum completion time of the game,
difficulty settings,
the target audience and target platform,
the graphics and sounds, who''s gonna do them?
design an engine, or use one already made?
scripting language?
very important, level editor, and other editors,
the technicalities of the game, the potential problems, and their solutions,
Object design,
from there, a schedule,
how much time per day can you afford on the game, when you want to finish it, split the work into tasks, assign timetables on tasks, see how long it takes, if takes too long, cut down some aspects, or get some help, maybe get an artist to do the art, because it will double your workload. Set yourself milestone dates for beta releases.
from there, work on a prototype, solve the most important technical and design aspects of the game (storing the world, NPCs, collision detection, interacting with NPCs at a small level), do a small quest on one map, fight NPCs, sounds, graphics and animation (quality more than quantity), interact with them, ect... prove the game can work on a grander scale, ect...
look on the web for design document specifications and examples, and here, on this very website
http://www.gamedev.net/reference/list.asp?categoryid=23
if you are serious of stepping up your games, a good design document is a necessity. Something that will give you a clear and concise idea about the game, gives you focus. A pong is easy, because the design is simple, but for a Zelda game, or even a shoot''em up, that''s a different story. I''m no game designer (hell, haven''t seen a design doc in ages, that''s what I hate mostly about my job), but for example, and in no order,
what it''s story is,
a complete script of the story, main characters and their interactions, quests,
characters design,
playable charaters,
non playable character (NPC),
their behaviour,
AI,
scripts,
game flow,
interaction with the environment,
interaction with NPCs and enemies,
interaction with the user,
menus,
weapons,
environment, variety of environment, their design,
buildings and cities,
multiplayer aspect supported? On several machines? What''s the network architecture? (Server / Client)?
cooperative mode (for a zelda game, that can be interesting, but bring a LOT of complications),
what''s the competition and their pros/cons,
the graphics and look of the game,
the scale of the game (how populated, size of the world, cities),
the save / load system, automated, at user request, ect...
the sounds and ambience,
special effects,
things that will hook a player to the game and set your game a class apart,
the replayability and minimum completion time of the game,
difficulty settings,
the target audience and target platform,
the graphics and sounds, who''s gonna do them?
design an engine, or use one already made?
scripting language?
very important, level editor, and other editors,
the technicalities of the game, the potential problems, and their solutions,
Object design,
from there, a schedule,
how much time per day can you afford on the game, when you want to finish it, split the work into tasks, assign timetables on tasks, see how long it takes, if takes too long, cut down some aspects, or get some help, maybe get an artist to do the art, because it will double your workload. Set yourself milestone dates for beta releases.
from there, work on a prototype, solve the most important technical and design aspects of the game (storing the world, NPCs, collision detection, interacting with NPCs at a small level), do a small quest on one map, fight NPCs, sounds, graphics and animation (quality more than quantity), interact with them, ect... prove the game can work on a grander scale, ect...
look on the web for design document specifications and examples, and here, on this very website
http://www.gamedev.net/reference/list.asp?categoryid=23
Be careful about branding a side-srolling shooter as easy. The difficulty level is entirely dependent upon what sort of goal you set yourself. Furthermore, I''ve started many a project feeling I''d thought it through and believing it to be easy (in theory), only to find some time later that there were many aspects I''d failed to consider fully. So, don''t be too swift to dismiss an idea because you''ve seen some code and think it would be easy. Looking at well-written code can make things seem deceptively easy.
Anyway, having said my part about being cautious it''s good to see someone start with Pong and then carry their enthusiasm onto bigger and better projects. I''d suggest you start by putting together a design document outlining what you''d really like to see in the game. Don''t worry about finding a proper template just write a document that is as clear and concise as possible in detailing every aspect of your game and how it will work. The idea is that someobody else could pick up the docuement and almost make the game from it without having to ask you for details.
How detailed you get is entirely up to you but try to get the core structure and components covered. Once that is taken care of I''d set about putting together a TileEngine to power your masterpiece. Get it reading in map files, displaying tiles, controlling input and entities. As you make progress with that you should start to get an idea of how capable you are of entirely envisaging your idea. At that point either rewrite or revise your document bearing in mind exactly what you feel capable of, after making that prototype.
With that done you can commit to your feature list and either work onwards from the prototype or start a fresh armed with the experience gained from that initial foray into writing a tile-engine.
Hope that is of some use, and best of luck to ya.
Anyway, having said my part about being cautious it''s good to see someone start with Pong and then carry their enthusiasm onto bigger and better projects. I''d suggest you start by putting together a design document outlining what you''d really like to see in the game. Don''t worry about finding a proper template just write a document that is as clear and concise as possible in detailing every aspect of your game and how it will work. The idea is that someobody else could pick up the docuement and almost make the game from it without having to ask you for details.
How detailed you get is entirely up to you but try to get the core structure and components covered. Once that is taken care of I''d set about putting together a TileEngine to power your masterpiece. Get it reading in map files, displaying tiles, controlling input and entities. As you make progress with that you should start to get an idea of how capable you are of entirely envisaging your idea. At that point either rewrite or revise your document bearing in mind exactly what you feel capable of, after making that prototype.
With that done you can commit to your feature list and either work onwards from the prototype or start a fresh armed with the experience gained from that initial foray into writing a tile-engine.
Hope that is of some use, and best of luck to ya.
Get the main thing running, the game.
Display tiles from an (dynamic) array on the screen, preferrably look into possible scrolling (adding an offset). Now draw only the visible tiles on the screen.
Add objects. Display and update objects. Colission between objects. Colission between object and world (simple tilebased-which tile is this object in?, or with colission bitmaps-e.g. slopes).
That ought to have you working for a while. Probably sketch out your source code in simple classes in your head or on paper before.
If you get this up and running you will be a step farther again, and can look to get story or levels into the whole shebang.
Display tiles from an (dynamic) array on the screen, preferrably look into possible scrolling (adding an offset). Now draw only the visible tiles on the screen.
Add objects. Display and update objects. Colission between objects. Colission between object and world (simple tilebased-which tile is this object in?, or with colission bitmaps-e.g. slopes).
That ought to have you working for a while. Probably sketch out your source code in simple classes in your head or on paper before.
If you get this up and running you will be a step farther again, and can look to get story or levels into the whole shebang.
SDl will do just fine.
You can start by classifying everything. Start breaking the bigger problem of "the game" into smaller chunks to tackle. Perhaps the actual tiling engine or level layout would be a good start. If it''s zelda-ish then each area will be a simple rectangle.
Then tackle various other issues including:
animations (even state-based animation trees in the AI forum)
collision detection
level design
enemy AI (harder than you think at times)
However, i would start by sitting down and putting down in writting all the things you want your game to include. With your Pong project, there was no design, you already know the game and are just copying it. Now you''re making something new so you will be actually designing a *game* and not just a computer program.
Another bit of advice is create a roadmap. For a first milestone version, you want features x,y,z complete. For version 0.2, you want another few, etc.
And think about however long you believe it will take and multiply it by x10.
You can start by classifying everything. Start breaking the bigger problem of "the game" into smaller chunks to tackle. Perhaps the actual tiling engine or level layout would be a good start. If it''s zelda-ish then each area will be a simple rectangle.
Then tackle various other issues including:
animations (even state-based animation trees in the AI forum)
collision detection
level design
enemy AI (harder than you think at times)
However, i would start by sitting down and putting down in writting all the things you want your game to include. With your Pong project, there was no design, you already know the game and are just copying it. Now you''re making something new so you will be actually designing a *game* and not just a computer program.
Another bit of advice is create a roadmap. For a first milestone version, you want features x,y,z complete. For version 0.2, you want another few, etc.
And think about however long you believe it will take and multiply it by x10.
*thinks* Holy crap that''s a lot more work than I thought it would be. Since I''m in school right now, I won''t be able to spend a lot of time on it but the summmer...I''m beginning to think it would be a very good idea to put it off till then. I''d be able to work on it a lot more and I''d be able to do everything without rushing and such. Thanks a bunch guys. Once this get''s posted, I''m book marking this thread.
R.I.P. Mark Osback
Solo Pa Mi Gente
VG-Force
Ekim Gram Productions
R.I.P. Mark Osback
Solo Pa Mi Gente
VG-Force
Ekim Gram Productions
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement