Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Galavant Garde

Pages: [1] 2 3 ... 10
Scripting / Re: Improving enemy vision
« on: February 11, 2018, 07:55:53 AM »

My game script does this:

Code: [Select]
function botRollCall(game,id)
    botRoll.push(id);   // adds ID of any bots calling this function to the checkpoint roll call. Note is only called after spawn event

function playerWatch(game)
    brightness=game.event.callPlayer('lightLevel',null);    // player script returns bone brightness
    if (brightness>0.3) inTheLight=true;
    else inTheLight=false;

    for (i=0; i<botRoll.length; i++) {
        if (distance<15000) withinRange=true;
        else withinRange=false;
    game.event.chain(5,'playerWatch');    // loops chain every 5 ticks

My bots do this:

Code: [Select]
function spawn(obj)
    obj.event.callGame('botRollCall',;    // sends ID of bot to the game script

function playerProximity(obj,inRange,inFOV,inTheLight)
    if (inRange) {
        if (inFOV) {
            if (inTheLight) {
                if (obj.sight.testPlayer()) enterCombat(obj);    // only perform sight test if game script calls saying player is in range, in FOV and in light

So far so good actually!  The only bit that isn't totally reliable is the map.object.isFacingId call - it sometimes says the player is in the FOV when it isn't within 120, and I'm not sure how the slop is calculated.  So I think I may have to make my own routine for verifying if the player is in the FOV

What I can then do is instead of triggering the combat routine as soon as the sight test passes, I can make a variable called something like 'spottedPlayer' which other functions rely on to decide if to carry on with what they were doing, or stop and enter combat. For example, if a bot is their way to get help or trigger an alarm, I wouldn't want the sight test to interrupt them

Scripting / Improving enemy vision
« on: February 11, 2018, 04:58:39 AM »
Oh hey guys, I've been working a lot on trying to improve my enemy's vision.  I've made a pretty streamlined vision routine that sequentially checks player distance, player angle, and the brightness of the player model before triggering a sight test, and this routine is called whenever the bot steps on a node.  Also if the player is 'close' according to the Watch event, the routine loops every second using a timer increasing the frequency of checks.  It works reasonably well, but I don't like feels sloppy.

The main issue with this approach is that it's continually checking for the player whenever close/touching nodes, but because these checks are occurring concurrently with other routines like movement and combat, function chains are getting interrupted.  This does stuff like bots not switching off their flashlights when they're supposed to, or kneeling to take a shot, and while in the middle of that animation starting a node run so it looks like they're sliding around on their knees or moonwalking etc.

The other issue is of course the slow refresh rate of checks means you can sometimes run past an enemy in plain sight but they don't spot you...which is kinda dumb.

So my idea was (this is where I'd love your input) instead of my bots trying to do everything at once, getting the game script to do most of the work.  So for example:

- The game script will continually refresh the brightness of the player model
- The game script has a function that can be called adding or removing bot IDs to/from an array
- The game script calls ALL bots on that ID array whenever the player model brightness indicates the player isn't in the dark
- Bots only add their name to that ID array when their Watch event indicates the player is close within a restricted angle
- As soon as the player steps outside of the bot's Watch range/angle, the bot removes their ID from the game script's callback array

The idea of this is, having only one script refreshing the player brightness is theoretically more efficient than having every bot doing it simultaneously.  It should also mean I don't have to do stuff like looping a bot's vision routine or triggering it when touching nodes (which is where I'm getting broken chains/weird behaviour from time to time).  It could also improve bot response times so theoretically you can't just run past them in the open.  It also allows me to play some sort of intense global sound effect whenever the player is out in the open, helping the player know if they're in danger or not.

Has anyone tried a system like this before?  Any tips or pitfalls you can think of?

dim3 Versions / Re: dim3 v24 Release
« on: February 01, 2018, 09:43:28 AM »
Wicked, thanks Brian!   ;D

dim3 Versions / Re: dim3 v24 Release
« on: February 01, 2018, 07:39:36 AM »
Oh hey again, where can I get the v24 source? I went to github for the first time in years to download it, but the version on there was last committed in 2009.

Idle Chatter / Re: One Of Them
« on: January 13, 2018, 04:05:25 PM »
Little update video:

The biggest thing to look out for is actually something you can't see.  It's the unnoticeable checkpoint saving and loading with no save screen or input from the player!  Less is more, plus I'm not a fan of the dim3 save screen, and it crashes a lot too.

I've rewritten the bots' vision and movement routines from scratch plugging a bunch of logic gaps and dead ends that caused odd behaviour in the past.  This has made them a lot better at filling a small space without getting stuck on each other (see up the top of the stairs in the video)

I also rewrote the math for bot aim when standing on different levels, and when the player height decreases.

The checkpoint thing is all manually scripted - was a big learning curve for me, but let's just say I'm dreaming in 'for' loops now.  The biggest issue I found with it was packing the Y angle of objects in the save data...took ages to work out that it was often freaking out because the Y angle had too many decimal places.  The way it works is, while still playing you can reload from a checkpoint smoothly, but if you quit and come back to the game later, it'll be at the start of that level. It's a tradeoff I know, but I'm pretty happy with it.

& before you say it, I know the action icon in the middle of the screen is terrible - it's on the list. Also I won't upload any more playable demos since nobody seems to try them out - will just do videos instead I think.

Scripting / Re: Scripting checkpoints
« on: January 05, 2018, 11:45:51 AM »
Meanwhile I've written a routine into my game script that constructs a 9-digit simple save ID with each number representing a different parameter.  I used a much more basic version of this with 2 digits when I made Ronja all those years ago.  Anyway I can use this to manually reconfigure the level after loading it so it works a little more like a full game save state.  At the moment it allows me to know which map, which music, which checkpoint to move the player to, what the player's health was, whether the player is carrying a rock, the player's model animation settings (he runs differently depending on what's going on), and whether bots are alerted to the player's presence or not.

It's a bit much to try incorporate stuff like enemy locations / health / if they're dead / what they were in the middle of, but I'm sure I'll come up with ways to squeeze more data in there  :D

EDIT - I rounded this bit out.  So yes I've made a simple save ID that clumps together basic data so loading a map after quitting the engine can put the player back where he was and with the same vitals / equipment, but all that remains of the bots' previous state is their collective awareness of the player...they sadly get sent back to their starting spots (because simple save IDs can't pack enough data into them to include the x/y/z/angY details of all the bots.  What I HAVE therefore been able to do is, while you're still playing i.e. you die and respawn but you don't quit and reopen the engine, the game remembers where to put all the bots and restores them fairly faithfully to their states as of the time you hit the checkpoint.

It involves using For loops in the game script that call bots sequentially to gather important vitals/stats, and stores them in arrays inside the game script. I'm then able to run more For loops to manually return all those values to every bot when the player calls the game telling it to restore the bots' old state.  Effectively, it's an auto-save that returns things essentially back to the way they were after the player hit the checkpoint but before the player died.

And it's fast!  No visible lag whatsoever - it just seamlessly puts things back the way they were.  Here's a messy look at how it works:

Code: [Select]
// SAVE ROUTINE - in player script

// Simple save ID will effectively form an array-like string - use JS string methods to read it. The positions will mean the following:

// 0 - Map              // 0 is Yard, 1 is Road, 2 is Sewers
// 1 - Music            // 0 is Prison, 1 is Prison_beat
// 2 - Checkpoint ID    // used to allow searching for the checkpoint, which allows pinpointing its map position so the player may be placed there
// 3-5 - Health         // occupies 3 places as the player default health is 200
// 6 - Holding rock or not  // 0 - false, 1 - true
// 7 - Player move animation    // 0 - Trudge, 1 - Limp, 2 - Run, 3 - Sprint
// 8 - Global bot awareness // 0 - Low, 1 - Medium, 2 - High

// When respawning without quitting, individual bot data can be restored. If loading a simple save, only the above parameters will be applied meaning
// only general data can be used to set bots up. This means their location and movement data won't restore, and they will all have the same awareness

function constructSaveString(game,x,y,z) // note the checkpoint includes its x/y/z position when calling the game script
    pos0=data.get('map name');  // this is set when the map loads
    pos0=pos0.toString();   // convert to a string - this will mean all other values added at end will be strings also
    pos1=data.get('current music');  // this is set when the music starts
    pos2=data.get('checkpoint');  // this is set when the checkpoint object spawns into the map

    playerhealth=playerhealth.toString();   // convert to string otherwise the JS slice method cannot be used

    if (playerhealth>99) {  // 3 digits
    else if (playerhealth>9) {  // 2 digits
    else {  // 1 digit

    if (data.get('holding rock')==null) pos6=0; // data container won't exist if a rock was never picked up
    else pos6=data.get('holding rock');

    pos7=data.get('move animation');  // set whenever player walk animation changes
    pos8=data.get('alert level');  // set globally by the last bot to change its alert level, default is 0


    data.add('respawn x',x);
    data.add('respawn y',y);
    data.add('respawn z',z);
    data.add('respawn angle',respawnAngle.y.toFixed(0));    // Y angle with no decimals rounded up

    for (i=0; i<botRoll.length; i++) {  // runs bot data capture for each ID stored on the roll array

    iface.console.write('auto-save complete - '+simpleSaveString);

All those calls to the bots look like this:

Code: [Select]
// This is in each bot script
function captureX(obj)

function captureY(obj)

function captureZ(obj)

function captureYang(obj)
return(obj.angle.y.toFixed(0)); // Y angle rounded up with no decimals

function captureAwareness(obj)

function capturePath(obj)

function captureMovement(obj)

function captureHealth(obj)

From that, when the player dies it calls:

Code: [Select]
// this is in the player script - attached to the Die event
function die(obj)

sound.playGlobalPlayer("Game Over",1);




function playerFallOver(obj)
    headTurn=new Angle(90,90,0);

function checkForSaveData(obj)

if (data.get('health')==null) obj.event.chain(10,'resetCamera');
else obj.event.chain(10,'resumeFromCheckpoint');

function resumeFromCheckpoint(obj)

function raiseTheCurtain(obj)
posX=data.get('respawn x');
posY=data.get('respawn y');
posZ=data.get('respawn z');
spot=new Point(posX,posY,posZ);
ang=data.get('respawn angle');,ang);'health'));


if (<50) walkSlower(obj);
    else if (<100) walkNormal(obj);
    else if (<150) runSlower(obj);
    else runNormal(obj);


musicID=data.get('current music');
switch (musicID) {
case 0:

case 1:

if (checkpoint1) checkpoint1=false;

You'll see in that second bit, the player calls the game after dying:

Code: [Select]
// this is in the game script
function playerHasDied(game)
    for (i=0; i<botRoll.length; i++) game.event.callObjectById(botRoll[i],'stopAllActivity',null);

That cycles through every bot telling them to stop what they're doing.  After they're all done, the player calls the game asking it to do this:

Code: [Select]
// this is also in the game script
function restoreBotState(game)
    for (i=0; i<botRoll.length; i++) {
        if (botHealth[i]<1) iface.console.write('skipping restore of bot '+botRoll[i]+' because he is dead');
        else game.event.callObjectById(botRoll[i],'restoreState',botX[i],botY[i],botZ[i],botYangle[i],botAlert[i],botPath[i],botMove[i]);
    iface.console.write('all bots restored');

Which checks the health the bot was saved with.  If it has no health, it won't bother restoring its old state because it's dead so hasn't changed state.  If it WASN'T dead at the time of hitting the checkpoint, it reconstructs all of the saved data and packages it up into a call to each bot script sequentially:

Code: [Select]
// this is in each bot script
function restoreState(obj,x,y,z,angY,prevAwareness,prevPathID,prevMoving)

spot=new Point(x,y,z);,angY);

switch (prevAwareness) {
case 0:

case 1:

case 2:
pathID=prevPathID; // revert to previous path iD
if (flashlight) useFlashlight(obj,false);
if (prevMoving) resumeInterruptedPath(obj); // if moving, resume previous path
else if (pathID==null) spawnOntoMap(obj);
else whereToNext(obj); // if not moving, decide on a new path based on previous awareness

Moral of the story?  There's always a way, even for coding noobs like me

Scripting / Re: Scripting checkpoints
« on: January 05, 2018, 09:34:11 AM »
Simple saves work great; it's the entire game state saves that I'm getting stuck with.  So is the map.action.restartMapFromSave(); a command intended for simple saves then?  I assumed it must be for the full game state saves.  If it is for simple saves, would it for example reload the map while simultaneously returning the simple save ID or something like that?

Scripting / Scripting checkpoints
« on: January 05, 2018, 08:30:37 AM »
Oh hi me again, so I've implemented Dim3 checkpoints for the first time (I always just used to use my own manually scripted checkpoints for simple save stuff) so that I can get my game to auto-save.  It seemed to work OK at the beginning, but now I'm getting problems with it.  I noticed when you load a game from a checkpoint, the checkpoint is still there after loading, triggering another save event in the same spot.  So you end up with near-identical saves in the same spot for each time you load it.  Also this saving-right-after-loading-because-the-checkpoint-is-still-there thing often causes the engine to crash.  Is there a way to add a script to the checkpoint that prevents it from re-triggering after loading the save file?  Or something in the engine/editor that removes triggered checkpoints from save files?

Alternatively, is there a command I can run that triggers the auto-save event?  That way I could get the game to save without bringing up the Save Game interface WHILE simultaneously avoiding the above checkpoint issue altogether?

Also the map.action.restartMapFromSave(); API isn't working for me - it just restarts the map even though there is definitely a save file.  Other times it comes up saying something about it can't find the spot '-Player'

Hopefully it's just something I'm doing wrong.  Sorry for all the questions - I know I'm the only one really posting anything these days but I'm really fond of Dim3 and want to keep using it

dim3 Versions / Re: dim3 v24 Release
« on: January 04, 2018, 04:34:46 AM »
Not sure if it's worth mentioning, but I think I found a v24 camera bug.  When restoring a save file, it restores the camera state from when you hit 'load' rather than when you hit 'save'

I came across it because when my player dies, the camera pans away at an odd angle.  So at full health with normal camera settings, I hit 'save', then I run out into the open then get shot.  When I die, the camera pans to the odd angle, and the 'load' menu appears.  Except when you hit the 'load' button to resume from when you had full health and a normal camera angle, it restores everything else normally but that weird camera angle stays.

Easy enough to make a workaround - I just reset the camera angle right before the 'die' event triggers the 'load' menu to open.  I'm really happy otherwise with how well the game state saving works - I remember older versions (years ago) that did all sorts of weird and unstable stuff.

Idle Chatter / Re: One Of Them
« on: January 03, 2018, 11:04:23 AM »
Hullo guys, first update for the year, and it's a big one!

Firstly, here's the updated link:

This update introduces:

- new sneaking ability
- redesigned prison map with various nooks/hiding spots
- redesigned ray lighting
- automatic health recovery
- automatic camera height adjustments when theres low ceiling clearance
- more scenery
- refined vaulting over ledges
- can now vault from the sneaking/crouching position

The way these things all work together completely changes the feel of the game. To me it's starting to feel like an actual game now ;-) the sneaking and hiding behind stuff element is much more prominent, and it actually flows well. The bots are pretty formidable, and much better at working together. The ray lighting makes things not only look better, but being able to see the light makes creeping around and avoiding light so much more doable.

Feedback please  ;D be brutal, I can handle it

Idle Chatter / Re: One Of Them
« on: January 01, 2018, 05:35:19 PM »
Will drop an updated link in a couple days - so far have added in auto-regenerating health, sneaking mode that doesn't make footstep sounds, bots can get scared and run off if you catch them unawares, got rid of the ugly snorkel vents and put some proper drains in that are actually visible and useful during gameplay, fixed a few dumb node-path errors with the bots, things like that. Still need to make melee more interesting, and probably add a bit of code where if you're hiding somewhere and they saw you in that area they stick around and search for a bit longer and more thoroughly

Idle Chatter / Re: One Of Them
« on: December 27, 2017, 05:39:24 PM »
Update on the way - I'm adding the ability to creep around so bots can't hear your footsteps. It's kinda a crouched walk. Also am furnishing the levels with more decorative stuff to hide behind and more decorative stuff to make it look better in general.  Also cutting a few vents out of walls and creating more escape routes so it isn't just a gauntlet slaughter fest.

PS check out how much nicer it looks - remember the first few screenshots I posted?

Idle Chatter / Re: One Of Them
« on: December 26, 2017, 03:32:31 PM »
Ok I've got a demo for you to try out:

Been working hard on this - the enemy AI is probably the toughest I've ever built.  You really gotta creep around otherwise you don't stand a chance.  What you'll notice they do is:

- give chase when you try to bolt
- keep tabs on nearby bots so they can run to them for help when in trouble
- respond to different sounds in different ways
- change behaviour depending on if they know you're there or not
- keep an eye out for friendly fire
- literally kick you when you're down
- get sad when they find a dead bot

They're also much better at long-distance shots than before.  Now, while they do chase you pretty hard when you try to run off, it IS possible to lose them if you duck down in the dark behind something. So keep tabs on hiding spots you find as you go along.

Please tell me if you manage to get into the sewers under the bridge - I'm curious if the bots are too easy or too hard.  Also I know I'm going to need to add more places to hide, and more abilities for the zombie (like maybe hiding in a box and pushing said box around, could be fun) but for now please tell me what you think of the progress

PS if you get sick of the fit on the operating table scene, open the console and enter 'skip' to jump ahead to when he falls out the window and starts playing.  Also there is one action button, one melee button, and one crouch/hide button you'll need to set

Good luck  8)

Idle Chatter / Re: One Of Them
« on: December 21, 2017, 11:01:58 AM »

Idle Chatter / Re: One Of Them
« on: December 18, 2017, 03:31:42 PM »
Latest update - working on enemy AI, and I've just figured out a neat way of getting bots to keep tabs on which other bots are nearby, and whether they're aware of the player's presence or not.  By them keeping in contact in this way, if one spots the player but is too far away from other bots to just yell out for help, they will take a shot, then run to go get help!  It works really well!!

Once they've gotten help, they won't try it again until after they've lost the player and had sufficient time to calm down (this prevents disruptions to their combat routines - it'd be silly if they kept running off for help all the time).  Also, they won't run for help when the nearby bot/s are already aware of the player, as chances are they're already engaged in battle or are frantically looking for him.

It's pretty neat in action - I want to upload a build soon so you guys can try it out!  There are 3 playable maps now btw  ;D

Pages: [1] 2 3 ... 10