Recent Posts

Pages: 1 [2] 3 4 ... 10
Idle Chatter / Re: One Of Them
« Last post by Galavant Garde 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
dim3 Versions / Re: dim3 v24 Release
« Last post by Galavant Garde on March 14, 2018, 03:54:36 PM »
Ha, spaghetti code  ;D I fixed it now, all good.
dim3 Versions / Re: dim3 v24 Release
« Last post by ggadwa on March 14, 2018, 08:27:27 AM »
There's no problem with doing something manually in the code, there's a lot of it there and if it solves the problem, then it solves the problem.  Too much of it makes spaghetti code, but a fix here and there?  That's fine.

[>] Brian
dim3 Versions / Re: dim3 v24 Release
« Last post by Galavant Garde 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->,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 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->[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 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  8)
Idle Chatter / Re: One Of Them
« Last post by Galavant Garde on March 10, 2018, 02:34:31 PM »

- 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
dim3 Versions / Re: dim3 v24 Release
« Last post by Galavant Garde 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  ;D going to have a tinker with it. Thanks again!!
Idle Chatter / Re: One Of Them
« Last post by Galavant Garde 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
Idle Chatter / Re: One Of Them
« Last post by Galavant Garde 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  8)

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
Scripting / Re: Improving enemy vision
« Last post by Galavant Garde 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
« Last post by Galavant Garde 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?
Pages: 1 [2] 3 4 ... 10