StrafeFighter source code

[ShannonSmith]

I've had a few requests for the source code to StrafeFighter and have finally got around to putting on Google Code:
http://code.google.com/p/strafefighter/source/browse/#svn/trunk/src

Also to go with it is a tutorial on procedural content generation specifically focusing on the StrafeFighter planets:
http://www.angryoctopus.co.nz/?page_id=11

[zammbi]

Very handy tut on procedural textures.

[SwampChicken]

Thanks for the up.
Much appreciated!

Games published by our own members! Check 'em out!

[h3ckboy]

hehe I hate to jump in on this but I am just curios did you make a class for every sprite?

[ShannonSmith]

No, I consider creating a class per sprite (or object type) to be very bad practice. Aggregation over inheritance, there is a good reason for this (there is a very good article lying around on this if you Google it).

[SimonH]

Cool! This could be very handy for the Community Space Trader game!

[h3ckboy]

if there is another way what is it I will try and find it on google but I have been unable so far .

thx

[ShannonSmith]

I suspect we may be talking about different things. What exactly do you mean by 1 sprite per class? I have a generic ship object that both the enemy and player ships are instances of. The ship descriptions are in an xml file and created via the ShipGen class.

[h3ckboy]

what I currently do is have a class that all the sprites extend "Actor" but every individual sprite has a act() method to do what it is supposed to do

[ShannonSmith]

That is a fairly common model. I don't particularly like it myself, it means every time you want a new type of Actor you have to subclass and write some code which is a bit of a pain. I prefer having a different composition of fixed objects (Weapon, AI, Ship) and have a factory class to put them together for you based on a configuration file.
If you ever find yourself having lots of very empty subclasses you probably want to consider a composition model.

Games published by our own members! Check 'em out!

[Jono]

I think this could be the article you're thinking of: http://www.gamearchitect.net/Articles/GameObjects1.html

It makes some good points, though at times it's a bud FUDdish about inheritance. Some of the problems mentioned with inheritance were just poor design decisions. Still, unless your game is never going to be extended and fits an inheritance model perfectly, the aggregation approach seems the way to go.

The real killer comes down to not having multiple inheritance. When different classes need to share more than one bit of code, that whole model falls apart.

[h3ckboy]

k guys thx I will check it all out in a bit I am just working on a  game right now and there are few enough sprites that the current model works. also i can use a switch to choose which model to use in one class. which is what I am doing now .