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.

Topics - Galavant Garde

Pages: [1]
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?

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

Scripting / More with Sight Tests
« on: December 18, 2017, 05:37:48 AM »
Hullo there (probably one for you Brian), so I remember once upon a time you could set how many rays and which angles/offsets etc for sight tests, but that's all gone now under a simplified but much better sight test command.  But, I don't really get what it does so I'm not sure what's the best way to achieve what I'm trying to achieve.

Let me explain ;-) I normally do sight tests when my bots are looking at the player.  As a result, they work fine!  However, I want my bots to have better peripheral vision, not just when they're staring straight at the player.  So what I do is start a watch event on the bots, and when the player is near, it starts a looping chain that checks the angle to the player.  When the angle is within what I think is a reasonable angle for the bot to see (it's like 120) I then do a sight test to see if the player is in the line of sight.  Now, that works fine when the player is dead ahead, but when they're off to the side a bit, the bots usually don't spot the player.  The result is, you can make a break for it out in the open where a bot 'should' be able to see you, but the sight test misses most of the time so you evade them far too easily.

What I did to stop this from happening is, quickly turning on the facePlayer command while doing the peripheral sight test, then turning it back off.  This works, and they're better at spotting the player, however they do this annoying twist at the player then back where they were facing for a split second...i.e. it looks gumby

To make sure I'm using it properly, how does the sight test actually work?  And is there a way to get the sight tests better at peripheral vision checks, or am I best off making my own sight projectiles and offsetting the angle they fire at by checking the angle to the player?  The latter seems manual and clunky, but I'm pretty sure I could do it.

Scripting / Getting angle to a node
« on: December 07, 2017, 10:55:50 AM »
Hello there,

So I'm getting an error when I use map.node.getAngleTo(id); because it says it needs 4 parameters but can only find one.  That's when I put the ID of the node I want to get the angle to in the () brackets.  Am I doing it wrong?  Or is it maybe the documentation is for an older version of the command and needs to be updated?

Here's what I'm doing:

Code: [Select]

The second line throws the error about parameters.  The reason I want to use this command is to check if the nearest node is behind the player.  I'll then check the next node in the path to see if it's also behind - if one is in front and the other is behind, I want the bot to skip the first node and start the path from the 2nd node.  That way they won't slingshot from one node to the next i.e. spin around to walk to the first node, then turn back around to walk to the second if you know what I mean

Idle Chatter / One Of Them
« on: December 27, 2016, 02:19:30 PM »

I finally have a name I'm happy with for the zombie game, also Dropbox is about to change Ts & Cs meaning all the pictures from the previous thread will disappear, so time to start a new thread I guess (images won't vanish on this one because I'm using my own website server)

I'll post updates and info here from now!  Currently working on making the zombie look meaner/better - the above artwork is just a quick experiment

Scripting / Firing from centre VS firing from bone
« on: March 11, 2016, 04:48:58 AM »
Oh hey guys, I'm having a little issue with enemies firing accurately.

I want my enemy fire to spawn particles while flying through the air so you can effectively see the bullets.  Think like the small rings you see on the Matrix when they're shooting in slow motion.  Anyway, the effect looks pretty cool, but the problem is when you set the enemy to look at the player, and set 'look' to affect weapons, it means the angle the object is facing (which is directly at the player) becomes the same angle the projectile is fired from.  This means if you're firing from the centre, it'll hit the player...whereas if you're firing from the enemy's gun (which in my case is held up to the left shoulder) the bullet always flies over the player's shoulder too.  Basically, the bullet travels parallel to the line of sight hence it never hits.  To mitigate it I added a slop to the projectile, but it hardly ever hits and is still too inaccurate.

Is there any way to set the look origin to a bone?  Or to have a static projectile slop so I can aim slightly inward to intersect the line of sight and hit the player more often?  I'm still trying solutions so if I work one out I'll post it.  Open to any suggestions  8)

Idle Chatter / new Zombie game :-)
« on: January 27, 2016, 02:34:18 PM »
Oh hey, I've been doing weekly scripting lessons with a few of my friends teaching them how to make stuff with dim3 so hopefully you'll see some more contributing members joining the forum soon ;-) I was inspired when someone told me "unity is the future" and I'm like "lies!"  My new recruits are keen to get coding/building so we're going to work on a project together.

I'm working on a new enemy AI (much better than anything you saw in my old Ronja game) so that enemies can work together as a team, environmental things have a greater impact (stepping on broken glass makes noise, the speed that you walk makes more/less sound, enemies use node IDs to know how to interact with the environment (ducking/hiding etc)) and I'll be testing it using my old Ronja assets.  When the AI is solid (it's pretty stable already; enemies are able to amicably decide between them who should step out of the way to let the other past when crossing paths) it's map-building time!

The game concept is the opposite of a regular zombie scenario...there's just one zombie, you're it, and all the humans are trying to hunt you down and kill you.  So it's a stealth/evasion game where you're presented with moral choices along the way and there will probably be a human in there to takes pity on you and tries to help you.  Also, enemy and object layouts will be random so no two runs of a level are ever the same, and you'll use things like perfume to hide your stench and makeup/clothes to disguise yourself.  Anyway I can't wait to show you some stuff - I'll keep you posted

Wanted to post this as I'm curious what you guys are working on and I also want to see more things come out of dim3 so best to set an example myself ;-)

Scripting / walking VS running
« on: January 09, 2015, 06:37:36 AM »
Oh hai again, you know how you can set an object's walk speed and their run speed separately?  Well, I can't quite work out how to get an object, say an enemy, to switch between walking and running.  There's an obj.motionVector command for walking to nodes, but none for running to nodes.  Also there's an obj.status command that lets you know whether the object is running, but not one to let you know if it's walking.  Is it possible to get an object to switch between walking and running?  Or will I just have to manually set the object script to change obj.forwardSpeed.walk depending on if I want it to walk or run?

Engine / Ragdoll?
« on: January 05, 2015, 12:04:01 PM »
I'm sure I can remember rag doll mode being a new Dim3 thing once upon a time but I can't seem to find it in the it still a thing?

Scripting / Onscreen messages for multiple item pickups
« on: December 15, 2014, 05:13:46 AM »
Hi there, slowly getting back into this and thought I'd start out sharing a little script I came up with this morning to resolve a problem I've had for a long time.  Say you pick up an item in game and a message is displayed on screen saying what it is...great!  But then say you pick up 3 items within a short succession of one another...if the display text changes as soon as you pick the new item up then the display telling you what the old item was will disappear too fast to read.  The solution is using arrays :-)

So I have one script that controls all of my onscreen messages that looks like this:

Code: [Select]
// By Cayelan Mendoza


var displayingMessage=false;
var msgArray=new Array(0);

function startup(obj)

// Receive call

function displayMessage(obj,id)

    if (!displayingMessage) show(obj);
    else obj.event.chain(10,'show');

function show(obj)

    if (msgArray.valueOf()==0) obj.event.chain(30,'end');
    else obj.event.chain(20,'show');

function end(obj)

// Message sounds

function playSound(obj,idy)
    switch (idy) {
    case 1:
    case 2:
    case 3:
    case 4:
    case 7:
    case 8:
    case 9:
    case 10:
    case 11:
    sound.playGlobalPlayer('Weapon Pickup',1);
    case 5:
    case 6:
    sound.playGlobalPlayer('Laser Charge',1);
    case 19:
    case 22:
    case 26:

// Message IDs

function decipherID(obj,idx)
    switch (idx) {
    case 1:
    return("Picked up some ammo");
    case 2:
    return("Picked up some rifle ammo");
    case 3:
    return("picked up some grenades");
    case 4:
    return("Picked up some rockets");
    case 5:
    return("Picked up some laser charge cells");
    case 6:
    return("Picked up an LP4 laser pistol");
    case 7:
    return("Picked up an UZI 9mm");
    case 8:
    return("Picked up an Assault Rifle");
    case 9:
    return("Picked up an automatic Sniper Rifle");
    case 10:
    return("Picked up an F2000S");
    case 11:
    return("Picked up an M1 Bazooka");
    case 12:
    return("OBJECTIVE 1 COMPLETE");
    case 13:
    return("OBJECTIVE 1 FAILED");
    case 14:
    return("OBJECTIVE 2 COMPLETE");
    case 15:
    return("OBJECTIVE 2 FAILED");
    case 16:
    return("Rendezvous point located");
    case 17:
    return("Dimitri has been killed");
    case 18:
    return("Door is locked - keycard required");
    case 19:
    return("Picked up a door keycard");
    case 20:
    return("ACCESS DENIED");
    case 21:
    return("Picked up an adrenaline capsule");
    case 22:
    return("Osiris package located");
    case 23:
    return("Warning - motorbike severely damaged");
    case 24:
    return("Security Centre unlocked");
    case 25:
    return("Security Centre locked");
    case 26:
    return("Picked up some body armor");
    case 27:
    return("Door is locked");

So all I do is call the displayMessage function from any other script with the an item ID (see the cases under the decipherID function) and it will add that ID to an array of IDs which will all be displayed in succession using a chained delay so you'll be able to read all of them.

I've also added the playSound function so that some items will make a sound as soon as you pick them up and some will play them only when the relevant onscreen message is displayed.  This is so picking up ammo makes an ammo sound immediately and the message follows on whenever, whereas something like OBJECTIVE 1 COMPLETE will only make a sound when the message displays to make sure it's clear

Anyway, the hardest bit was getting the array to work properly so I hope this is helpful to someone  ;D

Pages: [1]