Sign in to follow this  
ravinDavin

How to Plan? What to code first?

Recommended Posts

Hi, I'm quite sure this question has been asked before, But I have searched for the last 30 minutes and cannot find anything that answers it.

I want to make a 2D platformer. I am going to use XNA and C#. I am not a new programmer, mainly new to "good" game design.

My questions are this:
How do you create a game, and not get bogged down in the Object Oriented design?
Where do people normally start? What is the best thing to code first?
Should I first get sprites drawn on screen and get them move?
Should I first create a good program flow, which will run the different states before anything else?

When creating classes, When should I stop trying to make it better? I always end up thinking there is a better way to do things, and hence spend hours on 1 class.

I will probably have other questions, but can somebody please attempt to answer these questions?

Share this post


Link to post
Share on other sites
Hi,

Good design is essential to good programming. If you spend some serious time and thought designing your program then all these questions will be irrelevant.
However, if you are not at the level of expertise where you can design things before doing them and you still have a lot to learn about program structure, or you just want to get stuck in and learn as you go along (which I personally highly recommend, as doing is the best way of learning and you have to learn from mistakes as you make them) then I would go with your option of[size="2"][color="#1c2837"] "get sprites drawn on screen and make them move."[/color][/size]
[size="2"][color="#1c2837"]
[/color][/size]
[size="2"][color="#1c2837"]Good luck.[/color][/size]

Share this post


Link to post
Share on other sites
1. First start small and write some working code. Try to develop a 'prototype' of what you want to achieve or at least write a rough equivalent.
2. As for graphics, I think start with level design. Figure out what you levels will look like. And how you will represent your levels - data wise. This is crucial in platform games as they are level based. Try to figure out whether you want simple scrolling or continuous scrolling. Then move to tiles and graphics. Typically levels are made of background and foreground tiles. Think of this aspect.
3. Character design and animation. Create your character or use an existing sprite sheet to chalk out your character animations. This is a creative process and will take long, but of course you can use pre-made graphics to quicken the process.
4. Draw your character on the level. Make your character interact in the level - at this stage you should write code for implementing all the attributes of your character and levels: movement, jumping, falling, walls, obstacles, gravity, and so on.
5. Design your challenges and monsters. Write collision detection code for traps and obstacles in level.
6. Design your monsters. You can even make them "intelligent" and detect your character on screen and attack him. This is usually the trickiest part, but you could make do with writing very "AI" code for monsters (e.g. make them just walk up and down a predefined path and hurt the hero/heroine when he/she hits the monster).
7. Now work on in-game displays, lives, bonuses, artifacts and other goodies the hero must collect in-level. Scoring and so on.
8. Main menu, game saving/loading (if you want) etc. Saving and loading will involve saving the data that represents the current game state.

Hope this is useful to you.

Share this post


Link to post
Share on other sites
[quote name='Monkan' timestamp='1318169951' post='4870800']
Hi,

Good design is essential to good programming. If you spend some serious time and thought designing your program then all these questions will be irrelevant.
However, if you are not at the level of expertise where you can design things before doing them and you still have a lot to learn about program structure, or you just want to get stuck in and learn as you go along (which I personally highly recommend, as doing is the best way of learning and you have to learn from mistakes as you make them) then I would go with your option of[size="2"][color="#1c2837"] "get sprites drawn on screen and make them move."[/color][/size]
[size="2"] [/size]
[size="2"][color="#1c2837"]Good luck.[/color][/size]
[/quote]

I guess figuring out where to start in the design is my main problem lol.

Share this post


Link to post
Share on other sites
[quote name='vharishankar' timestamp='1318170381' post='4870802']
1. First start small and write some working code. Try to develop a 'prototype' of what you want to achieve or at least write a rough equivalent.
2. As for graphics, I think start with level design. Figure out what you levels will look like. And how you will represent your levels - data wise. This is crucial in platform games as they are level based. Try to figure out whether you want simple scrolling or continuous scrolling. Then move to tiles and graphics. Typically levels are made of background and foreground tiles. Think of this aspect.
3. Character design and animation. Create your character or use an existing sprite sheet to chalk out your character animations. This is a creative process and will take long, but of course you can use pre-made graphics to quicken the process.
4. Draw your character on the level. Make your character interact in the level - at this stage you should write code for implementing all the attributes of your character and levels: movement, jumping, falling, walls, obstacles, gravity, and so on.
5. Design your challenges and monsters. Write collision detection code for traps and obstacles in level.
6. Design your monsters. You can even make them "intelligent" and detect your character on screen and attack him. This is usually the trickiest part, but you could make do with writing very "AI" code for monsters (e.g. make them just walk up and down a predefined path and hurt the hero/heroine when he/she hits the monster).
7. Now work on in-game displays, lives, bonuses, artifacts and other goodies the hero must collect in-level. Scoring and so on.
8. Main menu, game saving/loading (if you want) etc. Saving and loading will involve saving the data that represents the current game state.

Hope this is useful to you.
[/quote]

It is useful, but I guess I am just worried that if I create my game in a certain order, I may end up with critical implementations left out until the end, meaning a refactoring of a lot of code.

Share this post


Link to post
Share on other sites
[quote name='ravinDavin' timestamp='1318171140' post='4870808']

It is useful, but I guess I am just worried that if I create my game in a certain order, I may end up with critical implementations left out until the end, meaning a refactoring of a lot of code.
[/quote]

u can not avoid that.. :-) especially not as a newb.. A game is very complex and mostly u just forget about things. If you are new in Game Programming than just start. And don't be afraid of making mistakes.. u will make them.. no matter how good ur planning is

Share this post


Link to post
Share on other sites
there are different approaches

u can write the renderer first and than the game logic.. both as different frameworks and then mix them up

or u write everything at one program..

in general u begin with implementing the basic graphics.. so make sure that u can load sprite sets, display them, move them, make them collide. than u will want to implement controls.. of course only basic but that u will have a function in the end which can be easy modified to your needs.. when this is finished and working u take the next step... means, u load levels from a external file (u may need to write a level editor before that)... when this works fine than u can write the interaction of the player with the level.. its a step by step process and u have to begin by the lowest levels.

My project i am working now is a 2D RPG .. i did no planning and just started off. the first time i encounterd a few problems was when i implemented my own scripting language.. but u always can adjust code until it works.. I learned from the project that planning is quite necessary BUT u can't plan every detail... plans are never working out like they should.. rule #1

Share this post


Link to post
Share on other sites
Everything FlyingDutchman said.
Get stuck in, don't think that your game will be the most optimal, extendable piece of software ever made and start programming. A good way to start is to make some sort of object class which has an update function and a position vector. Inside your main game loop call an update function which calls the update function from all objects in your game which will be stored in some sort of list / array. Draw all these objects using their positions.

Add to this as you see fit.

Don't be afraid to scrap everything and start over when you need to do some serious restructuring, this is inevitable.

x

Share this post


Link to post
Share on other sites
[quote name='ravinDavin' timestamp='1318168719' post='4870792']
Hi, I'm quite sure this question has been asked before, But I have searched for the last 30 minutes and cannot find anything that answers it.

I want to make a 2D platformer. I am going to use XNA and C#. I am not a new programmer, mainly new to "good" game design.

My questions are this:
How do you create a game, and not get bogged down in the Object Oriented design?
Where do people normally start? What is the best thing to code first?
Should I first get sprites drawn on screen and get them move?
Should I first create a good program flow, which will run the different states before anything else?

When creating classes, When should I stop trying to make it better? I always end up thinking there is a better way to do things, and hence spend hours on 1 class.

I will probably have other questions, but can somebody please attempt to answer these questions?
[/quote]

I'm actually in a very similar situation as yourself. I'd keep starting projects, try using OOP and more "advanced" methods of programming, and then scrap the project because I went too far ahead of myself. I've started to get past it as I've progressed in my studies as a programmer, but what I can say is this. You may want to hold off on XNA temporarily, as if you're having trouble understanding how to design applications in general, then having to work on the graphics side of it, handling input logic, drawing, etc., is just adding a lot more complexity and frustration to you. I was trying to work on a 2D game myself, and quit every project I started because I was confusing myself when I started realizing how important designing my classes before implementing them was. I didn't even use Lists because I didn't fully understand them, so I went back and worked on a text-RPG.

I can offer this advice: when you're learning how to design games so that you know how all of your classes interact with each other, simply type on the computer (using Notepad) or write in a notebook what you think you will need in each class. For example -

My Player class will need fields to store their health, mana, strength, toughness, intelligence, wisdom, agility, and gold.
My Player class will need properties to modify their health, mana, strength, toughness, intelligence, wisdom, agility, and gold.
My Player class will need functions to display their inventory, start combat, add items to their inventory.

And this could increase/decrease depending on the complexity of your game. When you look at the Player class functions, you notice how there's a function that displays the Player's inventory. Assuming that you create a new class that handles the Inventory, you could create a "has-a" relationship between the Player and Inventory to do this. When you have a simple design laid out before you, the design of your classes seems much less daunting. I wouldn't worry too much on designing the story, the characters, etc., just have a basic foundation for your game so that you don't overburden yourself with all these different classes, interfaces, files, and such. I hope this post provided some insight on getting you started with design.

Share this post


Link to post
Share on other sites
[quote name='ravinDavin' timestamp='1318168719' post='4870792']
My questions are this:
How do you create a game, and not get bogged down in the Object Oriented design?
[/quote]

Experience and careful preparation. Mostly experience though. After a while you realize (almost) everything boils down to a few common patterns.

[quote]
Where do people normally start? What is the best thing to code first?
[/quote]

Error reporting.

[quote]
Should I first get sprites drawn on screen and get them move?
[/quote]

Depends on the game, your general approach, and how you want to/need to work. I personally don't since the hard parts of a game aren't in the rendering.

[quote]
Should I first create a good program flow, which will run the different states before anything else?
[/quote]

Depends on the game, your general approach, and how you want to/need to work. Unless there's a pile of game states and that's vital to success, I wouldn't.

[quote]
When creating classes, When should I stop trying to make it better?
[/quote]

When it's good enough to solve the problem you're currently facing. If you're solving some mysterious future problem, you're making a classic error.

[quote]
It is useful, but I guess I am just worried that if I create my game in a certain order, I may end up with critical implementations left out until the end, meaning a refactoring of a lot of code.
[/quote]

That's why one of the big things to come out of software development methodology recently is to implement the core of your app first. Get [i]something[/i] working ASAP, even if it's ugly, even if it's incomplete or hacked up. You can identify critical issues earlier so that they cost less to fix. Then build incrementally off your working core.

Share this post


Link to post
Share on other sites
I programmed a poker bot for one of my university projects. It could hook onto an online poker client, read the state of the game through a combination of pixel matching and OCR, and then used ANNs and targeted simulations to decide on the best action to take, and then click the appropriate button on screen. It took me about 3 months of programming to get it done.

Once I finished university, I decided to create a newer better poker bot. It was going to be amazing. This version would have a database to store previous hand histories, which could be used to create an individual ANN for each opponent it met, improving the accuracy of the opponent modelling. It would have a bot simulator, where bots could play each other at 500 hands a second, producing a nice graph and all the statistics you could need to see where their weaknesses / strengths were.

I spent the next 3 months designing it all. Classes, databases, all perfectly designed adhering to OO principles.

Then I started coding. Despite all my planning, problems popped up that I hadn't foreseen. No problem though, I'll just do a bit of a redesign. Designs were changed, classes removed, added, amended. Carry on coding. More problems. More redesigns.

In the end I spent more time designing than I did coding. It has been more than a year now, and my poker bot has less than half the functionality that my 3 month uni project had. I don't spend a huge amount of time programming - I have other responsibilities nowadays that I didn't have when I was a student - job, baby etc, but I think the real problem isn't lack of time, it is lack of motivation. I have spent so much time on the project, but have barely anything to show for it.

My advise - don't worry about design very much at all. Have a quick think about how the main parts will work together, and start coding. Dont worry about needing to rewrite code when things go wrong. The most important thing is to get coding and get something working to keep you motivated. Better a working program with terrible source code, than a great design and no program.

Share this post


Link to post
Share on other sites
[color="#2B3730"]Aye, follow [b]vharishankar's [/b]pieces of advice, IMHO it seems to be quite a business-like approach, suitable even for larger projects, where first the skeleton is implemented and details come after.[/color]
[color="#2B3730"]What [b]DaveMS [/b]said is really interesting for me, ending up with so much design work, that motivation flies away...[/color][img]http://public.gamedev.net/public/style_emoticons/default/ohmy.gif[/img]
But the contrary is also true in real-world projects: insufficient design and/ or early implementation mistakes can lead to a super-huge unstable, unimproveable Code mass, which may be running, but also has some unforseen "features". This is how the game-maker tool [url="http://www.scirra.com/"]Scirra's[/url] Construct Classic turned out to be, that's why they now need to code Construct 2 from scratch.

My experience comes. My last summer was spent with a 2d platformer creation and also Python, Pygame learning. The project, possibly similar to yours, was not a big one. I had no planing in mind, just started with moving sprites, then added detectable terrain (platforms), some stone-age level "pathfinding", some collision detection, and so on. One step will invoke the other, it is that easy when dealing with such a small-scale project. This really hadn't required any plan to worry about! I rewrote the OOP structure 1-2 times, but that was part of the learning, just lack of practice, which you still can't plan before with small experience.

[b]so just do it! It's the funny learning time![/b]

Share this post


Link to post
Share on other sites
[quote name='DaveMS' timestamp='1318276731' post='4871185']
I programmed a poker bot for one of my university projects. It could hook onto an online poker client, read the state of the game through a combination of pixel matching and OCR, and then used ANNs and targeted simulations to decide on the best action to take, and then click the appropriate button on screen. It took me about 3 months of programming to get it done.

Once I finished university, I decided to create a newer better poker bot. It was going to be amazing. This version would have a database to store previous hand histories, which could be used to create an individual ANN for each opponent it met, improving the accuracy of the opponent modelling. It would have a bot simulator, where bots could play each other at 500 hands a second, producing a nice graph and all the statistics you could need to see where their weaknesses / strengths were.

I spent the next 3 months designing it all. Classes, databases, all perfectly designed adhering to OO principles.

Then I started coding. Despite all my planning, problems popped up that I hadn't foreseen. No problem though, I'll just do a bit of a redesign. Designs were changed, classes removed, added, amended. Carry on coding. More problems. More redesigns.

In the end I spent more time designing than I did coding. It has been more than a year now, and my poker bot has less than half the functionality that my 3 month uni project had. I don't spend a huge amount of time programming - I have other responsibilities nowadays that I didn't have when I was a student - job, baby etc, but I think the real problem isn't lack of time, it is lack of motivation. I have spent so much time on the project, but have barely anything to show for it.

My advise - don't worry about design very much at all. Have a quick think about how the main parts will work together, and start coding. Dont worry about needing to rewrite code when things go wrong. The most important thing is to get coding and get something working to keep you motivated. Better a working program with terrible source code, than a great design and no program.
[/quote]

I perfectly understand this situation. It happens all the time when you try to approach a task with too much analysis. Paralysis by analysis, [url="http://en.wikipedia.org/wiki/Analysis_paralysis"]http://en.wikipedia....lysis_paralysis[/url]

I know the OOP is particularly vulnerable to this issue. I say this because I have a feeling that OOP was overemphasized in CS courses. So much so that I find that there are so many problems that DON'T fit into an object-oriented based model naturally and we programmers spend so much time trying to "fit" the problem into the solution we have already planned out. I think the approach at schools and colleges is too theoritical and technical.

The key, I think, is to realize that OO is just another model of problem solving in general and is not a magic bullet for every kind of programming task. Sometimes I think C++ is the biggest culprit in bringing in too much complexity to the OOP model and people spend too much time beautifying and dressing up their classes rather than make things work.

Also the "verb" problem always exists in OOP: should it be thisobject.performTaskOn (thatObject) or thatobject.performTaskOn (thisObject)?

Share this post


Link to post
Share on other sites
-Well, I start almost always with placeholder rendering. I have to see what the program is doing. (but again, just some hacked together placeholder stuff)
-Then some basic (placeholder) input handling with some hacked game loop. I have to be able to modify, move around, interact with things (again, maybe just placeholder mechanics for debugging the input).
-Then comes some basic (placeholder) mechanics. Or maybe nearly-full-featured mechanics.

(debuging/testing after every single step!)

-Only after these, I start planning/designing (apart from the planning of implementation stuff of course). Usually, I don't overdo it. So I end up with a mess again, but WTF.

-Then I rewrite the whole thing, maybe reusing some pure functions from the first iteration of the program.

So, pretty much what Telastyn said (I guess...).


Usually I end up too exited about adding and adding new features to the first iteration, and then I never do any planning at all. This way I can get a working, polished (-looking) feature-rich application in no time (a few days to a month). With some impossible to fix bugs and flaws....

Share this post


Link to post
Share on other sites
I work by making lists.

Make a list of things to do, with some criterion for knowing when one task is finished. Try to keep this list in logical order that things should be done, but of coursemeplay, you may reorder items later.

Example:

1. Get gfx initialisation, engine inintalisation code working
1. Write file format convert & write map loader
1. Write background renderer
1. Get object manager / engine working "enough"
1. Implement basic physics / gameplay
1. Implement object loader (from map file)
1. Implement some Things in the map (e.g. powerups)
1. Implement bad guys
1. Fix end-of-level, next level, player death etc
1. Tart up graphics
1. Create the shop for buying new weapons etc for next level
1. Add sounds etc
1. Further tart up graphics...

Then potentially divide tasks into subtasks. If you find that you're running out of time you can cancel tasks, or move them on to a lower priority list

Anyway, this is what I do every time I enter a LD48 or similar.

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