Sign in to follow this  
Dieseltjuh

How do i split my game up in pieces?

Recommended Posts

Dieseltjuh    109
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.

Share this post


Link to post
Share on other sites
OldProgie2    158
You need to start with a process called top-down design.

Think of all the major systems you will need for your game, e.g.

Graphics
AI
User input handling
Front end
Audio

Then start breaking down each of these systems into smaller units. E.g.

Graphics
+ Backgrounds
+ Sprites
+ Effects

Audio
+ Music
+ Spot effects

Continue this process, breaking down each system as much as you can until you get down to a level where you can start writing psuedo code for your systems.

The design at this point will probably lend itself to a prticular overall structure.

I then ususally start with a bottom-up programming approach, starting with visual elements (so that you can see what is happening)

Share this post


Link to post
Share on other sites
BladeStone    100
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

Share this post


Link to post
Share on other sites
Captain P    1092
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?

Share this post


Link to post
Share on other sites
Casino    101
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

Share this post


Link to post
Share on other sites
Dieseltjuh    109
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.

Share this post


Link to post
Share on other sites
Dieseltjuh    109
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...

Share this post


Link to post
Share on other sites
Captain P    1092
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.

Share this post


Link to post
Share on other sites
Dieseltjuh    109
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)

Share this post


Link to post
Share on other sites
Captain P    1092
Animations are usually done by displaying multiple images, or multiple parts of an image, after each other. That is, the first few frames you draw image A, the next few ones you draw image B, and so on. For another animation, you simply use images D, E and F rather than A, B and C.

Share this post


Link to post
Share on other sites
wijnand    253
Dieseltjuh

Making a game engine is nothing more then first writing down what you want it to do.

We know you have one goal in hand: Make a game for a college and you need an enhine for it. First things you need to do is write your requirements and then chop these up in "iterations"

When I had to make a 3D engine for my minor in the hague I basically wrote down the following plan:

1. Make a Windows Window.
2. Load directX in the window
3. Load a 3D model in the window
4. Try to add a Texture to the model
5. Flesh out the rendering part to be able to render multiple objects

As you do small steps and try to work out in a step by step plan the things should start coming themselves. The BIGGEST problem you will most likely run into is physics and collision detection. But try to do the easier things first so you get valuable experience and also problemsolving skills :) Programming and specially game programming is nothing more then just trying to solve problems in systematical ways.

The Vyper engine basically had the following structure:

Kernel.cpp (bootloaded the entire thing)
Renderer.cpp
- DirectX
- OpenGL
Model.cpp
Texture.cpp
- load the textures into a linkedlist
DirectInput.cpp
Log.cpp

And so forth if you have some UML experience or OOP write things down on paper first before starting what is logical in your case :) what si the best most efficient way to write an engine. the BIGGEST rule you have to abide to is that you have an engine you can easily rip out again and start with a new game.

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