|
Bill307
Canada9103 Posts
Since ~January, I've been hard at work programming a mid-sized (from my perspective) game. Through this experience, I've learned and come up with a number of code design ideas, both good and bad. To save others from making the same mistakes that I did, and to give others ideas for their own games or programs, I've decided to share some of my experience here.
Please comment if you found this information useful / easy to understand / hard to understand, or if you have suggestions or improvements for it. 
By the way, the game is being programmed in C# using XNA Game Studio. It's also a long way from being finished, so many aspects of the game have not matured yet and won't be covered here.
--------------------------------------------------
Class Organization
Below is an overview of many of the game's classes, showing how they are organized from the top down, i.e. from general knowlege to specific knowledge.
- Game class -- the over-arching class that encompasses the entire game. Essentially all of the game logic is off-loaded to other classes. It also provides static methods for accessing "global" objects anywhere. (Using XNA's "game services" functionality.)
- Stage Updater and Stage Drawer classes -- these classes manage the game logic and rendering of the game, respectively. These also off-load most of the work to other classes. All they really know is the order in which parts of the game are updated/drawn.
- Various manager classes -- e.g. Enemy Manager, Bullet Manager, etc. These classes know some of the detailed game logic for their own little subsets of game objects.
- Various game object classes -- e.g. Enemies, Bullets, Explosions, Players, etc. These classes are self-explanatory, and contain the rest of the detailed game logic.
- Lower-level classes and data structures -- e.g. Sprites, Particles, Hitboxes, Custom Lists, Custom "Vertex Buffers", inactive object Pools, etc. These don't contain any game logic, and handle small, common tasks like displaying sprites, moving particles, checking for hitbox collisions, storing vertices, etc.
- Physics class -- handles all game physics (just basic linear kinematics with linear forces, acceleration, velocity, and position, and all objects being treated as circles/spheres). The only "physics" code outside of this class is simple stuff like adding an acceleration to a velocity, or multiplying a force by the inverse of a mass to get an acceleration.
- ... and more!
--------------------------------------------------
Pooling Objects
When a game is running, you want to create and destroy as few objects as possible (outside of loading screens and the like). This is especially true when using a managed language such as C# or Java that uses garbage collection.
A common solution to this problem in general is to use "pools" of inactive objects.
Basically, your objects have two pairs of methods:
- a constructor and a destructor / Dispose()
- Activate() and Deactivate()
When objects are created, they are initially inactive and don't do anything. You start your game / level by creating a bunch of these inactive objects and sticking them in a pool (e.g. a stack). Then whenever your game needs one of these objects, instead of creating a new one, it gets an inactive one from the pool. Similarly, when an object is no longer needed, it is not destroyed / disposed of: it is deactivated and stuck back into the pool.
Sounds simple, but there's a caveat: when an object is deactivated, you have to remove all references to it (aside from the pool) immediately. E.g. if an enemy explodes and disappears, the Enemy Manager needs to stop calling its Update() and Draw() methods, homing missiles need to stop following it, etc. You have to remove all these references immediately. E.g. you could use the Observer design pattern (event sending and receiving) to accomplish this.
You might think of adding an IsActive() method as an alternative, and each time something wants to use the object, it checks whether the object is still active before using it, and removes the reference to the object if it is inactive. Unless you do some ugly workarounds, this isn't going to work, because the object could be reactivated as a totally different object. It's much simpler to just remove all references to the object right away.
--------------------------------------------------
Drawing Sprites yourself
This tip is for do-it-yourself sprite-drawing, in contrast to using a sprite-drawing library such as XNA's SpriteBatch. (I don't use SpriteBatch mainly because it uses a different coordinate system from all the 3D graphics.)
Sprites can be rendered in 3D in one of two ways: Orthographic Projection, or Billboards. Which method you use doesn't matter. In both cases, you're drawing the sprite on a rectangle made from two triangles.
When you learn how to draw a sprite on a quad (a rectangle), you get some tutorial code that will draw a single sprite for you. Chances are, when you want to draw a collection of sprites, you'll simply run that tutorial code for every sprite.
THIS IS BAD!! Your game will slow below 60 fps with just a few hundred sprites. Even something as simple as a 30x30 grid of tiles will bring your graphics card to its knees if you draw it like this!
The problem is that your graphics card is designed to process a large number of vertices / polygons all at once, but instead, you're sending it 4 vertices / 2 polygons at a time.
The solution is to put all your sprites' vertices into one big array, then tell your graphics card to draw that. Yes, it really makes a BIG difference! E.g. previously, only 3 particle explosions (~50 sprites each) were enough to slow down my game, but after I made this change, I could fill the screen with explosions without any drop in framerate.
More precisely, you need to group all your sprites' vertices by texture, then for each texture, draw all the sprites that use it (as a big array of vertices). So you'll want to put multiple sprite images into a single texture, instead of giving each sprite its own texture. (If you've ever seen a "sprite rip" of a game, then you'll know what I mean.  )
--------------------------------------------------
A way to organize your collision detection (hitbox) code
It's a good idea to take your code for comparing hitboxes against each other and put that into its own class(es), as opposed to putting that logic into every single class with a hitbox.
For example, you can make a Hitbox class that stores four coordinates -- x1, y1, x2, and y2 -- and provides a method to test if it is overlapping another Hitbox.
But what if some of your game objects have multiple hitboxes, like an irregularly-shaped enemy? Or maybe you want to give some objects Hitcircles instead of Hitboxes? Or maybe you want to check against a bounding box before doing finer collision detection? In any case, it'd be nice to have all of this mass wrapped away in some separate class heirarchy, so that all your player or enemy needs to do is "myHitArea.IsOverlapping(otherHitArea)" no matter how complicated the collision areas actually are.
My first attempt at designing this code was a huge failure. It's so obviously bad in retrospect that I won't even bother sharing it here. 
Instead, I'll share my second attempt, which I'm implementing right now. (By the way, a good way to check if your design is good or bad is to try writing it out like this. It'll help you to see problems with your design that you wouldn't have found if you kept it in your head, especially when you try to explain why your design is so good.)
I'm going to make a class called HittableArea, that has a method "Overlaps(HittableArea other)" to check if this area overlaps the given one. I'm going to make an interface called Hittable that has a method "GetHittableArea()" that returns the object's collision area. Every player, enemy, bullet, crate, etc. in my game is going to implement Hittable, and have a HittableArea object to keep track of its hitbox / bounding box / finer hitboxes / whatever.
So whenever I need to do a collision test, I can just write:
bullet.GetHittableArea().Overlaps(player.GetHittableArea());
And that's it: that's my whole design.
Why is this a good design? Because it works even though we don't know anything about how HittableArea works. (Hell, not even I know how it'll work just yet.) It decouples the long and volatile collision detection code from the rest of my program, simplifying the rest of the code and making the collision detection code much easier to modify.
This will definitely be slower than a simple hitbox-hitbox check, however. But this is something I should look into at the END, when the game is 99% finished. If this code is causing a bottleneck, then I can optimize it knowing I probably won't need to change it again. (As opposed to right now, where I may decide the player won't have just a simple hitbox, or that some bullets will have two hitboxes, etc.)
--------------------------------------------------
Passing some of your game objects' initialization parameters in structs
Suppose you're activating a new game object. (Activating, not constructing, since you got an inactive one from a pool. )
Your activation method might look like this:
public void Activate(Vector2 position, Vector2 velocity, float mass, float size, int hitpoints, float aggression, bool isAsleep, ...)
I suggest replacing it with something like this:
public void Activate(Vector2 position, Vector2 velocity, Params ps)
Where Params is a data structure like this:
public struct Params
{
public float mass;
public float size;
public int hitpoints;
public float aggression;
public bool isAsleep;
...
}
(in Java, you can use a class instead of a struct, but keep in mind you might end up frequently creating and destroying instances of the class, whereas a struct in C/C++/C# is passed by-value)
Right away, you can see that the Activate() method looks a lot cleaner, but that's not the main reason to do this.
The main motivation is that if/when you start storing your game data in XML or binary files, you're going to want a data structure like that, anyway, to contain the same data as your XML/binary file. If you're really lucky, you might not have to change your old code at all when you want to load your game data from a file instead. Speaking of which...
--------------------------------------------------
Loading Game Content, part 1: Game Data class
This is a new idea I came up recently, so it might actually be terrible.
Originally, all our game content -- enemy properties, level design, etc. -- was being loaded all over the place. Eventually the time came to actually organize all this code. So I decided to store all of our game content in a single class called Game Data.
Whenever the game needs some content, it always loads it through the Game Data class. The reason for this is that it allows me easily to change whether this content is loaded from hard-code, or an XML file, or a binary file, or wherever. See, right now almost all of our content is hard-coded, but eventually we'd like to store it in XML or binary files. My hope is that, when the time comes to switch from hard-coded to file-loaded content, I'll have to modify only a single method.
E.g. suppose we've written a map editor and now our maps are stored in XML files. In theory, all I'd have to change is the folllowing:
public static MapParameters GetMap(String name)
{
// OLD:
//return mapHashtable.Get(name); // all the hardcoded map data is stored in this hashtable
// NEW:
return XMLLoaderThingy.Load(MAP_PATH + name);
}
Hopefully this will actually work well in practice.
--------------------------------------------------
Loading Game Content, part 2: Data Loading classes
This is a simple improvement to how I load all my static game content at the start of the game. Note that I haven't really thought about how to load content in short bursts between levels instead of loading it all at the start of the game, so this idea might flop hard if/when we need to do that. Anyway, at least it's better than what I was doing before.
Game has a method called LoadContent() that's called by XNA at the start of the game, and it's the place where you're supposed to load all of your game content. Originally, this method looked like:
Game.LoadContent()
{
Enemy1.LoadContent();
Enemy2.LoadContent();
Map1.LoadContent();
Map2.LoadContent();
HitBox.LoadContent();
Sprite.LoadContent();
ExplosionParticle.LoadContent();
// etc.
}
Basically, every class that had to load some static data had its method called here. This mess was compounded by the fact that the Game class is already bloated with other code.
The solution: every code folder (that needs one) has a class like "LoadEnemyData" that calls LoadContent() for each class in that subfolder. So the code flows like this:
LoadGameData.LoadContent() // load root folder
--> Hitbox.LoadContent()
--> Sprite.LoadContent()
--> ...
--> LoadEnemyData.LoadContent() // load enemies folder
----> Enemy1.LoadContent()
----> Enemy2.LoadContent()
----> ...
--> LoadMapData.LoadContent() // load maps folder
----> Map1.LoadContent()
----> Map2.LoadContent()
----> ...
--> ...
And so on. Much cleaner than putting everything in the Game class.
--------------------------------------------------
Well, that's it for now. I probably won't write one of these again unless a significant # of people actually learn from this one or start some good discussion around it. Enjoy!
|
Wow thanks, I'll definitely use this for reference as i'm writing my game (my first!) although it is somewhat late to implement some of these things and I guess some things may be different as your'e writing in C# with XNA game studio while i'm making it from scratch in C++ . But very nice anyways.
Game class -- the over-arching class that encompasses the entire game. Essentially all of the game logic is off-loaded to other classes. It also provides static methods for accessing "global" objects anywhere. (Using XNA's "game services" functionality.)
Stage Updater and Stage Drawer classes -- these classes manage the game logic and rendering of the game, respectively. These also off-load most of the work to other classes. All they really know is the order in which parts of the game are updated/drawn.
Various manager classes -- e.g. Enemy Manager, Bullet Manager, etc. These classes know some of the detailed game logic for their own little subsets of game objects.
Various game object classes -- e.g. Enemies, Bullets, Explosions, Players, etc. These classes are self-explanatory, and contain the rest of the detailed game logic.
Lower-level classes and data structures -- e.g. Sprites, Particles, Hitboxes, Custom Lists, Custom "Vertex Buffers", inactive object Pools, etc. These don't contain any game logic, and handle small, common tasks like displaying sprites, moving particles, checking for hitbox collisions, storing vertices, etc.
Physics class -- handles all game physics (just basic linear kinematics with linear forces, acceleration, velocity, and position, and all objects being treated as circles/spheres). The only "physics" code outside of this class is simple stuff like adding an acceleration to a velocity, or multiplying a force by the inverse of a mass to get an acceleration.
... and more!
Yea i agree. The game i'm programming is an RTS/TFS sort of game and as I've begun to code the moving part of the ships I've realized how helpful a movement manager/controller would've been. Would you care to expand under the 'and more' section as I think that would give us (me) a better idea on the structure of a game.
Drawing Sprites yourself
Wow! I never suspected that it was the drawing of the sprites themselves to be the cause of my game's FPS to be lower. I'm not exactly sure how to implement it your way. I'm using DirectX 9 (DirectDraw 9), i have a game class, a GUI class, and a graphics class (not all but all that's relevant). The graphics class LPDIRECT3DTEXTURE9 class that DirectX uses to display the image ( *.tga) and from what i read, DirectX uses the LPDIRECT3DTEXTURE9 class to display sprites. I have multiple vectors of all the things that need to be drawn and I retrieve the retrieve the Graphics object either from the vector or from the object in the vector and i retrieve the LPDIRECT3DTEXTURE9 object as well as any other parameters I need to display. I hope that made sense? :3 If i have it set up this way, how would i be able to implement your way of doing things?
I'll comment on the others as I come to actually design those myself but I'll make sure to reference this ! Please keep it updated with your progress!
On a side note: that pool idea is really good, I think i'm doing something like it. Kinda, sorta.
On another side note: What's considered a mid-sized game?
|
great article for people who love that!
|
Thanks for this, I'm going to be writing a game in XNA / C# as a school project, so this is very relevant to me. I hope you post more!
|
Hey Bill - how have you been?
Is this a hobbyist/student project or did you wind up in the industry?
Let's catch up sometime - araxas at symbol gmail point com
|
Maybe I can use some of this for my current project..
I am making a 2D shmup, and my question is how I should do hitbox collision searching, because I can have a lot of hittable objects and projectiles on the screen.
Maybe this won't make the performance any better because there are not that many stuff ... but...
So I search something more elegant instead of the O(n^2) method where I take the objects one by one and check one by one in the set of if there is anything that could hit them.
Now it's like:
for (i=0 , i<size of objects_vector, i++)
for (j=0 , j<size of objects_vector, j++)
check if objects_vector[i] hittable box is underlapped by the hitbox of objects_vector[j]
|
konadora
Singapore66201 Posts
Wow I can barely understand 1% of all the jargon mentioned here
Seems like a totally new language to me T___T
Impressive!
|
Wow, I have trouble enough making a game with game maker. I think my mind would explode if I program a game by hand.
|
Bill307
Canada9103 Posts
Hmm lots of stuff to reply to. I'll start with b3h47pte's reply, for now.
On July 16 2009 11:51 b3h47pte wrote:Wow thanks, I'll definitely use this for reference as i'm writing my game (my first!) although it is somewhat late to implement some of these things and I guess some things may be different as your'e writing in C# with XNA game studio while i'm making it from scratch in C++ . But very nice anyways. Show nested quote +Game class -- the over-arching class that encompasses the entire game. Essentially all of the game logic is off-loaded to other classes. It also provides static methods for accessing "global" objects anywhere. (Using XNA's "game services" functionality.)
Stage Updater and Stage Drawer classes -- these classes manage the game logic and rendering of the game, respectively. These also off-load most of the work to other classes. All they really know is the order in which parts of the game are updated/drawn.
Various manager classes -- e.g. Enemy Manager, Bullet Manager, etc. These classes know some of the detailed game logic for their own little subsets of game objects.
Various game object classes -- e.g. Enemies, Bullets, Explosions, Players, etc. These classes are self-explanatory, and contain the rest of the detailed game logic.
Lower-level classes and data structures -- e.g. Sprites, Particles, Hitboxes, Custom Lists, Custom "Vertex Buffers", inactive object Pools, etc. These don't contain any game logic, and handle small, common tasks like displaying sprites, moving particles, checking for hitbox collisions, storing vertices, etc.
Physics class -- handles all game physics (just basic linear kinematics with linear forces, acceleration, velocity, and position, and all objects being treated as circles/spheres). The only "physics" code outside of this class is simple stuff like adding an acceleration to a velocity, or multiplying a force by the inverse of a mass to get an acceleration.
... and more! Yea i agree. The game i'm programming is an RTS/TFS sort of game and as I've begun to code the moving part of the ships I've realized how helpful a movement manager/controller would've been. Would you care to expand under the 'and more' section as I think that would give us (me) a better idea on the structure of a game.
Well, I think the overview up there already shows the gist of how my game is organized:
1. lots of high-level classes that "manage" lower-level classes
2. a set of game objects at the ends of the "management" tree
3. a set of bottom-level classes like Sprites
4. content-loading and -storing classes like LoadGameData
5. utility classes like Physics and general Utils
But I'll give you some more examples...
InputSource interface and replays
The InputSource interface is used by the game to get the player's input. For a shoot-em-up, it might have methods like IsUpPressed(), IsFirePressed(), IsBombPressed(), etc. So the game doesn't know what keys, mouse buttons, or joystick buttons correspond to these inputs: it's all hidden behind the interface.
Specifically, my InputSource interface has a method called GetInputBits(), which returns an integer where each bit corresponds to an input, like move up, or fire bullets, or fire a bomb. Not only is this slightly faster, it makes the replay-saving code a little easier: I just have to write this integer to a file at each frame, and voila: all the game input is saved!
The InputSource interface is great because it allows you to change the source of the input -- from a keyboard, from the mouse, from a gamepad, etc. -- without having to change any of the game code. In particular, I can simply make the input source a replay file, and that's it: replay functionality done.
This allows you to easily add replay functionality to most genres of games... but not RTSes. If you did this in an RTS, you'd get a first-person-replay, which is nice, but generally people like to have the ability to control the screen and the mouse themselves when they're watching an RTS replay.
For RTS replays, I'd suggest following StarCraft's example and saving the actions performed at each frame, not the player's exact mouse and keyboard inputs. In that case, you might want to write an "ActionSource" interface instead. Then you could add first-person support by storing the mouse position and screen location at each frame, as well.
PhysicsObject interface
Each game object that obeys the laws of physics implements this class, allowing it to be used by the Physics class. It has methods like GetPosition(), GetMass(), GetCollisionRadius() (every object is treated as a circle/sphere), ApplyCollisionForce(), and so on. Pretty self-explanatory.
EnemyMovement class
(Actually, I should make this a general movement class, not something specific to enemies. Thanks for indirectly bringing this to my attention. Anyway...)
This class fills two roles:
1. it implements the PhysicsObject interface, and
2. it controls the movement of an enemy.
Previously, all of this code was lumped into my Enemy class, which was a bad idea. So as part of our enemy code overhaul, I'm moving it into its own class.
It has methods for:
- implementing PhysicsObject: GetPosition(), GetVelocity(), ApplyCollisionForce(), etc.
- controlling movement indirectly: SetPropulsionDirection(), Accelerate(), Turn(), Decelerate(), etc.
- controlling movement directly: SetPosition(), SetVelocity(), etc.
Wow! I never suspected that it was the drawing of the sprites themselves to be the cause of my game's FPS to be lower. I'm not exactly sure how to implement it your way. I'm using DirectX 9 (DirectDraw 9), i have a game class, a GUI class, and a graphics class (not all but all that's relevant). The graphics class LPDIRECT3DTEXTURE9 class that DirectX uses to display the image ( *.tga) and from what i read, DirectX uses the LPDIRECT3DTEXTURE9 class to display sprites. I have multiple vectors of all the things that need to be drawn and I retrieve the retrieve the Graphics object either from the vector or from the object in the vector and i retrieve the LPDIRECT3DTEXTURE9 object as well as any other parameters I need to display. I hope that made sense? :3 If i have it set up this way, how would i be able to implement your way of doing things?
While I know how to program graphics in OpenGL, I'm afraid I don't know how to use DirectX. 
But basically, my code is like this:
1. For each sprite (with some texture T), add its vertices into a big array called spriteVertices.
2. Also maintain an array of indecies for these vertices.
3. Once that's done, tell the graphics card to draw a triangle list, and send it the vertices and indecies.
Actually, I use a single class, "SpriteVertexSet", to manage those two arrays: it gets passed around to all the different game objects that use sprites (of the same texture) and when it finally reaches a Sprite, the Sprite simply adds its vertices to the SpriteVertexSet. The drawing code is also inside the class: SpriteVertexSet.Draw().
As for the exact DirectX functions to call, I'm afraid you'll have to find that out on your own.
By the way, once you get this working, I suggest looking into Vertex Buffers. These are very useful when you have a set of vertices that never changes, e.g. your terrain. They allow you to copy the vertices to the graphics card only once, and store them in the GPU's memory. This is another big performance gain. Unfortunately, it isn't useful for sprites in general, which will usually move around and animate.
There are also Dynamic Vertex Buffers, which would probably be useful for sprites that move and change, but I haven't learned how to use them, yet.
I'll comment on the others as I come to actually design those myself but I'll make sure to reference this ! Please keep it updated with your progress!
On a side note: that pool idea is really good, I think i'm doing something like it. Kinda, sorta.
On another side note: What's considered a mid-sized game?
Thanks, guess I will.
I call it a "mid-sized" game because I can think of games that are probably a lot more complex, and games that are a lot simpler. I'd guesstimate that your RTS will also be a "mid-sized" game, if not bigger.
It's actually very risky what you are doing, imo: undertaking such a large and complex game for your first game. To be honest, I expect you won't be able to finish it: not because it's big, but because you'll write code that isn't very clean or easy to modify, and as your game grows you'll waste exponential amounts of time rewriting old code or hacking around your code's limitations. :S
In any case, good luck. 
|
On July 16 2009 20:13 freelander wrote:Maybe I can use some of this for my current project.. I am making a 2D shmup, and my question is how I should do hitbox collision searching, because I can have a lot of hittable objects and projectiles on the screen. Maybe this won't make the performance any better because there are not that many stuff ... but... So I search something more elegant instead of the O(n^2) method where I take the objects one by one and check one by one in the set of if there is anything that could hit them. Now it's like: for (i=0 , i<size of objects_vector, i++) for (j=0 , j<size of objects_vector, j++) check if objects_vector[i] hittable box is underlapped by the hitbox of objects_vector[j]
you can cut down from n^2 checks to (n - 1) + (n - 2) + ... + 1 = ((n^2 - n) / 2) checks with some minor changes to the loops, to make sure that i != j (wouldnt make sense to check for collision with itself) and j > i (if object[i] hits object[j], object[j] hits object[i], no need to check both ways)
num = number of objects
for (i = 0; i < (num - 1); ++i)
for (j = (i + 1); j < num; ++j)
// check for collision of object[i] and object[j]
|
Nice read. Never really worked/wrote a large-scale game before, largest was only a small 1-level Kirby game (reflecting upon it now, had lots of bad programming practices - but that's high school for ya).
How is C# for game programming? I've only used it for web/desktop apps. Also, did you go off a book or is this just all "as it goes"?
|
Thanks, I guess I'll have to dive into that DirectX stuff myself
It's actually very risky what you are doing, imo: undertaking such a large and complex game for your first game. To be honest, I expect you won't be able to finish it: not because it's big, but because you'll write code that isn't very clean or easy to modify, and as your game grows you'll waste exponential amounts of time rewriting old code or hacking around your code's limitations. :S
Let's hope for the best shall we.
|
As an EE who's never had to learn any object-oriented programming, this is pretty easy for me to understand. You did a good job breaking down the information.
For loading static game content, would it make more sense to load only information pertinent to the entire game at the beginning and then load level-specific content at the beginning of each level? That way you can discard the first level's content at the end of the first level, load the second level's content, and move on. Level content would include what enemies/objects are used in that level and particularly that level's map, locations of things, etc. If an enemy and its data is used in multiple levels, there's some waste reloading that information I guess...or you could just put any repetitive level data into data loaded at the start of the game.
|
I'd like you to know I'm also following this. I'm also working on a game - but with PyGame. Once I get a few projects under my belt I'll probably delve deeper with OpenGL, though.
|
Wow Bill, using input flags frame by frame with integers is a fuckin good idea.
If you make a fighting game, and do this method, and the players have 8 inputs each (4 direction 4 buttons), the max replay size will be:
3 * 90 sec rounds * 60 frame/sec * 2 byte = 32 400 bytes = 32.4 kbytes
If the players use more than 8 inputs, for instance Street Fighter series, you'll need a Uint32 to store everything .. so tha max size will be doubled, 64 kbytes.
Interesting, I just checked, the Guilty Gear XX # R replays are between 3 and 10 kbytes in size. How did they do it ? ~~
|
Germany2896 Posts
Did you do any measurements to determine that object allocation limits performance?
And why do you have so many different managers?
@freelander
Simply compress it afterwards?
|
a month earlier this blog might earn you a sc2 beta key.
|
@freelander
Simply compress it afterwards?
that's probably true
|
Bill307
Canada9103 Posts
On July 16 2009 15:22 nvnplatypus wrote:
Hey Bill - how have you been?
Is this a hobbyist/student project or did you wind up in the industry?
Let's catch up sometime - araxas at symbol gmail point com
A couple of friends and I are hoping to break into the industry with this.
On July 16 2009 20:13 freelander wrote:Maybe I can use some of this for my current project.. I am making a 2D shmup, and my question is how I should do hitbox collision searching, because I can have a lot of hittable objects and projectiles on the screen. Maybe this won't make the performance any better because there are not that many stuff ... but... So I search something more elegant instead of the O(n^2) method where I take the objects one by one and check one by one in the set of if there is anything that could hit them. Now it's like: for (i=0 , i<size of objects_vector, i++) for (j=0 , j<size of objects_vector, j++) check if objects_vector[i] hittable box is underlapped by the hitbox of objects_vector[j]
I don't know if you're doing this already, but: you can simply store each kind of object in a different vector, then only check two vectors' objects against each other if those objects can hit each other.
E.g. you wouldn't check the vector of player bullets for collisions with the player.
That alone is probably enough. Unless your game is going to have a LOT of objects that can collide with each other, you'll only be wasting your time by trying to optimize it further.
If you do need a more efficient algorithm, then you can start your search here:
http://en.wikipedia.org/wiki/Collision_detection#Spatial_partitioning
On July 17 2009 04:29 King K. Rool wrote:
Nice read. Never really worked/wrote a large-scale game before, largest was only a small 1-level Kirby game (reflecting upon it now, had lots of bad programming practices - but that's high school for ya).
How is C# for game programming? I've only used it for web/desktop apps. Also, did you go off a book or is this just all "as it goes"?
I've never read a single programming book in my life, actually. The vast majority of my experience came from programming stuff in my own time, through high school and university. Some stuff I learned from classes, and some of it I read online, but most of it is stuff I came up with myself.
On one hand, looking to see if someone else has already solved your problem can be immensely helpful. In particular, if you're working with people who are more experienced than you, then you should never hesitate to ask them for help or advice.
On the other hand, you learn 100x better from your own programming experience than from reading or listening to another's experience.
|
Bill307
Canada9103 Posts
On July 17 2009 18:04 freelander wrote:
Interesting, I just checked, the Guilty Gear XX # R replays are between 3 and 10 kbytes in size. How did they do it ? ~~
Like MoC said, they compress them.
If you think about it, between most frames, the players' inputs will not change, and compression algorithms can take great advantage of this.
In theory, one could write replay saving and loading code that exploits this pattern to save smaller replay files.
In practice, one should leave this to a general compression algorithm and focus on useful tasks.
On July 17 2009 20:53 MasterOfChaos wrote:
Did you do any measurements to determine that object allocation limits performance?
I've read repeatedly this as fact, both in general and regarding XNA on the XBox 360 specifically. Since C# is a managed language, it's not just object creation and destruction, but also requiring the garbage collector to do its job.
I should be using a single generic Pool class to handle all of my object pools, and in the interest of measuring this difference, I've set it up to not use a pool at all and create new objects as they're needed if NO_POOLS is defined. It's not a true comparison, but hopefully it'll be better than nothing.
On July 17 2009 20:53 MasterOfChaos wrote:
And why do you have so many different managers?
To divide the code into sane portions.
|
|
|
|
|
|
EPT
