We're Walking And We're Walking
Jan 25, 2015
Don't be misled by this video looking like a nearly finished point & click adventure game, there is still a lot of work to do. TODO: Insert smiley face.
My goal last week was to get the foundation of the Actor system in and working. Second only to the Room class, it is one of the workhorses of the engine and will drive the movement and animation of every character in the game.
Here is the Squirrel code...
function clickedAt(x,y)
{
detective.walkTo(x,y);
}
detective <- Actor("DetectiveFemale")
detective.at(160,50);
Obviously there is a lot going on behind the scenes in the c code of the Actor class.
Being able to display and manage images is something that's been in my engine since day one, but for Thimbleweed Park we need to be able to play animations that are more than just cycling through frames. The Actor class has to manage not only walking, but reaches, gestures and various special animations. It needs to understand the direction the actor is facing and if they are talking, so all the game scripter needs to do say something like...
...and everything else is handled for her. This class got a lot of use (and overuse) in the SCUMM system. If anything had more than a two-state animation it became an actor, even if was a smashing crate, a boulder or a swinging rope.
Last week, Gary and I started looking at tools that would work well with 2D bitmap graphics and could also do layers that could be turned on and off at runtime.
Of all the suggestions we got (thank you for those), Aseprite seemed like a good choice, so we spent last week putting it through it's paces. We also built some of the animations purely in Photoshop to get a feel of that process and we'll probably use a combination of the two, with larger (in pixels) and simpler animations just using Photoshop.
Art pipeline has always been important to me, mostly because I'm lazy. I don't want to have to hand export animations when they change, I like to be able to type 'munge_art.sh' and have it go though all the art and animations files, convert anything that changed and build spritesheets. Once you start doing stuff by hand, you introduce the human element. I like just pushing a button. More time to read Twitter.
So part of last weeks exploration was getting that process figured out. Aseprite has a nice command line tool that will pull animation apart files and dump the frames and layers into a folder, then my script invokes TexturePacker and out come packed spritesheetswith duplicate frames removed.
If we find another editor we like (or an artist has tool they feel more comfortable working in), and the file format can be pulled apart by the munge script, it should work in our pipeline. Although, there are benefits to standardizing tools, so we can't go crazy, but the flexibility is good and other reason game code shouldn't read editor formats directly. Always try and use a run-time format that can be converted to from multiple sources. The exceptions are very standardized formats like .png or .jpg.
Onward!
After getting the engine to load the animations, the next step was playing them while taking into account the direction the actor was facing. I wrote some hacked code to respond to the arrow keys and spacebar to change direction and start and stop walking. Everything was coming together swimmingly.
Now I just need to get someone walking around the screen. Another quick hack and I'd call the walkTo() function when the mouse was clicked.
My first thought after seeing the result was, "Hey, this is amazing!". That was followed by, "Hey, something is wrong. This doesn't feel right."
I spent a good 10 minutes clicking around the screen watching her move. Something was wrong. It didn't feel like the old SCUMM games.
Time to power up SCUMMVM and take a look at Maniac Mansion.
It hit me after the first click. SCUMM actors move twice as far in the horizontal than in the vertical. It gives the actor's movement this fake sense of perspective.
I went back and changed my code to look at the primary axis of movement, set the actor's speed based on that and then adjust the step distance of the other axis accordingly. I timed how long it took Dave to walk from one side of the screen to the other, then adjusted the detective's walk accordingly. I don't remember if Gary and I spent any time tinkering with the walk speed of the Maniac Mansion characters, but it feels good.
The other issue is that my code does most of the internal calculations in floating point (just as fast as an int in 2015, pure witchcraft in 1987), so the detective moves very smoothly, often stopping on sub-pixels. Modern hardware makes this easy and it looks really slick, but it lacks "authenticity". It's was an easy fix, but I might turn it into a user selectable option in the final game.
So there you go... another Thimbleweed Park weekly milestone checked off.
Next week Gary and I are going to focus on game design, but I also want to get started on the Room structure and setting up objects. After that, I'll move onto getting a first pass of the verb UI. By the end of Feb, I hope to have a mini playable adventure game all driven by scripting.
It is strange how much of this process reminds me of getting SCUMM up and running the first time.
Also... please... no subpixels.... they are horrible!
On c64 the actors were moving a full char (8 pixels, or 4 double-wide pixels actually) horizontally to allow for the column-based masking.
I always wondered why MM and ZMK (on C64) hat that jerky scrolling though the C64 had pixel-wise hardware-register-scrolling. Only much later I learned about the pains of sprite-masking in software :)
It's a refreshing change to the sugarcoated PR blah-blah of other many dev blogs.
A question about the animation to engine pipeline. Looking at the atlas, it's obvious that you have your character fractioned. Right now head+body, but I suppose it's expected other "cuts" to save on texture memory. Are you storing the relative position of each body part when exporting from aesprite to rebuild the animation later? How it's going to be the animation format, something like scumm AKOS? plain xml?
I usually do this via a custom flash exporter to XML, to then rebuild the animation on Unity's native anim format... I save relative pos of each body parts to the character hotspot point (usually at the character feet), number of frames showing, fps and stuff like that. For some anims I store the hotspot position too, as I change it. The resulted anim curves needs cleaning though.
And about pathfinding... MM and Thimbleweed Park have this kind of horizontal rooms, where you could even avoid pathfinding if you wanted to... but, seeing that you have already mentionend it... are you planning on walking boxes? a room editor?
Rooms, scripts, actors... *ahh* adventure game engines makes me feel so fuzzy xDDDDD
Thank you so much!
But I have to say the vertical movement animation is a bit weird... It seems to be more fluid than the horizontal one, plus those overly wavy arms just appear too "dancy" :)
exaggerations- we're also looking to determine how much we'll mimic
the original Maniac style and will also be fine tuning that as development progresses.
-Gary
But Ron, I have a question about the music you and Garry used in the Thimbleweed Park trailer. It's a music from some artist or you guys created the music?
Thanks!
I really like the front and back animations. They are so smooth and work great, but I miss some frames in the side animation. I miss the second step. Also there's two frames where the arm is in the same straight position that makes some flicker animation instead of the smooth one that front and back animations have. Maybe this is the way Gary wanted to do it, so it feels like in MM, but when I saw it for the first time, it grabbed my attention.
Anyway, it's starting to look great.
Being stuck for several days surely is part of a proper adventure game experience (was in the 90's at least). I'm okay with that, but it would be nice if I could share the pain with the character.
As you've mentioned the room design to be the next programming checkbox, do you plan to use the same system? I read somewhere that the reason the "connections" (which is the fastest route from box A to box B) were precalculated was due to the low processing power of computers at the time. Will the engine you're working on calculate them on the fly?
Please don't be afraid of sharing those details once you come up with solutions, nothing is technical enough! Thanks again, I'm so proud to be a backer :)
I remeber that in MI2, when the room was a "long shot", Guybrush sprite changed its size while walking on the paths, to respect the depth of the room.
Do you plan to implement that feature, or it will look like Maniac Mansion?
Watching Good Will Hunting helped me solve the seckrit question. :-)
Second best regards, Mattias (maleman guydude)
I only understand about 1/4 of what is going on in the article and comments, but it's still fascinating seeing what goes on behind the scenes in an adventure game. As a programmer, this is much more interesting than seeing a room of 2 dozen people coding and motion capturing the next Call of Duty.
Crap. There goes our next blog entry.
Thanks so much for this update! I love this!
If there's one thing that bothers me about this project, it's how serious the characters we've so far seen look like and that's part accentuated with the palette. The palette feels more life-like, or in other words more "drab" than "80's tv/jerry bruckheimer/don simpson". There's a crazy amount of drab-palette+sadface style indie games out in last couple years. I generally think that once something is getting popular in way that it's hard to ignore, the trend pendulum is going to swing the other way or elsewhere.
A good example of what I'm talking about is the cheery old school palette of Minecraft vs a bunch of clones trying to do the same but with a drab palette that's not really doing any favors besides being different for the sake of it. I kind of believe that in both music and graphics, it's not about the unlimited possibilities of sounds and colors you can produce, but figuring out which frequencies in sound and light and their combination produces the most pleasing output. According to some statistics only ~5% of the population are wired in a way to be able to "hone in" on the ideal colors/sounds suited for based on the scene, writing etc. I can instantly tell within 5 seconds of youtube viewing whether any entertainment product had the "right people" making it as the difference especially in music is so striking. As "bedroom production" became popular I suspect where the industry in past had higher percentage of these 5%'ers, they are now in a niche - and that's why I stopped listening to new music as finding good new music became extremely more time consuming.
first of all, thank you and Gary for this great devlog: it is very nice to peek at the Voodoo you do to piece this great adventure game together.
I'd have a question about the interactions between your C++ game engine and the Squirrel scripting layer.
Assuming you could have a script like the following this:
selectedActor.walkTo(100, 10);
selectedActor.playAnimation("wave");
selectedActor.say("Hello Everybody!");
I imagine the walkTo will invoke the actual C++ code that will set the state of the character class to render the right frame at each draw call.
How does the Squirrel script gets notified when the walk target as been reached, so the script can resume to the following line?
Do you achieve that with some event subscription/dispatch system?
To make it wait, you'd do...
selectedActor.walkTo(100, 10)
waitForActor(selectedActor)
selectedActor.playAnimation("wave")
waitForAnimation(selectedActor)
selectedActor.say("Hello Everybody!")
waitForTalking(selectedActor)
I haven't completely figured out the naming of the commands, so that will likely change.
You can also do...
breakwhile(selectedActor.walking())
Cool, thank you!