Here’s a new version with a couple of fixes – and native Linux compiles.
– Fixed issue with rendering of character shadows that would potentially crash the game.
– Fixed bug that allowed you to access objects through walls.
– You can now also scroll the map with W, A, S, D.
There are two executables. The debug version may run a bit slower on older systems as it’s doing range checks on variables and such. If you’re getting slow-downs, try running the non-debug version. But if you can, please use the debug version, as this will provide valuable information in case of a crash. Pressing F1 in either version will display the current rendering speed (if the number goes below 0, it means there are slow-downs). A Linux version is in the works, and I hope to release that in a week or so.
Hope you enjoy this test map! Please share on the forums how it ran on your computer and what you thought of it. And see if you can complete the assassination job with 100% stealth!
1 CommentSeptember 24th, 2012 by Christian Knudsen
Just a quick update this week. Everything’s implemented for the test level, so I’m currently doing the final bit of testing and fixing any critical issues that crop up. I’m sure there are still a hundred bugs left in the code, so don’t expect everything to be 100% smooth.
There’ll be two executables in the zip file I’m releasing: a release version and a debug version. The debug version might run a bit slower on older systems, as it’s constantly doing range checks on variables and so on, but it’s also got error tracking, so if you experience a crash, you can tell me exactly where it occurred in code. But I’ll go into more detail on that with the actual release.
I spent the entirety of yesterday tracking down a tough bug. Through casual testing, I had discovered that if characters were trying to run through a door, but their path was blocked, they’d run through the wall next to the door instead. And seeing as those characters were neither ghosts nor X-Men, that wouldn’t do.
At first, I thought their paths were getting out of whack. The pathfinding works by instantaneously finding a path from start to end, then having the character store the directions of this path (move forward, move left, move left, move down – you get the picture). But if for some reason these directions went out of sync with where the character actually was, that would account for weird pathfinding, such as running through walls. So I spent a great deal of time searching for places in the code that could potentially push a character out of sync with his pathfinding. I wasn’t able to find any.
So with that theory abandoned, I started running through the actual pathfinding code. Outputting some debug info revealed that the pathfinding did indeed path its way through a wall. So the issue arose from the pathfinding itself. And that’s when the fact that this was always happening next to a door lit a lightbulb above my head (I quickly turned off that lightbulb, as the glare on the screen was distracting). There was a problem with how doors was handled in pathfinding. The process of pathfinding is a 3 step process in my code. First, a path is attempted while respecting locked doors. If no path is found, a path is attempted while ignoring doors completely (since the character will be stopped anyway when trying to move through a locked door). If a path still can’t be achieved, the code will find the closest reachable spot to the destination and find a path to this spot instead.
The issue was with the second step: ignoring locked doors. The code didn’t check properly that the door to ignore was actually in the direction the character was moving, just that the door was associated with the tile the character was currently on. So if a character was trying to run left, through a wall, and there was a door to the right that was associated with this tile, the game would think that the wall obstructing the character on the left was a door as well – and since the second pathfinding step ignores doors, the wall would be ignored. The fix was just to make sure that the door was actually in the direction the character was moving from this tile. 6 hours spent finding a bug, 2 minutes spent fixing it once found. That’s programming, I guess.
Anyway, there’s currently only one AI thing left to do: characters reacting to finding a corpse. After that, I need to polish some minor things, do a bunch of testing, fixing the bugs that are bound to reveal themselves from this testing, and then packing up everything I’ve got so far for release. This is the home stretch!
Another week of programming done. I added a bunch more functionality to the scripting language, so I can now script the stuff needed for the test map. I also expanded the AI a bit, so that characters will now react to you carrying around a weapon in a restricted area, and when you shoot an NPC that is unarmed, he/she will either run off the map or try to hide – as well as cry out for help, which might attract the attention of nearby guards.
With regards to AI behavior, I also added character types. The most basic types are Guards and Civilians, but I can add whatever type I want (the test map, for example, also has a Receptionist and a CEO). Beyond affecting AI behavior to some degree, this is now also displayed when you hover over a character, along with the character’s name:
I also fixed some minor issues with the spawning of random characters and added random name generation for these spawning characters. It uses the same system from Ascii Sector – basically just picking a first and last name from a long list of names from various nationalities. I feel that each character having a name and type gives them a bit more personality, but it’s not all that important for the actual gameplay mechanics.
AI work continues this week. I’m almost at a point now where I can play through the test map. There’s just still some cases that aren’t covered by the current AI system, as well as stuff that needs polishing. The September release of pre-alpha demo version 0.1 still seems possible. The challenge with working freelance in addition to making a game, though, is that you never really know for sure how much time you’re going to have to work on the game.
There’s still a bit of AI work left to do before the test level is fully playable. As is evident in the video, shooting at close range is still a bit wonky, for example. Kinda reminds me of that Naked Gun scene. I also need to add some more features to the scripting language to have characters in the level react the way I want to certain events.