QUESTION:
I don’t believe if you use brute-collision detection. How do you check collision, especially for 2D like on Ultratron which have so many entities? I’m using CokeandCode’s space invader part 1 tutorial until now and it gave me 80% CPU usage :point:
In Ultratron and Titan Attacks, it’s brute force collision detection.
Droid Assault used a quadtree (which turned out to be a complete waste of time). Revenge of the Titans used a cell-based collision manager which was much more appropriate. The cells are 16x16, the same size as the gidrahs.
Ultratron doesn’t really have many entities at all! Certainly no more than 100 on screen ever, which means 5,000 collision checks per frame - bugger all.
Cas 
In what sense? Was the performance improvement nonexistent or just less than you expected? How did you use the quadtree there?
So you just do collision checks between gidrahs, obstacles and shots in the same and neighboring cells? (btw. just noticed that american spelling makes your neighbours boring ;))
Looking back, I’d use a quadtree now if the sizes of the collision entities varied greatly, which it handles much more efficiently than the cell based manager. However, in DA and RoTT, almost everything fits into a single cell (or overlaps into 4 cells). I discovered in RoTT that by switching from a quadtree to cell-based I got a massive performance boost. And I mean massive. So although the quadtree was pretty efficient at what it did, it was too generic a solution for the specific problem I had which was managing collisions between hundreds and hundreds of very small reasonably uniformly sized objects; I simply didn’t need the ability to check for hundreds of totally arbitrarily sized rectangles.
I never did go back and retrofit DA with a cell-based collision manager because there are still only maybe 100 entities in the world at any one time usually and in fact it could probably have been brute forced without much trouble. But Revenge can have several hundred entities trundling around, which would be over 10 times as many collision checks per frame.
Cas
I can really agree about the cell approach. I used some complicated quadtree-like solution for 2D first but when I switched to a simple grid, the performance got so much better.
I was just guessing, since there’re so many bullets spray each time shoot
Not sure if this has been asked and I haven’t looked at your code all that well.
Do you have some sort of scene graph/tree?
How do you deal with rendering priority? (or just rendered from lowest to highest Y-value?)
There’s no scene graph as such, no. This is only 2D after all! It’s all rendered back-to-front, sorted by a multitude of variables. The sprite engine is designed to more or less be as efficient as it can be whilst being totally easy to use - I just throw all my sprites into a giant bucket and render them pretty much using brute force, albeit with some nifty batching techniques and double-buffered VBOs. I don’t use shaders yet - haven’t quite managed to see the “point” and I’m still supporting pretty old OpenGL drivers so I don’t want to waste time with two rendering paths in the code.
Cas
Ok, sounds simple enough.
Actually I wrote some text here explaining how I do it and what the problems are, but now after explaining I think I can solve my problems with top-down rendering priority of both nested and layered entities/components.
What percentage of your customers are users of what OS ?
How much isn’t windows ? How much of it is Mac how much Linux ?
Direct units (not sales - an Ultrabundle sale can mean up to 3 units) in the last year, it’s about 21% Linux, 21% Mac OS, and 58% Windows.
Cas
That is a lot more linux than i was expecting.
Then why exactly is it, that you said that developing the linux version of ROTT was a commercial failure ?
I can’t find the quote now, but I’m certain you said something like that.
Princec is there any plans for RotT android port. Devices are gaining raw power quite fast and marketshare is growing rapidly.(>550k per day)
Because that amounts to about $10,000. Massive FAIL. If I also added up my time supporting Linux users (easily 90% of support problems) I’ve spent over a month in total answering emails and investigating oddities, so basically I’ve created a month’s support for myself for nothing.
Cas
Not in the near future. The game is too complex to fit on a phone screen and the wrong fit for the demographic anyway. Android tablets are going nowhere fast thanks to lawsuits. I’ll sit and wait before I undertake any massive projects like that I think! Also, Dalvik is far too slow.
Cas
But the mac version was worth it ?
Also: When puppygames finished it’s first game, how did you sell it ?
By that I mean how did you get people interested, how did you advertise your game, what were your strategies ?
Because before you publish a game, your practically unknown obviously.
And:
What kind of problems, technical or not, did you run into when publishing your first game ?
The Mac version was eminently worth it because a) it cost me zero time in support and b) we had it available for Steam where it’s made another $23k (again, with no support).
If we add in the complete fluke of being in the Humble Indie Bundle #2, we can safely say Linux was worth it too, as the Linux portion of that was worth around $40k. And this is why we continue to support Linux really. The money’s out there, there is a market, but without some rather extraordinary measures it can’t really be reached.
The story is quite well documented in the archives of Javagaming Our first game was the thrice-cursed Alien Flux, an abject failure in game design for the masses, which sold a staggering 211 copies. Yes, 211. We had no idea how to advertise our game beyond hassle a few review sites, no idea how to advertise it at all (and no money anyway), not much of a clue in general. So we spent 6 months attempting to rectify the game (duh) and subsequently we made about $3000. Epic fail!
Technical problems back in 2002/3 amounted to the size of the Java runtime environment and the immaturity of the LWJGL (I believe we released Alien Flux with LWJGL 0.7beta). In 2002/3 the size of a demo was still pretty important as a lot of people were still on 56k or ISDN and there was a lot of anecdotal evidence around at the time of a rapid falloff in the number of demo downloads as the size exceeded 5mb (yes 5mb!). As it happens we managed to squeeze the Alien Flux demo into a 5mb download by using Excelsior JET Professional with global optimisation and a bit of cunning. The full game weighed in at 10mb.
Eventually using JET got to be a bit too fiddly so I started using a sneaky cut-down JVM. Also at this time maintaining separate demo and full version builds proved to be another pain point so we removed that too and released the now ubiquitous unlockable demo. The whole game still came in at about 11 or 12mb or so as I recall, even with a JVM in it! Though it didn’t start up nearly as fast or as slickly as the JET version.
Cas
So what would be your advices to someone who is going to publish their first pc game ?
What are really efficient way to get people to know your game for free, and
if you have a little bit of money for advertisements, lets say $200, whats most effective ?