XNA using C#

[Vinen]

Nice, never thought of it that way; makes perfect sense.

[Throag]

Happy I helped
Don't hesitate to ask more questions, I'd be glad to help more on that kind of stuff. Anyway, if you are serious about that, I suggest you try to find some books on object oriented programming it will help a lot grasping more of the available possibilities.

[Cloud9_]

Almost done with the very basics of my battle engine; put together some screenies for some friends who were interested in the project so I figured I'd share them here.

(note that all the sprites will be changed when I get around to doing them... AKA after the engine is done. Also this game will be very very very short, think "intro" to FF1 short where you fight garland and return to the very 1st town)

Shackpics - Intro Screen!
Shackpics - TestMap
Shackpics - Battle!

[Kharza-kzad]

Looks fun!

I'm jealous, been doing nothing but tools and art, don't have anything working yet.

[Cloud9_]

i should actually program tools like a map editor and stuff, even if its just for the learning process since i've never made game tools before... all i've been working on is the core engine and "how the game works" type stuff.

- battle background + sprites are from squaresoft, the other stuff was put together as placeholders

- the tiles are from a tutorial I got a while back, since my TileEngine is a heavily modified version of that tutorial.

I figure once the battle engine is done (i'm writing the actual logic and stuff now, gonna have to refactor it heavily after I'm done.. i just want to get it into a working state at the moment) I will try to think of other systems I may need and try to build those, and once the core engine is done i'll make a "mini rpg" .. and depending if there is interest from other beginning programmers / friends / online communities who want to try and make a "medium length" rpg with the engine, we could try that too.. for anything bigger than a mini rpg though, would need proper tools that I just have not gotten around to yet

[Kharza-kzad]

Early prototypes are great, so I think you are going at it the right way.

I am planning on doing the same, but alot of my prototyping needs a bsp in place, so I'm doing all the bsp build tools for now. 3D is a bit harder to dive into than 2d.

But other than that, I'll probably build one skinned mesh and use that for every character and npc in the game, and skip any other fluff and just get it running

[Hachima]

Originally Posted by Throag

Seems like you are trying to hard code a lot of stuff Vinen.
What you are trying to do could be defined as behavior for each character.
This behavior could be an attribute of your Character class, and at each frame your game engine would iterate over all your Characters who would in turn process their behavior.
You could have a BasicBehavior class which would be responsible for the basic behavior of a character during battle (whatever that it is you define as "basic"). That class would be the default behavior attribute of a character. And then you can have as many class as you want inheriting from BasicBehavior to implement more specific behaviors such as the one you explained.
This way you can define as many behaviors as you want and change them whenever you want. You could also manage them through a BehaviorManager singleton class which would return an instance of a behavior class on demand.
You could also define your behaviors in a way that allows a Character to have multiple behavior and process them all at each frame. There are a lot of ways to improve that idea
When designing game mechanics like these, you should always try to think them as evolutive as possible. It saves a lot of work for later when you are trying to change stuff.

I'd have to agree. That sounds like the decorator pattern to me. There are a lot of design patterns that can be applied to gaming. State pattern, command pattern and factory pattern are just a few that come to mind. I highly recommend Head First Design Patterns Amazon.com: Head First Design Patterns (Head First): Elisabeth Freeman,Eric Freeman,Bert Bates,Kathy Sierra: Books

It has a nice casual tone to it, and it is real easy to follow.

[Vinen]

Originally Posted by Hachima

I'd have to agree. That sounds like the decorator pattern to me. There are a lot of design patterns that can be applied to gaming. State pattern, command pattern and factory pattern are just a few that come to mind. I highly recommend Head First Design Patterns Amazon.com: Head First Design Patterns (Head First): Elisabeth Freeman,Eric Freeman,Bert Bates,Kathy Sierra: Books

It has a nice casual tone to it, and it is real easy to follow.

Nice, going to go ahead and order that book...

[Kharza-kzad]

I use observer alot for input (controllers, keys) and network stuff. And command for sending stuff back and forth. And bridge for somestuff.

I'm not a huge fan of state machines. Maybe I just haven't seen one done right but they seem like a house of cards to me.

[Vinen]

Originally Posted by Kharza-kzad

I use observer alot for input (controllers, keys) and network stuff. And command for sending stuff back and forth. And bridge for somestuff.

I'm not a huge fan of state machines. Maybe I just haven't seen one done right but they seem like a house of cards to me.

I dunno, I tried otherwise but I am currently using a State Machine for the RPG I'm working on. It's nice for pausing, loading screens, etc...

[Cloud9_]

I've come to the conclusion that the way I'm handling my gamestates is actually making my job harder After some searches, I notice the main method to use is stacking gamestates so when the game is paused, it doesn't 'destroy' the previous state.. just draw's over it until unpause which would pop the paused state off the stack.

I saw the microsofts GameStateManagement demo and am reading through it, but I'll have to play with it a ton to fully understand what its doing (yay for beginning programmers )

So let me ask you guys, how are you handling your GameStates? Any good tutorials for getting a basic one set up ?

[Vinen]

Originally Posted by Cloud9_

I've come to the conclusion that the way I'm handling my gamestates is actually making my job harder After some searches, I notice the main method to use is stacking gamestates so when the game is paused, it doesn't 'destroy' the previous state.. just draw's over it until unpause which would pop the paused state off the stack.

I saw the microsofts GameStateManagement demo and am reading through it, but I'll have to play with it a ton to fully understand what its doing (yay for beginning programmers )

So let me ask you guys, how are you handling your GameStates? Any good tutorials for getting a basic one set up ?

I stack them. I modified the library which is supplied as part of the XNA Unleashed book.

[Cloud9_]

heh have not gotten around to getting Unleashed yet. Worth it for someone still very new to programming or would it be over my head?

[Vinen]

Originally Posted by Cloud9_

heh have not gotten around to getting Unleashed yet. Worth it for someone still very new to programming or would it be over my head?

Very worth it. From what you've done chances are you will understand it. Keep in mind the book was written for a prior version of XNA so some code is obsolete / doesn't work.

[Froofy-D]

For game states I use state machines I guess (switch statements). I'm trying to keep everything as simple as possible, with as few files as possible. My game so far is basically 3 major parts:

Main.cs - does rendering, collision detection, and state management. Has separate Array_Lists<> for each major object type: ship, projectile, particle system, star system, asteroid, planet, etc. The actual code for rendering, updating, colliding, and drawing objects is in other files. So Main() is just a big state manager that farms out calls.

Class Files: each major class has it's own Update() and Draw() function. Examples: Camera.cs, Player.cs, Ship.cs, Starfield.cs, Particle.cs, ParticleSystem.cs, etc.

Static Helper Function Files - static functions that don't really make sense associated with an object. Random number generation, collision math, file loading, model drawing, stuff like that.

One thing I'm not sure where to put is mouse and KB input, since my Main.cs is big already with rendering/collision. Right now its a big switch statement in Main.cs. I was thinking of just making it a static function like ProcessKB() and ProcessMouse() in a separate file.

Collision is another thing that is really hard to decouple from Main(), since many different types need to be done (e.g. ship-ship, projectile-projectile, projectile-ship, etc.) and depending on the outcomes different things need to happen.

I guess Collision, Rendering, and State Management are all interdependent, and hard to separate in an intuitive way.