Having three goons running around, but only a limited number of elevators is calling for trouble. So in order to make that work ("Only one goon per elevator, please"), we had to come up with something really clever (well, almost).
The first obvious option might have been to make the goons talk to each other and let them decide which of them will enter the elevator. Not the easiest solution and there would have been a lot of back and forth between the goons just to make sure they talk about the same elevator.
The second option was a central piece of code that sorts goons and elevators, group the ones belonging together and then decides which one will enter the elevator (not a piece of cake either).
Luckily, option three is just what we need, it's almost clean, it is simple and if it fails it sorts out itself after a while.
Last post I mentioned that the goons look ahead and "decide" what to do with the target (doors, walls and elevators [and player]), so we use this to lock the elevator as well.
I added a simple flag ("claimedBy") to the elevator code (which makes them move up and down) and that was it (OK, not quite, but mostly).
With this in place, only a few things needed to be added to the goon's AI:
If a goon "sees" the elevator and the elevator is not currently claimed, the goon claims it.
If the goon decides to turn away from the elevator after he claimed it, the elevator is released.
If the elevator is already claimed by another goon, ignore it and check again next step.
If the goon is killed, check if the elevator needs to be released.
Let's code these shiny UI icons and make them work, too.
Code won the game.
This only makes sense if you've read last week's post about FSMs. At some time during clicking and dragging states and trying to fit my idea into the corset of the FSM, I figured I need to write my own actions to make things worthwhile. So I started to write my own action. The problem is once you start writing your own, you need to find a point to stop and expose values to the FSM (that can then fetch these and pass to the next action ...).
With this working quite well, I came to the point where I needed to pass more than a single string or float, but my own class with data (or I had to pass a set of values) and suddenly the beauty of this new toy (the FSM and it's supposed easiness) started to fall apart. Years of coding took over the show, brain cells kicked into crunch mode and in an act of fury I deleted the FSMs from the game. A good deal of hours fiddling and working against instinct paid it's price and code once again won the game.
A few hours later the door control was coded and working, multi language ready, too:
Tooltips and control hints up and running and talking to each other via SendMessage, so no links in code are needed.
The interface for using the tooltips is unified and based on "Items" that carry a name, a set of actions and "results" (inspired by classic adventure games). So the Control panel right of the door has the "Item" component attached, it is also linked to the door (to request the door's state). In the image above the door's state is "locked" and the action for the control panel is "unlock door". The result is a new door state: "closed" and a changed action on the control panel "open door", plus the control hint is being updated.
I need more time...
Of course opening a door using a code (or hacking it if you don't have the code yet) takes time, this is also handled by the item, allowing to set a time these action needs to be performed - from 1 sec to a few minutes (it also handles if the time should reset if you leave before the task is performed).
Searching items is done as well, so if you search one of the blue boxes you find the key code for the door and can use it.
Next on the list are guards and the security cameras with these in place the map will be more or less playable and can be dressed for a quick game.
But that's for next week's post.
-- Oliver / nGFX
I've been toying with playmaker (a visual state machine) for while now and I'm still not quite sure what to think of it. On one hand it can make things incredibly easy, on the other hand it can be a huge pain in the ass to get things done.
Let's take one of the easier examples: a simple door.
Ingame door, developer art :).
All the basic FSM tutorials consist of the same basic parts: a door, a trigger and a set of animations to open/close the door. Of course you could also code the opening/closing animation... I deal with that later. Let's take a look at the FSM for this door (not as basic, though).
Even in this image there's trouble ahead.
The tutorials get along with four states: closed, opening, open, closing. When the state is closed the FSM listens to the trigger and when it is fired it goes to "opening". The "opening" state simply plays the animation and continues to the "open" state. The open state then listens for the trigger and if fired goes to" closing". Viola.
The problem is that in my case I have some more conditions to check and I want to paste some initial values as well. A door can be open, closed or locked. Additionally, if the door is open, it should test if the should stay open, and if the door is looked which key is required.
The FSM above could be done in a way better organized way, but this is the very first working draft...
...and to be honest, will be replaced by code.
I find a strange attraction in the thought to be able to do things visually and it's always worth a try, but at some point one has to admit that it would be easier to just code it the darn thing. The FSM works great, but it took me a good while to get my head into it - and there we have the result of years of coding: I have an idea how to code this right from "I need a door" and for me it is a lot of work to leave this path and break things down into parts I can built as FSM. This time the FSM lost, it may win next time.
... now that's the thing you want to read on an artificial fire log.
I've been hammering out tiles over the last couple of days to be used in the prototype of my pet-project game I'v started. This time I'll try something different and do a very basic prototype first (before jumping right in and doing full fledged 3D models before even knowing if the idea is valid)
Though, I must admit that I couldn't resist and make the tiles just a wee bit more pleasing to the eye than plain grey-boxed ones...
Busy building the dummy map ...
As dummy maps go, this is a fairly bigger one than what I would normally do for level 1, but it's also a testbed for all the things to come. Mainly guards, cameras, locked doors and drawers to search through.
Unlike the usual pointless bullshit I write every week I have something helpful in mind for the next post ... something about culling and exporting stuff ...