Messages

1

Idle Chatter / Re: One Of Them

« on: March 26, 2018, 06:03:07 AM »

Focusing on making everything look better at the mo...dark pictures I know, but the player and bot models have been redone with better UV mapping, and I've adjusted the geometry around joints to make for less jagged body parts when they move around.  Still have a few odd triangle shadows around the lower back which I need to improve...getting there

2

Idle Chatter / Re: One Of Them

« on: March 22, 2018, 10:36:44 AM »

Fixing up the zombie model, better or worse?

3

Idle Chatter / Re: One Of Them

« on: March 18, 2018, 01:32:06 PM »

https://youtu.be/IUqLXE6Ywe4 redid the opening sequence, a bit shorter and (I think) better

4

Idle Chatter / Re: One Of Them

« on: March 14, 2018, 04:14:27 PM »

Latest update - I realised side-scroll mode is limited to the X axis only, which would mean I'd have to build levels with ledges/cliffs/whatever all facing the same direction.  Which is sad.  So I modded the engine adding side-scroll input from X/X-reversed/Z/Z-reversed axes! Here's a little snap taken out the side of the prison:



So you can be running around in 3rd person view with FPP input mode, jump out a window or whatever, and regardless of which direction you're facing or the ledge is pointing, you can land on that ledge and switch to side-scroll mode.  Walk left means walk left, and walk right means walk right, regardless of the player's orientation! Small thing I know, but it adds a lot in terms of gameplay dynamic - a lot more so than other bits I experimented with like yelling into vents and knocking out lights

5

dim3 Versions / Re: dim3 v24 Release

« on: March 14, 2018, 03:54:36 PM »

Ha, spaghetti code  I fixed it now, all good.

6

dim3 Versions / Re: dim3 v24 Release

« on: March 13, 2018, 02:22:02 PM »

Scrap that last message - v24 DOES build fine in Xcode9, and the app launches, but it crashes when you load a map...

EDIT - I've worked out that it doesn't like when you use strcpy(map->info.name,name); in map.util.main.c...

EDIT 2 - I can stop the crash happening by manually setting the map name instead of using the above command, but then the game doesn't know which map is currently open when I use the map.info.file API in any of my scripts.  So if I instead use the 'name' reference in the map_new function under map.util.main.c (i.e. map->info.name[0]=name;) it slices the first character off the name for some reason. I'll keep digging

EDIT 3 - yeah I can't yet work out how you've linked it all together Brian, so for now I'm having to manually make a new string in the map.util.main.c with the name of the map I want the game to load with. That's fine for me, but I'm gonna keep trying to make it configurable from the project file like it's meant to be (& like it currently is in v24...so odd that this has happened...maybe it's something in the new compiler that works differently).

Meanwhile though, I've upgraded side-scrolling mode! Now there's DIM3_INPUT_MODE_SIDE_SCROLL_X, DIM3_INPUT_MODE_SIDE_SCROLL_X_REV, DIM3_INPUT_MODE_SIDE_SCROLL_Z, and DIM3_INPUT_MODE_SIDE_SCROLL_Z_REV so you can easily switch to side view/mode at any angle...I kinda wanted to make it easy to dynamically change just like when you're climbing ledges on Unchartered. Works like a charm 

7

Idle Chatter / Re: One Of Them

« on: March 10, 2018, 02:34:31 PM »

Update!

- Fixed issue where action buttons still registered when player input was frozen;
- Player can now walk sideways along narrow ledges;
- Bots have more efficient/reliable method for noticing nearby bots to go get help from;
- Multiple wall collision events are now blocked out preventing bots from getting stuck on walls;
- Bots now filter noises more effectively reducing confusion/broken chains;
- Improved rock-throwing method including ability to abort a throw while aiming;
- Improved bot melee reducing friendly hits;
- Improved bot animations;
- New lightning effect;

Check out the lightning effect and the ledge crawling here:





For the lightning I've gotten rid of the over-saturated ambient lighting effect - now it lights everything up nicer, you see the shaders/bump maps properly, and there's a flicker to the flashes making them look more realistic.  As for the bolts themselves, they're auto-generated using the dim3 lightning api...I think I'll ultimately get actual lightning bolt images and put them on large transparent frame-changing panels in the distance or something like that

8

dim3 Versions / Re: dim3 v24 Release

« on: March 04, 2018, 02:46:39 PM »

PS took me a while to get to it, but v24 builds and runs just fine in the latest version of Xcode  going to have a tinker with it. Thanks again!!

9

Idle Chatter / Re: One Of Them

« on: March 01, 2018, 02:54:05 PM »

Better sky - kinda thought the yellow was too much...

Also, I know I've said this a load of times and later retracted it after finding bugs and stupid shortcomings, but the enemy AI is SO much more polished now.  There are a few physics issues that are holding them back (such as sight tests / projectiles passing straight through walls - this totally ruins everything lol) but as always I'm sure I'll work it out

10

Idle Chatter / Re: One Of Them

« on: February 28, 2018, 04:37:46 PM »

Still chipping away at this.  Have overhauled the enemy AI with moderate success:

New vision routine controlled entirely by the game script:
- Game script successively calls all bots telling them if player in range, FOV, and light;
- Calls will not interrupt what bot is doing unless player is ‘visible’ or within flashlight range;
- Bots ignore calls when in the middle of something important that shouldn’t be interrupted;
- As all bot vision is calculated sequentially in one script, there’s no lag from multiple simultaneous calculations;
- This routine allows bots to spot the player almost instantly while using less engine resources;

New touch/dodge logic:
- Bots now decide which bot should get out of the way by ranking importance of their activities;
- Precedence is based on if they’re moving or stationary, in combat or not, or in middle of something that can or shouldn’t be interrupted;
- If both bots decide they’re ranked equally, the game will decide for them;

Tighter logic map:
- Removed several hundred lines of unnecessary code including functions with duplicated functionality or that weren’t called regularly;
- Heavy use of function stacking making script easier to follow;
- Bots now able to work out if their chain has been interrupted/broken, and will start a new chain if this happens (this prevents freezing bots);

I'll make a video showcasing how much tighter the enemy AI is soon 

Still to do:

COLLISIONS!  ARGH, bumping into other bots works fine - bumping into walls is sadly still messy.

Also on the radar is implementing a ledge-walking mode where you walk against the wall along narrow ledges - should make for some fun action sequences

11

Scripting / Re: Improving enemy vision

« on: February 11, 2018, 07:55:53 AM »

Update:

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)
{
    playerPos=map.object.getPosition(0);
    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++) {
        distance=map.object.getDistance(botRoll[i],playerPos);
        if (distance<15000) withinRange=true;
        else withinRange=false;
        inFOV=map.object.isFacingId(botRoll[i],0,120);
        game.event.callObjectById(botRoll[i],'playerProximity',withinRange,inFOV,inTheLight);
    }
    game.event.chain(5,'playerWatch');    // loops chain every 5 ticks
}

My bots do this:

Code: [Select]

function spawn(obj)
{
    obj.event.callGame('botRollCall',obj.setting.id);    // 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

12

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

13

dim3 Versions / Re: dim3 v24 Release

« on: February 01, 2018, 09:43:28 AM »

Wicked, thanks Brian!   

14

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.

15

Idle Chatter / Re: One Of Them

« on: January 13, 2018, 04:05:25 PM »

Little update video:

https://youtu.be/NXkaeJc0S_E

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.