- How do you handle path finding? - What sort of AI do you implement?- How do you tune the CPU player?

It's an A* pathfinder (see source code). The implementation uses packed integer coordinates as an optimisation (ie. nodes in the path are identified by a single int which holds the x and y coordinates) to avoid excessive object allocation, though I still create a lot of actual Nodes.

The pathfinder executes a maximum of 512 steps per frame to keep a lid on execution time. This is done with the entirely pragmatic method of a static step count in the GidrahMovement class which I reset to 0 every frame.

The pathfinder finds its way around the map using a Topology which describes the cost of moving from one grid location to another for a particular alien. Certain aliens move diagonally, some fly, etc. There are a few "tricks" in the topology like making the cost of moving through a bunch of other gidrahs more expensive, which has a subtle declumping effect.

Beyond the pathfinder the AI is braindead simple. Each gidrah has a "target" building which it heads for. There are 3 basic brains for choosing targets. The dumb one just heads for a random "apparently valuable" building (the base or a decoy). Clever brains choose the nearest building and attack it. Tactical brains apply various weights to refineries, turrets, and bases, and choose the nearest. Then they simply collide with anything in their way along their chosen path and attack it.

The paths are influenced by the danger level - some turrets increase the "danger" on grid tiles nearby. Gidrahs that die also increase the danger level on the tile upon which they die. This means if they are walking headlong into slaughter they will eventually realise it's unsafe and might pick a different path.

Tuning is all by trial and error. The behaviour you see is all basically emergent, unplanned, and the result of months of subtle tweaking.

- How does your "main game loop" work?- Do you use delta timing or fixed time step (frame based)?- Do you have different mechanisms for game logic updates and render loop?- Do you use multithreading? If so, why? If not, why not?- Do your games use a fixed resolution?- How do you deal with different desktop screen resolutions, especially wide screen support or tiny screens on netbooks?

- How does your "main game loop" work?- Do you use delta timing or fixed time step (frame based)?- Do you have different mechanisms for game logic updates and render loop?- Do you use multithreading? If so, why? If not, why not?- Do your games use a fixed resolution?- How do you deal with different desktop screen resolutions, especially wide screen support or tiny screens on netbooks?

The basic idea behind the main loop in my games is, it ticks the game logic at 60Hz, and I update the screen at the same rate. However, I keep a hi-res timer going, and work how many logic ticks I'm supposed to have done in total since the last clock reset. When that drifts, sometimes I do 0 ticks, or sometimes a few extra logic ticks, up to a maximum of 5 (when basically the game is running flat out and can't cope). The game loop in its entirety is here:

So basically: I use fixed timing at 60Hz but only update the display at a maximum of 60Hz. This keeps everything really simple and means I don't need to worry about float time deltas and so on - the game is simply hard coded / designed to run at 60 frames per second.

I do use multithreading but only for background tasks. The JVM is already making some good use of threads with garbage collectors and background compilation; I use them to stream music in the background, and for async remote calls, and async preference saving. I'd use another thread to do calcs such as AI but when I started this game less than half of all PCs had 2 cores; now well over half of them have 2 or more cores so the next game will probably feature multithreading to perform AI more efficiently. The architecture of a multithreaded design is pretty complex - especially as it has to work precisely as well on a single-core machine as a multi-core machine.

We no longer use fixed resolution graphics; Revenge is the first title of ours that simply uses the desktop resolution, and applies a scale to it (can specify scale=2.0 etc on commandline to experiment). By default we divide the smallest dimension by 320 and round down to get the scaling factor. All our UIs are designed around the notion of a logical 320x320 display, but the widgets are anchored to edges of the screen or the middles, and can move accordingly. There's nothing really in theory stopping me from using an AWT window and allowing dynamic UI resizing actually. Hm. But that's how we can cope with any game resolution. The scale factor is always rounded to an integer unless manually specified on the commandline as stretching things to 1.5x gives slightly crappy artifacts and ruins the crispness of our pseudoretro graphics.

<edit>Notes we can specify the framerate to be anything in that code but 60 is best. Also note that we use a busy yield() loop on dual-core or better processors and a sleep() loop on single core processors. It can also be forced to sleep() on the commandline.

1. Molebox.. and, er.. no Though not for much longer. Steam won't be Moleboxed, nor the next release of Revenge, as I want to make it easier to mod and patch.

This might be a dumb question because you just posted the source code on this thread. But as indie how much do you worry about people cracking the game and running it with out paying. Is there any sleep lost to try to obfuscate code since Java is a lot easier to decompile then say C++.

Are there any examples where some more design would have saved you a lot of rework and heartache later on? Do you have counter examples where you spent too much time planning and ended up having to rework because you wrote the wrong thing? Any specific areas where you would recommend one approach over another?

1. Molebox.. and, er.. no Though not for much longer. Steam won't be Moleboxed, nor the next release of Revenge, as I want to make it easier to mod and patch.

This might be a dumb question because you just posted the source code on this thread. But as indie how much do you worry about people cracking the game and running it with out paying. Is there any sleep lost to try to obfuscate code since Java is a lot easier to decompile then say C++.

I lose no sleep at all over it. The game's already torrented to hell and back and I figure that anyone who goes out of their way to find a crack really isn't going to bother giving us fifteen lousy bucks. Maybe I don't begrudge them as they'll lose far more than that when their bank account is hacked from the keylogger that the torrented version installs but that's their business*

Our next game is going to be online so I'll sleep even more soundly at night. Or at least I will when I find a Java API for dynamically manipulating Linux firewalls. I expect I'll write one that just shells out to ufw.

Cas

* actually it turns out warezbb actually manages to install a keylogger just by surfing to their home page. Pretty impressive stuff. WARNING do not go there unless you have a spare VirtualBox you don't mind losing.

What are your thoughts on waterfall vs agile i.e. up-front design vs iteration?Are there any examples where some more design would have saved you a lot of rework and heartache later on? Do you have counter examples where you spent too much time planning and ended up having to rework because you wrote the wrong thing? Any specific areas where you would recommend one approach over another?

A full post-mortem would be a good article to write for the blog to talk about all that, so I'll get cracking on that I think. Basically, we do have a very iterative approach to development, and release frequently and as early as we can without it looking utterly rubbish. Early feedback is good. Droid Assault and Revenge of the Titans were heavily shaped by player feedback.

That said, we totally scrapped Revenge three times in a row. I just couldn't get a fun game out of it until fourth time lucky. It started off as a single-screen, non-scrolling, 320x320 game like Titan Attacks, set in the dark with lots of lighting, and a very simple mechanic that now I think about it would probably work quite well on iOS. However we scrapped it because it probably wasn't going to make much money, being the kind of entertainment found in Flash games all over the internet. Then we tried a game with graphics fairly similar to the current ones, but with no "terrain", and just a constant spawn of aliens, and you manually aimed the turrets with the mouse. We got really far with that and were almost going to release a demo... except the gameplay boiled down to simply rotating the mouse around the screen and watching the monsters die till you got bored. Then I got cold feet about the whole graphics thing because everyone told us that's why our games don't sell, so I tried medieval wizards in towers casting spells at gobboze, but that was kinda pants and didn't fit the rest of our games. So that got ditched, and I tried another prototype, again without scrolling, where the turrets did all the shooting themselves. That one grew and grew into what you see today as the current game through some particularly torturous continual extreme refactoring. So you could say waterfall or agile or not, it's definitely the product of XP mantras. I'm not sure this approach would work with a bigger team as they'd get really annoyed.

What were the major performance bottlenecks you experienced and what solutions helped you overcome them?How solid is your math background?

Various dumb implementations of algorithms that didn't scale well such as turrets targeting gidrahs every frame, etc. Quadtree was a crappy choice of collision manager as nearly everything is roughly the same size or smaller - changed that to a cell based collision manager, got loads more performance. Had to switch to VBOs to get necessary sprite performance (pushing thousands of sprites per frame now). Various tweaks and hacks required to make sprites invisible when offscreen (things like emitters which are way offscreen are turned off for example). There's a bit of poorly conceived code that colours the entities according to their distance from the centre of the map which should really have been precalculated. In fact I may still do that. That's the biggest performance bottleneck I think!

The biggest bottleneck I've been unable to control is Java bounds checking. Java 7 gets some performance boost in this area but nowhere near enough. This is a guess based on what I think the average C++ application would manage, sprite-wise.

We should probably have a sprite shootout sometime eh? I've got quite a nifty sprite engine.

Various dumb implementations of algorithms that didn't scale well such as turrets targeting gidrahs every frame, etc. Quadtree was a crappy choice of collision manager as nearly everything is roughly the same size or smaller - changed that to a cell based collision manager, got loads more performance.

I guess I won't bother implementing that octree collision manager then

The sound that plays when the player ship appears in Alien Flux always reminds me of the beginning of the extended version of The Cure's "A walk". Is that just me or was the sound borrowed/inspired by it?

Given your avatar I'd bet you have some good ol' The Cure records in your shelves

Oh and btw: I would love to buy Alien Flux and Super Dudester nowadays cause I loved both games when I played the demos years ago (but couldn't afford them)...

One more question because it's nagging me for years now:The sound that plays when the player ship appears in Alien Flux always reminds me of the beginning of the extended version of The Cure's "A walk". Is that just me or was the sound borrowed/inspired by it?Given your avatar I'd bet you have some good ol' The Cure records in your shelves Oh and btw: I would love to buy Alien Flux and Super Dudester nowadays cause I loved both games when I played the demos years ago (but couldn't afford them)...

It is indeed a slightly granularised sample from A Walk (And the Jellie's maniacal laugh is from Lucretia by Megadeth). I'm not sure what to do with Alien Flux and Dudester at the moment as they have succumbed to code entropy for years and need a bit of refactoring and bashing with a hammer.

1. Where did you learn lwjgl?2. When you start learn lwjgl, what kind of PC that you used? I have an old Duron and mx400 so I can't learn lwjgl 3. Do you have any simple java2d game (beside RTT etc) that you can share with source code? the previous source is too scary for me4. Have tried pulpcore? what do you think about it?5. Your university?

1. Where did you learn lwjgl?2. When you start learn lwjgl, what kind of PC that you used? I have an old Duron and mx400 so I can't learn lwjgl 3. Do you have any simple java2d game (beside RTT etc) that you can share with source code? the previous source is too scary for me4. Have tried pulpcore? what do you think about it?5. Your university?

1. I started it 2. See #1. I had a TNT card originally. That was in the days of Java 1.2. By the time Java 1.4 came along, with ByteBuffers, I'd gotten a GeForce 1 with a dual overlocked 300Mhz celeron motherboard. 3. Not any more. We did have game called Puppy Invaders once on our website (an applet), but I didn't write that and it's slightly crappy code too. I never got into using Java2D because it was just too random as to whether we'd get any performance out of it.4. Nope, but I've seen the results and I'm impressed.5. Reading University, England, nearly 20 years ago now (Where did the time go?) Very inauspicious. I nearly went to Durham but turned them down, for some reason. Maybe for the best, as I didn't learn a thing at university. I spent the entire 3 years pissed and stoned out of my head. When I got a degree at the end of it the Dean of the Science Faculty came over to personally shake my hand, stating, "Well done, you've made a mockery of the examination process."

5. Reading University, England, nearly 20 years ago now (Where did the time go?) Very inauspicious. I nearly went to Durham but turned them down, for some reason. Maybe for the best, as I didn't learn a thing at university. I spent the entire 3 years pissed and stoned out of my head. When I got a degree at the end of it the Dean of the Science Faculty came over to personally shake my hand, stating, "Well done, you've made a mockery of the examination process."

I was wondering if any more beginnery types might have some more technical questions?

Cas

Well, I totally 100% fit the bill in the "beginnery" aspect. I've been programming in Java for 1 year and I'm currently a full-time firefighter and computer science student. Like many others (I assume) Android has brought me to Java.

That all said, I have some (perhaps general) questions that may be painfully obvious...but I' would like to see the answers none the less.

1. When programming, before you became a wizard(when you were in the everything isn't obvious stage); How did you go from idea to implementation?

2. Do you program to the UI or do you program and then design the UI around the code?

3. How do you keep track of code in big projects? I realize that "big" is subjective, so... how do you keep your code organized?

4. Where do you think programming is going? More abstraction, or less ala App inventor/Scratch or scripting?

5. When working on a project, do you skip around or focus on one task until its completed?

6. DVCS or SVN?

7. Do you have any programming "aha!" moments that you can share?

8. To get started in Game programming, how should I think compared to utility or "regular" business type programming?

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org