Hi, Im a student who's studying C#.NET and alot of XNA in my spare time, and i want to use XNA to create a game. I need to make this game to apply to a gameschool in my country so i want to do almost all code myself. I've completed the whole game idea which you can find here: http://www.dieselgaming.com/fangame.htm Its basicly a 2d game with some small AI, but i dont know where to start with. If some1 has got tips on how to split it up it would be great :) Frank.

My approach is not better or worse then any one else, it's just different. I don't mean to offend people who do a different approach. My intent is to share a different point of view. If I offend someone by accident, please accept this as a pre-apology. With that said:

I'm a self taught coder and I find the above approach good if you are confident and know all parts of the game. Although, when you get done with writing out EVERY thing as a new coder it can really break one's spirit.

Instead, when I first got into coding, I started with a basic "Hello World." Then I build my logic code to function with just single key strokes to get things like movement (out puts as values to the screan), eat commands, fight commands, buy/sell w/ inventory. This way you've got how the game functions. You'll find that your code will break down into simple files: Main, KeyCommands, Character, Map, Buy/Sell, etc.

The second part which I did seperately was to make the graphical side with the mouse and mouse controls and the ground, sky, trees and some additional objects which can be broken upon mouse click. This way, if you've got a great idea for game logic, you don't have to wait until you've got a graphical menu and new 3D objects to impliment it, you can just go to your logic code and write it.

Finally, when you have a solid understand of both, you merge the two into one massive complex folder with some 20+ files and multiple sub-folders which are all broken down based on what they provide to your game.

Now the second game you write, or the next rewrite of your code, you can then do what the person does above, and it doesn't feel very daunting because you've already writen each of those at least once, and you've got a good point to start from.

I hope this helps and I apologies if I offended any one.

BladeStone

What are you capable of right now? Can you render some things? Can you handle input already? Can you implement a game loop? How familiar are you with C#? Have you built some (small) games before?

OldProgie2 has noted a very important part of the design process of where you'd probably want to get started, so i'm not trying to take anything away from what they said. But to add to the list some other elements that i'm sure others here know, that you'll want to think about.



Game Engine:

Already listed--

Graphics

AI

User input handling

Front end

Audio

Also Add --


Timer

- Frames Per Second:How often does the game need to render graphics

- How fast will the game run

Physics

- Collision Detection

- Movement Between Objects

--Speed and Velocity of Objects when applicable

Quote:Original post by Captain P
What are you capable of right now? Can you render some things? Can you handle input already? Can you implement a game loop? How familiar are you with C#? Have you built some (small) games before?

First of all, thanks all for replying :)

I think its hard to say what i can and cant do. I think i know a lot of C# and the programming techniques involved with it (i recently passed my microsoft exam for it) but in there there's no graphics involved.

Im reading a very good book atm (at least i think its a good one) called
"XNA Game Programming for xbox360 and windows" In this book i learned how to make my own pong game for example.

I know how to create user input, game loops, but redering things is new for me (i did it already, but there's more to learn) i have build small network games in java before like tic-tac-toe and guess the number.

A list of thigs i think ill need:

Graphics:
- Background (do i make a grid? and if i do, how do i place the fan in it?)
- Mouse sprites (it needs to move smoothly (i heared about bitblitting?))
- Fan sprite (3 states: not blowing, slow blowing, fast blowing)
- Menu (to the right in which you can buy upgrades)

AI
- Mice need to move from right to left only, not too fast, and they need to wait when they are between blocks (horizontally)

User input handling
- Up and Down only to move the fan, maybe mouse input to select menu items.

Front end
(what do you mean by front-end?)

Audio
- Got a band to make me music :)

Timer
- Frames Per Second: havent thought of it, but 30-40 should be enough i think.

- How fast will the game run: Mice need to move smoothly across the field, but very fast (so you got plenty of time to blow em away)

Physics
- Collision Detection: I need this when a mouse hits the spikes (then a bloodbath should erupt or something :P)

- Movement Between Objects: Dont know what is meant here, but mice shouldn't be affected by the fan if they have a block left of em.

-Speed and Velocity of Objects when applicable: havet thought of it yet...

Let's start by prioritizing things first. A lot of game-developers fall for feature-creep, which means continually adding new cool stuff because it's, well, cool, but in the end, their product is either late or it never gets done. If your game doesn't need a fancy technique, then save it for later. Of course, in this case it depends on what this school finds most important.

In this case, it's probably a good idea to get a moving fan up and running first. This makes sure you can handle input, react to it and draw the results. Once you've done that, you can add the field with the mice and work on the mice movement. Once that's in place, you can add the obstacles and have the mice react to them. Then, you can implement the fan blowing and the mice reaction to that. Finally, a menu on the side, some powerups and a score system and you've got a playable game. Of course, there will be plenty of things you can tweak and polish but it's important to get the core aspects up and running early on.


Anyway, if you can draw a few images, you're well on your way already. A tilemap is nothing more than drawing multiple images at regular intervals. But perhaps a single background image will do the job just fine, too... One thing to keep in mind is the order in which you draw images: something that's drawn later is drawn on top of earlier images. In other words: you'd draw the background first and then the mice, cheese and fan. Bit blitting isn't relevant here since XNA handles the rendering for you.

Then there's some logic involved. This is simply programming and a bit of smart thinking. Where should these mice move to? Is the fan blowing at them and if so, are they hidden behind a block? Have they reached the cheese? If so, substract 100g from the cheese (or whatever other amount) and remove the mouse. Is the fan blowing fast or slow? Substract energy from the battery according to that. Has a mouse hit the spikes (simple bounding box collision checks are probably more than sufficient here)? Kill it. Basically, all these 'game rules' should be taken care of somehow.

And finally, the game has to react to user input. Has the user pressed a key? Which key? If it's the up arrow, move the fan up a bit, and so on.


Usually, you should handle input first, then logic and then you draw the screen. Input affects logic and logic affects where things need to be drawn.

Does that help you somewhat? The idea is to keep things simple, don't let this intimidate you. Start working on something small and essential and continue from there.

Yes, those are great tips!

ill start working on the fan and user input first.
only 1 question: how do i change the animation of the fan when its blowing fast/slow (i need animations then, i only used not moving sprites in the past)