Survivor - first alpha!

[darkprophet]

<ThreadJack> has anyone seen agency9's entry? Its brilliant, multiplayer Quake III in java! its actually better than quake! If only you managed to hook it into GrexEngine! If only....</ThreadJack>

[Herkules]

<ThreadJack> has anyone seen agency9's entry? Its brilliant, multiplayer Quake III in java! its actually better than quake! If only you managed to hook it into GrexEngine! If only....</ThreadJack>

GrexEngine .... they definitely need HeadQuarter!

[blahblahblahh]

Ack, they need webstart first! No idea if it's suitable for GE because they only distribute a ZIP, which is more hassle than I can be bothered with

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

[darkprophet]

lol, i wasn't talking about GE with Agency9, i was talking about Survivor with GE. Should have made myself clearer I suppose.

[moonpxi]

Sigh...this is getting pretty fun!! And I MUST stop playing it!!

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".

[princec]

I don't like monsters with brains. It takes all the fun out of killing them.

For lessons in this kind of gameplay learn from the masters:

Robotron
Gauntlet
Doom
Crimsonland

All brain-dead! Brilliant.

Cas

[blahblahblahh]

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 /

[moonpxi]

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.

On a second though, leave the AI as it is!! I am already having a hard time now.

[MickeyB]

wow, spend a week moving to a new home and miss seven pages of chat on a new game!!  dang!  Will play when I get home!

[blahblahblahh]

I've put up a basic manual on the website; not much extra added, but will probably add more details to it over time.

DP: mail me on ceo @ grexengine.com if you're serious about having a go with the editor; it's not really ready for use yet, but if you're brave I'll try and get you started as an experiment.

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

[moonpxi]

blah*3: do you mean the survivor level editor??

[dimmengestel]

This game is really great,
nice 3d environment,
and also the alpha blending texts
maybe some background music would be nice.
keep it up!
check also my site  

http://members.home.nl/dimmengestel/Games.html

[MickeyB]

very nice game, ran very smooth.  athlon 1.1, 512 ram 1.4.2, win 2k

and once again...you see what can be done, compare it with my own and ... phooey!  back to coding!  

[blahblahblahh]

(from another thread, that veered off topic towards survivor)

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.

[oNyx]

Thanks for clarification

So... are there plans for adding gamepad support? (dual analog stick that is )

[blahblahblahh]

Thanks for clarification

So... are there plans for adding gamepad support? (dual analog stick that is )

Right now there's no plans for anything but Kev and I both want to add JInput support (that's right, isn't it Kev?)

[kevglass]

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.

Kev

[swpalmer]

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.

[blahblahblahh]

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...

[kevglass]

Yep, I've got one! Testing is going to be FUN!  

Kev

PS. its not going to be for a while tho  

[oNyx]

Great

And... uhm... I donate(*) one of my photobased seamless textures:
http://kaioa.com/temp_img/stein_kacheln3b.png

(* Survivor only)

Hope that one fits somewere, since I can't use it for anything right now (or within the next year).

[blahblahblahh]

Nice. Thanks! Which reminds me, need to add "user contributed level packs" to the wishlist...

[darkprophet]

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?

Btw, i emailed "ceo at grexengine.com"

DP

[blahblahblahh]

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.

[blahblahblahh]

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...

[darkprophet]

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.

DP

[darkprophet]

blah and the team, would you consider open sourcing this game?

DP

[blahblahblahh]

blah and the team, would you consider open sourcing this game?

I thought we'd answered this before, but the key question is "Why should we?". I've not yet heard any argument that gives a good reason for doing so...

[Herkules]

Hm, the reason to make FG opensource was that as opensource project, the whole effort MAYBE hasn't been completely wasted.

But of course that's a different case, bc. nobody ever asked for it to be open

[darkprophet]

my reason so that you should is three fold:

So that I can:
1) Learn AI integration into game logic
2) Learn Editor creation
3) Learn how to integration BeanShell into game logic

Those are my main points that I would like to investigate and all three are found in survivor.

It will give rise to other games that uses the survivor code as a reference rather than creating and improving the game.

DP