Anyway, I am having a hard time figuring it out which type of player is more useful. Being fast is extremely important, but shooting fast is as much when there is a BIG crowd following you.

I was thinking, every "sort" of monster has the same AI for chasing the player? It appears so, since they all seem to chase after me, even with blocking wall and, sometimes, they do some kind of "dodge". It might be fun, and harder, to have different kinds of behavior from the enemies. There might be some who go straight at you, others who tries to encricle, and so one. Of course, it might be a bit difficult to program this.

Oh, there are very minor bugs now and then. There are rare times when an enemy get out of the "playing field".

It might be fun, and harder, to have different kinds of behavior from the enemies. There might be some who go straight at you, others who tries to encricle, and so one. Of course, it might be a bit difficult to program this.

Each mob can have it's own unique AI already (AI is scripted, so adding new ones is quite easy). At the moment, we only have 3 mob AI's (which is pretty good considering that 48 hours ago we only had 1!), and one of them is a fair bit faster than the others, so Temple mixes all 3 freely to improve performance.

Temple needs some serious rebalancing - the new AI's caught me somewhat on the hop, and the level balance has been broken (although I also haven't had time to re-balance for the stuff we added to kill DP ).

If we taught monsters to encircle you any more effectively, then you would have a snowball's chance in hell of completing the harder (not even the hardest) rooms. As it is I am using Dave's latest mobscript sparingly: he occasionally nominates "champions" who get angry and decide to dodge the queue: they speed up, leave the crowd, and come after you with some serious attitude.

But...maybe once we add powerups we'll need the better AI to keep it from getting too easy /

On thing I don't understand - why does the level editor of survivor uses floating point? That just doesn't make any sense - especially if the coords are relative to their room. I just use 32bit ints and that's really good enough (there is no way that I could ever build a level wich goes beyond those bounds [most likely I'll die in about 40 years - so there just isn't enough time to do that]).

For example the levelbounds in GTKRadiant (a q3 level editor) are 2^16 units in each direction. Doesn't sound like much, but the levels can be really really huge and a single unit is somewhat like 1cm. So just think about the scale and build it accordingly. If the player is 32x32 units he would fit into a map with int bounds over 130 million times on one axis. Walking from one side to the other actually takes several days. No one would ever build something like that

As Kev pointed out, the level editor actually re-uses the code that runs the internal data structures for the game. Yes, this is entirely deliberate: our core data-structures, our level loading, etc are all bundled entirely separately and compilable without any of the renderer or rendering APIs (e.g. Xith, JOGL, etc), and so if e.g. I find a bug in the level-loading when doing the editor, I can fix it and the game benefits. Or, if I add a new feature to the editor, altering the file format to include it, that feature is instantly available in the game, *without recompilation*, especially useful to all the scripted AI etc which can simply start using it straight away.

It's worked out really well to work this way - we have an elegant set of core interfaces (now running at 10 classes I think) and an entirely self-contained level-loading system with implementations of 90% of those interfaces, that can be shared between any apps. Interestingly, the level-loading is generic enough to be able to load levels for almost any 2D game (although several parts of the file format are unimplemented in the load/save classes simply because we didn't use them in the end - but if we added that code it would be very generic).

Onyx wondered why we went with floats...well, originally we didn't. It was int's (and for similar reasons as those that Onyx gives for using them). But then Kev joined at the last minute, so to speak, and built a new renderer from scratch, and floats were just easier for him to work with - and it was fairly easy to make that change throughout the code.

Because we're using floats, accuracy is a problem, so we have a multiple-layer co-ordinate system: each room has a private co-ordinate system where each unit is approximately a couple of inches, whereas the level itself (where the rooms are positioned relative to each other) has a co-ordinate system where one unit is approximately 3 feet. This gives us huge levels without loss of float accuracy. Because the co-ord systems are decoupled, you simply work in the space of your current room and it is effectively like translating to the origin, since rooms tend to be built centred on their local origin, and float accuracy problems mostly disappear.

Finally...yes, we might move back to ints at some point. But there seemed very little benefit at the time (since the rendering layer was having to use floats to OGL anyway), and if it saved Kev some time on the renderer implementation that was far more important.

Surprisingly after the last week of pain, yes.. I had JInput support in martian madness and the controller infrastructure for Survivor is very similar.

I think it would add to the game being able to play on a joypad. The only worry I have is that analog sticks are "analog" and hence how you record what is currently a digital mechanism (i.e. 8 directions). It would be easy enough to support the buttons for movements and firing. However, using the sticks is going to take some thinking about.

It is easy enough to compute the 'slope' of the analog sticks x,y vector and divide that into 8 regions. The cool thing would be if you allowed movement that followed the true direction of the stick though. Though most gamepads have a digital direction pad anyway. Dual stick gamepads would of course be great for this game - with the split move/fire directions.

I'd be tempted to buy the necessary gizmos to plugin a ps1/2 analog controller if we supported 360 stick movement (nb it's already there in the code as support for arbitrary mouse directions). There's some links to these converters on the JInput HCL page on JGF (Technologies section) and the reports I've had were that they worked fine...

hey blah^3, i emailed you about a week ago for the survivor editor, and you haven't replied, have you changed your mind? or are you just busy?

Just been too busy I'm afraid. There's a non-trivial amount I need to do first, like update the instructions so that you have half a chance. I had some optimisations to try out too, which I've done now, so maybe at the weekned I'll get time to finish off.

We've started brainstorming new features and development plan now. I know Kev's been catching up with other stuff, and I've got an article and two book chapters to write within the next 5 weeks, so we're still kinda busy in our freetime already .

In the meantime, I wondered if there's any cool features you'd like to see, or any things you've noticed in the alpha that really irritate you. This would help us prioritise what to do next, and we might be able to get some of your ideas into the game...

couple things that would make the game a whole lot better, and possibly percieved as harder.

#1, Soft shadows, like S-Type, those were just plain cool. And Lighting would also come into play i suppose.

#2, Flock behaviour perhaps? I noticed that the zombies had no relation to their surroundings. A* path finding perhaps?? And something that would be seriously cool? Collision Detection between the zombies too, because i can make them gather around a corner at the exact same spot, move the player little, and make one zombie come at me at a time, shoot them, then do it all over again.

#3, The bullet is horrible! Something like the bullets in Call Of Duty which are simple yellow lines with one end being completely yellow, the other, is completely transperant. That would be awsome.

Btw, ive broken your current AI routine down too. This is what im percieving is happening:

Find the angle between the zombie and the player, make the zombie head towards the player at the angle, if you encounter a wall, go back to the last location.

Im sure its better than that as your AI dude spent ages on it, but thats how it is percieved.

Just general stuff like that. A boss would be good, I was thinking a mutant slug?? with slime going everywhere!

#4, a multiplayer option would be fantastic, but im sure that wont be easy to make as the previous comments, so I wont be expecting that anytime soon.

If want a hand in making any of the above, im more than happy to help.

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