I'm not sure I mentioned it, but setting up lights (in 3D) is an art form (even with today's "click and done" tools and global illumination). Even more so in "realtime 3D", when you have a very, very specific idea of how things should look.
AgentZero (or AZ for short) isn't different there (did I mention that the prototype finally has a name?).
My original plan was to be able to light each room (as I would do for rendered 3D) to get the light *right*, but of course there is no such a thing as "right" when setting up the lights in Unity. The first bummer was the fact that even with shadows turned on the lights shine "through" the scene, ie. when turning off a light on the first floor the room below it would become darker too.
So I ended up separating rooms with layers and "exclude" lights, so the lobby would be layer "RoomA" with the lights limited to that layer and the first floor would be moved to layer "RoomB", while the second floor would use "RoomA" again (as there was enough distance, so the lights didn't shine through).
This shows the old lights in action, with 3 spots per room there where 12 in there, plus the spots in the elevator and behind the doors (which are turned off when the door is closed).
Due to the nature of the beast there are only so many lights Unity handles well, setting the important ones to "important" helped a bit, but the nail in the coffin was the new "Restroom" room. When opening the door some annoying flicker showed (when the light was turned on behind the door). I may have been able to work my way around that, but I decided to overhaul the light completely and reduce the number of spots a LOT.
The new lights in place, it got a bit brighter and it lost a good deal of depth, but not to a degree where I would have cursed and shouted. Instead of using spots I went for 2 directional lights - one main light and one fill light to light up the edges. On the plus side I still can exclude rooms from that and add individual lights there (think dark passage), I need yet to find out if I can change layers at runtime, but if not I find a way around that.
The lobby with the new lights (not as bad as I feared either).
I'm toying with the idea of adding a light that moves with the player to recreate a bit of atmosphere, but for now the light has to stay the way it is now.
... and with this I'm going to continue coding the handling of the WC stalls.
During the last couple of month the prototype game changed a lot and I entered a state not unlike "full production mode" (just with less time to actually work on the game).
This is what it looked like the last time I posted about the game (because, let's be honest, the last post was fucking ages ago):The most obvious thing changed is the map:
As you can see, it moved away from the platformer style to something room based, the elevators were moved into the back (instead of blocking the path) and there are no goons in there (yet).
It started easy enough with the idea of removing the gun from the player and introducing the "hiding" mechanic, I also started to dislike the way the goons moved around "randomly" (the reason why I wrote a pathfinder based solution
). Also some of my early playtesters mentioned that the mechanics weren't quite working as well together as I thought (something that had dawned on me as well).
Once the old map was gone it wasn't that hard to settle on the room based map and add the mechanics that suited the slower pace, just to realize that I made a full circle with the game idea (and a round trip of about a year). Mechanics wise the game is more or less the same as the one I first started over a year ago, just the visuals changed from top-down/iso to fake-2D:
Right now I'm exporting some new rooms in order to add some more features (cameras, laser gates, etc.) and later get the goons back in, but this time with less freedom to move around (for the most time). Mostly they will be used as guards (patrolling a set area), but some may walk off and explore the map on their own.
Last image in this post is the "Elevator Cam", which ended up in there because I needed a new way to control the elevators from the inside:
And with this I'm going to export a restroom.
ps: There are more frequent updates on this on (my) twitter (@nGFX, link on the right) as it is sometimes easier to just write 5 words and post an image.
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.
As much as I like the Chrome browser, google sometimes annoys the crap out of me for playing the web police.
If you're greeted with this:
when doing a quick test built for friends (using the unity web player), try this in your url bar:
Activate it and don't forget to click "restart now".
Not a pretty fix, but hey ...
Let's start with a screenshot of the recent game prototype:
The testbed for the goon's AI.
Even though it's only 2D, there's a lot going on to let the goons walk around the map on their own. Handling their normal way is easy enough, it is just looking ahead 2m and then decide what to do next (mostly broken up into multiple random chances).
If the goon sees a door, it is set as next target and he start walking into that direction (although there's a check every now and then to see if the player can be shot). After he reaches the door there aresome things to decide:
Doors are easy.
- Have we reached the max number of steps (90% chance of using the door to exit the stage)
- if not, there's 10% chance of an early exit
- ... and a 5% chance of turnung around
- otherwise pick the next target
Elevators on the other hand trigger a lot more possible actions (heavily simplified):
When the goon is finally in the elevator there are still a lot of things to check:
- Is the elevator on the same floor? (and is it empty?)
- Enter, pass or turn around
- is the elevator coming towards our floor (90% waiting for it)
- are we heading towards the player's floor? (keep going until we reach him)
- no? (chance of riding another floor or exiting the elevator)
- are we at the top or the bottom (90% chance of getting off, but which way?)
Here's an image of an early draft for the goon AI:
And the first playmaker based version (I since moved that over to code)
The code version is in a way easier to maintain than the playmaker version, but also less easy to track when you want to know what's going on.
And with this, I need to get back to the goons ...