Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


RubyNL

Member Since 13 Jun 2007
Offline Last Active Jul 07 2012 05:40 PM

#4955764 Space partitioning for flocking

Posted by RubyNL on 04 July 2012 - 03:48 PM

Well, you could use binary space partitions or quadtree's, which are probably easier for 2d things, or even octrees which are easier to use with 3d things.
Or, you can just use a grid, when each cell in the grid has a pointer to the objects in it, the objects only have to check for collisions with objects that are in the same cell.


#4955761 Help me change my life and career.

Posted by RubyNL on 04 July 2012 - 03:45 PM

A little tip. If you're gonna make a game, first make some smaller, simpler games in the same genre. By simple I mean especially the graphics. Good graphics are pretty hard to archieve, most game studio's have whole teams of artists for character and level creation, and in my experience, good graphics are one of the hardest things to archieve (together with a general fun game experience: making the whole game not too hard or too easy, not confusing the player, and keep rewarding the player without giving him more of the same every time).

The first small game will probably be a mess, maybe you won't even finish it. But, as a result, you will have a better idea of the structure the program needs to have. Sometimes, when you're able to implement a new feature in your old engine, you will think 'OMG, if I redesigned the whole thing it would be so much easier!'. Keep your old projects, and comment everything well, so you have usable source to consult or even use directly if you're having trouble. Also, think about splitting things up in classes, if this doesn't hurt the readability or performance of your game. Also save useful functions in a seperate file.
For me, this way of working results in much cleaner and faster code. Please note I didn't ever code a big game, so I don't know how well this way of working scales with the projects, possibly this is too much work for big projects.

Last thing. You've probably heard this before or thought of it yourself, but seperate your engine from the levels, graphics, and gameplay as much as possible. It will be easier to make special effects (graphical effects or gameplay-wise, for exception, inversing the gravity will be easier when you have some force vectors instead of a hardcoded "player.y += 5;" each frame (as a figure of speech)). This can cost a little bit of performance, but things like this can usually be done pretty efficient. Else you just have to find a balance, or try both ways and then decide what's the way to go.

Good luck :)


PARTNERS