Time Keepers Blog
This is the all new totally Web 2.0 dev blago Klein bottle. As I make progress on I game I will post updates here. It even has an RSS feed so you can have up to the second updates! How convenient!RSS Feed
Hell is your own old code
if(Enemies[i].bCanBeTranqd)
{
//check if the enemy is waiting to be knocked out
if(Enemies[i].nTranqHit)
{
if(vcTimer[TIMER_ENEMY_LOGIC].nTick >= Enemies[i].nTranqEnd)
{
//the tranq dart took effect
Knockout(i, TRANQ_SLEEP_TIME);
}
}
else if(Enemies[i].nTranqHit)
{
//check if enemy is knocked out and should wake up
if(vcTimer[TIMER_ENEMY_LOGIC].nTick > Enemies[i].nTranqAt + Enemies[i].nTranqTime)
{
WakeUp(i);
}
}
}
I spent about 30 minutes looking around the source to figure out why enemies weren't being woken up. WakeUp() is in the function it needs to be in. It's getting passed the correct variable.
So yeah. That was fun.Posted On: 2009-01-11 22:17:59 Comments
Stuff I did
I made a bunch of test cases for existing functions. Specifically for rectangle collision and Field of View.
I wanted to implement a rectangle collision function that returned a value specific to which side the collision occurred on. This turned out to require more thought and sketches then I originally thought. I put together a function that worked empirically, but as it turns out failed 3 out of 5 test cases. I worked the function until it passed all the test cases, working on each case one at a time. This made me quite happy to see the function progressing in this way. Also, I know that it will always work for proper inputs. Which is nice.
I also updated the Field of View function. Originally FoV() would only check the top left pixel of the targets hot spot. As well the FoV check was always originating from the top left pixel of the source's hot spot. So yeah. Not the best decision on my part.
I added a width and height to FoV() so the function now checks the four corners of the target's hot spot. I also originated the FoV() check from a position dependent on which way the enemy is facing instead of the top left corner.
So yeah. With any luck, no more "enemy vision is completely broken" kind of events.
Posted On: 2008-12-17 21:40:44 Comments
Mission 3
I sketched a map for mission 3. Like, on paper.
I think I need an army of mappers to make and script my maps. So slow, so tedious.
Posted On: 2008-11-26 09:54:57 Comments
Bullet list time
Today I got a bunch of crap done.
- Updated my RectCollision() function to return a integer to say which side of the Rect was collided
- Made thrown items show at the correct point in the render stack
- Fixed the trig for free aim. I had forgotten how to use atan2(). Again.
- Compiled my own verge.exe to add joystick hat support. Then got kicked in the nuts by an internal error. When I called DictContains(). Ahh, the downside of using the exe from SVN. I eventully reverted my Verge working copy to 244, and copied my new files in to get my additions without the crashing.
Posted On: 2008-11-02 18:52:31 Comments
Fire in the hole
I spent the last week or so making grenades.
I had to do some special things here, specifically I used some basic physics to figure out the speed to roll the grenades at. I also had to used fixed point math since my velocity was < 1.0 (yay ofixed.vc!)
I didn't really know how to make a parabolic flight look good in 2D, so I decided that the grenades would roll. Hence they look round like the Half Life 2 grenades. To make the "grenade shoot" sound I rolled a can of beans on the floor of my apartment. It make a kind of uneven sound, since the can was full of...beans. But I think it works.
Anyway, I'm going to start maping and scripting mission 3 instead of releasing at this point. I don't really feel that what I have right now is enough to warrant a full release.
Posted On: 2008-10-25 22:58:50 Comments
TK October 7 Update
Been a month. Yeah.
I've actually done quite a bit. I think I finally got the path finding sorted. It would be a good idea to have some people who are not me go through it to see if there are areas when there are too few/many nodes. This seems to make things go b-a-n-a-n-a-n-es.
I also put some effort into refining parts of the UI so it is a bit more intuitive, as well as rewriting some of the UI text so it uses something that closer resembles English. Computer Science and Literature are mutually exclusive I'm beginning to think.
I took a video of one of the new things I made. Arena mode!
Fraps did a good job of recording it (Except it doesn't capture sound. Oh well.) My feeble attempts at converting it to something that YouTube could understand resulted in the quality drop.
Anyway, that's it.
Posted On: 2008-10-07 23:22:52 Comments
More pathfinding stuffs
I fixed several bugs. This made things work more, and improved performance.
I (finally) switched my queue implementation from a string array, to an int array since I was only holding int's in there. This improved performance.
I have too many nodes. This is decreasing performance. <client_voice>But they did it in Unreal Tournament! Why can't you do the same thing here?</client_voice> BECAUSE THIS AIN'T UT, NOW IS IT IMAGINARY CLIENT PERSON. ONE MORE WORD AND I'M TURNING THIS CAR AROUND.
...nothing to see here....carry on....wayward son
Posted On: 2008-08-24 18:58:32 Comments
Random thoughts on pathfinding performance
So I got my new node based pathfinding system using Dijkstra. Now as I'm making the node graphs I'm starting to see some patterns emerge on mission 2. I consider mission 2 a decent stress test at this point since it is larger, has more complex, and more enemies then mission 1.
- I still have to optimize my implementation. I'm using too many linear searches.
- Having mode nodes produces more believable movement.
- Dijkstra did a wonderful job when the graph was only ~256 nodes, but as I increase the nodes I'm starting to hit critical mass.
The original idea was to build all the possible paths either at compile time to be stored on disk, or at map load to be stored in ram. While on a company wide meeting this morning I was thinking about how much data that might be. Note to self: You look really weird when trying to formulate that in your head. If there are 20 other people in the room who aren't sharing your thoughts, you may want to just write it down for later.
Anyway, I'm thinking that either way it will be too much data held in ram, or take too long to load the map. My second thought was to have a caching system where once a path is generated it is held in cache. Then if that path is ever needed again I can recall it from the cache instead of generating it again.
I think it may be time for some speed tests...
Posted On: 2008-08-08 00:33:48 Comments
Pathfinding improvements
I was able to properly implement Dijkstra's algorithm into my node system. This does several things.
- Improve performance. Enemies are no longer searching the entire map to find a path. Instead they are searching a graph of at most 256 nodes meaning they find their path faster.
- I can better control what paths the enemies take. For example: if there is a doorway that requires the enemy to be perfectly aligned, I can setup two nodes at the necessary XY coords to let the enemy walk through.
- I can also prevent enemies from going to certain areas. If an area is too narrow and enemies get stuck on the obstructions, I can move the nodes to make them path around it.
Posted On: 2008-08-03 00:16:46 Comments
Pathfinding
Quick update for now. I've implemented Dijkstra's algorithm into my node based path finding system. It still needs testing in an actual game environment, but so far it is able to handle far more nodes and edges then the previous algorithm.
Either that or I screwed up the implementation. Guess I'll find out.
Posted On: 2008-08-01 11:12:04 Comments
In addendum
I got low obstructions working. It was actually a lot easier then I originally thought it would be. I ended up using zones instead of layers, as the logic I needed was already there.
Here's what I did. I added a function to set the zone that denotes a low obstruction. This function is called during map startup. Then in the LoS function if an obstruction is reached the game checks if this tile is also occupied by a zone with the correct id. If so it lets the LoS continue.
The player can now no longer avoid the ai by hiding behind a chair. The advances in technology being made here are amazing.
Posted On: 2008-07-24 10:43:44 Comments
Engine enhacements
So after mulling it over, I've decided on a course of action on two topics:
- I'll be adding support for low obstructions. This means that things like desks, buckets, etc will no longer break line of LoS. Enemies will be able to see, and shoot over them. The player will also be able to shoot over them. I'm going to add a new layer, make it completely translucent in MapEd, and use it to flag Obs as low.
- I've made a new SVN branch that has mouse controls (WASD movement, mouse wheel to switch weapons.) I'm still undecided on how it's turning out - things seems to happen too fast to be able to aim. That said, if I can get it to work I'll have a 3rd control option. Also several people have brought up the point online and off so it's probably for the best.
This is of course subject to change as I work/don't work on things.
Posted On: 2008-07-05 23:47:51 Comments
RE: Enemy AI
So, in Gayo's write today (awesome write up by the way) he mentioned the fact that Enemy AI still kinda bites.
So I'm trying to make it bite less.
There were several problems that I could see
- A* was sometimes returning bad paths, resulting in enemies running square into a wall.
- I had programmed in a minimum distance for enemies to shoot from. The idea being that they would not get right next to the player before shooting. The problem was that around small obstructions the enemy would stop pathing because they were within minimum distance, but wouldn't shot because they didn't have a LoS to the player.
- If an enemy starts moving because of A* when they are not aligned with the tile grid, A* may send them into the edge of an obstruction.
The cause of the first problem was really because I used the original A* script (there was an updated version that I never downloaded) and also because I had done modifications to that script. The solution was just to download the latest version of the script and wire it back to my functions again. This fixed a rather ugly bug where the destination coords were being offset by X+1 Y-1. I know. Weird.
I added another statement to the enemies logic that allows them to go closer then minimum distance to the player if they can't get a LoS. This greatly improves the AI around small obstructions that the player might hide behind.
The last issue is still unresolved. I'll probably write a function to check if an enemy is stuck, and force it to call A* again to path out.
Next Time: More AI work? Cleaning the Inet code? Mouse support? The world may never know...
Posted On: 2008-06-30 23:55:09 Comments
This weekend
I played Deus Ex.
It's an awesome game, also I needed to design an armory for TK.
So I played the last save I had (at the Hells Kitchen subway station) to the armory in the MJ12 base under UNATCO. I then found that the MJ12 armory was only slightly more interesting than the armory that I had designed.
It has a desk. And a camera.
On the upside it is patrolled by really big bad ass robots that shoot rockets.
Posted On: 2008-06-08 23:18:43 Comments
I did some stuff
I made a logo.
I implemented the last of the things from playtesting.
I made a CHEAT_ENABLED define to disable cheats for release.
I wish VERGE had #ifdef.I could probably put it in myself....
It's 12:04AM.
I was tired, but then I got Dr. Pepper.
This was a bad idea.
Posted On: 2008-05-29 00:04:18 Comments
Teh arts!
I
Anyway, screen shots or it didn't happen!
|
Posted On: 2008-04-30 18:32:58 Comments
Hate for art/map making
Adding new code that will probably take my attention away from actually finishing mission 2 in the name of a silly fun new mode.
More "later"
Posted On: 2008-02-16 19:52:59 Comments
Expansion and new chr.
So I expanded the playable area of mission 2 a bit. Reason being that I was playing Thief 2, and noticed that the levels are much larger then they strictly need to be. It gives the player the ability to wander around and explore and stuff.
But I suck at making maps, so I'll probably put some kind of "figure out the key code" puzzle to artificially extend the play time.
I also made a new chr. It seems that I have the ability to recolor/draw(no actual drawing takes place) them, I'm just a lazy noob. I have a list of all the chrs I need, at some point I'll probably force my self to do nothing by draw them one after another. Like some kind of art slave.
Posted On: 2008-01-05 09:00:12 Comments
Todo lists
Every time I remove something from the todo list I add one or two!
Sometimes I only add one, and a few times I haven't added anyway. At least I'm going in somewhat of the correct direction.
Posted On: 2007-12-22 22:09:22 Comments
Taste the sound!
So in TK enemies can hear and respond to sounds around them.
Thing is there was this bug where enemies would magically start to hear things out of their range when the player came close. I decided it was time to implement a feature I had long put off
|
Posted On: 2007-12-14 23:47:29 Comments
Enemy priority
Enemies now have a priority index. This means that when the player hits the "gimmie a target" button, the game will generate a list of valid targets (in range and alive) sorted first by priority and second by distance.
In simpler terms, this means that the game will no longer target the civilian instead of the guy instead of a shotgun just because the civilian is closer.
I've also been inspired by Grue's post to implement a testcase map. The whole purpose of it is to have some automated function calls that will move the player around, forge player input see what the results are, and then compare them to what is expected. This way I can know at a glance if something is bork'd. Also the act of making testcases might find bugs in my code.
I'm actually fairly proud of most of the code in TK (system.vc, enemies.vc, and gui.vc excluded...bad source files! Go sit in the corner untill I destroy and rebuild you from the ground up!) this will just make me more proud and hopefully track down that stupid crash bug pertaining to animations -_-.
Posted On: 2007-12-07 23:06:23 Comments
PDA
I did work on the PDA. It now is fully functional and has little buttons on the bottom to let the player know they can scroll through the screens.
|
Posted On: 2007-11-30 23:35:22 Comments
The player, and the killing thereof
//If PlayerDeathDone() is hooked, we already called this function.
//The player is dead, don't kill him again. That's not nice.
So there was this little bug that was allowing the player to get shot (and killed) even if they were already dead. Now, this might be a cool feature - the game gets it's revenge on the player.
The problem was that each time the player died the game ran it's player death logic, causing the game over menu to load its self multiple times. The only sign I had that there was some problem was an extra cursor animation being loaded. I was going to rewrite the animation code anyway so thought nothing of it.
Anyway it's fixed not.
Blarg...my system.vc is ugly...
Posted On: 2007-11-21 00:00:15 Comments
sekrit
I did a good bit of work on some really cool aspects of TK today, but don't want to reveal too much. So there!
I also made a function that parses XML in to a dictionary. The logic behind it is really stupid and doesn't actually find all the nodes in the XML and make them keys in the dictionary, it just takes a passed string as the node to look for and parses out all the text in between the open and close tags for that node.
I've been trying to think of a better way of doing this, but the problem comes down to two issues.
- An intelligent way of finding nodes
- An intelligent way of storing child nodes of the same name in the same dictionary
For the first problem I would use regular expressions, but as far as I know verge does not have support them :(. I could probably add them to the source, but it's a bit more work then I want to undertake right now.
The second problem...I don't know...do dictionaries support arrays as data?
Posted On: 2007-11-18 20:44:06 Comments
PDA
So it turns out that players don't enjoy remembering six digit numeric passcodes. Thanks playtesting! So to remedy this problem I've started to implement an ingame PDA. It will keep track of your mission objectives, any important notes, and all conversations that happen during the game.
 |
I still have to put in buttons to let the player know they can press left and right to swap between the areas of the PDA....and actually do the logic to log conversations and such, but that's minor.
Little known fact: all of the dialog that I've written starts in this form.
Posted On: 2007-11-04 20:09:06 Comments
Lockers!
The game now lets the player use all the weapons in the training area.
It also has lockers (wooo!)
Posted On: 2007-11-02 20:08:23 Comments
Playtesting, targeting, forgetting
Haven't updated this in a bit...
I did some play testing in an attempt to remove some of the annoyances that I don't notice from the game. This was rather helpfull as I now have about 2 pages of notes to go through.
Reworked targeting so it will grab the closest target first - I may also implement a priority system in the near future.
Um...I can't remember everything else I did, but I have all the changes under source control so I'll put up the ones I care about here later.
Posted On: 2007-11-01 20:08:11 Comments
The path to victory
Verge -> PHP -> MySQL -> Win
Posted On: 2007-10-24 20:07:35 Comments
You will be baked. And then there will be cake!
I wanted to work on the game today, but my laptop didn't want to cooperate.
-So I formatted it. (You will be baked. And then there will be cake!)
My desktop didn't want to share a similar fate, so it worked with me
I finished up the frames I needed for one of the CHRs, still have 3 or 4 more to make...
Fixed a bug that was preventing saving even where saving is allowed.
Fixed up some of the cutsceen flow. Extracted the default font and messed with it a bit to get what I need out of it (added a +, $ and some others).
Posted On: 2007-10-20 20:07:12 Comments
Font making
Spent way too long trying to get a new main font. All the ones I found online did not scale down well (i.e. looked like crap at 320*240). In the end I'm just going to add some characters I need to the default Verge font, and put a drop shadow under my text.
I hate making fonts.
Posted On: 2007-10-19 20:06:40 Comments
Fruitless crash bug hunting
Spent a lot of time trying to track down a bad image reference. Through the combined poweres of the visual studio debuger, my VC image tracker, and Verge's edit code console I managed to track down the offending image.
-I still don't know why it goes bad. This saddens me.
Fixed a nasty crasy on the tile screen.
Posted On: 2007-10-16 20:06:27 Comments
Bug fixing and suck removing
Fixed some of the cosmetic bugs introduced in the hook reworking.
Fixed a bug where cameras were disabled when they weren't supposed to be.
Did enough work on leader boards to make me want to implement it completly.
Removed some of the suck from the health and weapon icons.
Posted On: 2007-10-15 20:05:52 Comments
Retrace hooks
Reworked the order of retrace hooks. This introduced several bugs (including at least one crash bug - wee!!) but the orgainization gained was worth it.
Did several more frames for tech.chr.
Worked out the sequence of events following the end of mission 2.
Started server side work on leader board code. Not sure if this will be part of this release, but I still think it's cool.
Posted On: 2007-10-14 20:05:25 Comments
Fade in/Fade out
Messed with the FadeOut/FadeIn system giving me the ability to have fade that block and don't block. Fades no longer corupt dual retrace. Fades can now have colors.
Posted On: 2007-10-13 21:21:50 Comments