More rambling

Just a quick update to give an idea of where we are with the demo (aka, how much we've procrastinated.) Also, this blog itself is a form of procrastination in that I can avoid programming for a little bit. Despite how fun it is, it can get tiring. Anyhow, here are some of the tasks that we have been working on during the last few weeks (look, I even gave each task a header... gettin' fancy):


MOLSHA SCENE REFINEMENTS

As is often the case with uh... well, everything, a lot of refinements/visual updates are completely serendipitous. Andy and I get to looking at something in this particular scene, decide that we don't like the way something looks and then two hours later, somehow the entire scene is improved. In this particular instance (one of many), something as simple as changing the skybox (a skybox is exactly what it sounds like... a big set of pictures that wrap around the sky in a scene in a particular way) can drastically change the entire mood of a scene.

I would say something really nice about some of the 'terrain' used in Molsha (for the park areas, as well as some of the areas around the mines), but Andy somehow managed to delete a large portion of it. Then again, if I came across an asset named "New Terrain 9", I probably would've deleted the shit out of it too. So it goes.

We were wanting to have three connected 'scenes' for Molsha, but decided on settling for two after realizing that the demo will already be quite long (assuming the player is interested in fighting the different enemies scattered throughout... and finding the various things that we have hidden). This also gives us more time to focus on the way two specific scenes look/play without spending a bunch of time trying to tune three scenes. Still a two-man team, after all.

FOOTSTEPS

When people walk, sounds happen. Since our game is a 100% accurate representation of reality (with giant roots and shit), we decided that we'd need some footsteps too. There are a bunch of ways of going about adding footsteps, but really, all one needs to know are the particular moments when a given foot hits the ground.

Since this is such a small, but important task, we figured we'd spend a few bucks on a Unity asset to basically do this for us. Literally, thing cost two bucks. Anyhow, it didn't really work: couldn't handle variable speed characters (which is completely worthless), nor could it handle blend trees (again, completely worthless). For two bucks, I'm not sure what I expected.

Anyhow, we ended up doing this ourselves. For anyone interested, here is how we did it:

This graph represents the xyz coordinates of Bodom's right foot as he runs. The blue line represents the vertical position of his foot and as such, is the only thing we're really interested in here. As you can see, there is a low point and a high point. Basically, Unity (being the little darling that it is) allows you to add 'Animation Events' at particular points in an animation. What this means is that you can trigger a function to be called whenever a desired event occurs. In this case, every time the blue line is at its lowest point, we know that his right foot should be hitting the ground. We then call a 'Footstep' function that we implemented, and we can additionally pass it the foot that 'stepped on the ground'. This function then casts a ray downwards to determine what it actually hit--from there, it can play the appropriate sound depending on the surface. We do the same thing with the other foot. The best part about this method is that the graph above will effectively be scaled depending on the speed that the character is moving, ie, it doesn't matter whether he walks or runs.

The only real downsides to this method are that a.) it requires manually setting up each animation and b.) it only works for bipedal characters at the moment. Both of these can be dealt with by automatically determining the lowest points in code (contrast with having to do this by hand) and altering the function to handle an arbitrary number of feet/contact points, respectively. For now though, it works well enough.


SOUND EFFECTS

Since we're on the topic of footsteps, we additionally added a few mechanisms to allow skills/attacks/other interactable objects to trigger sound effects. This was not difficult by any means... however, finding appropriate sound effects was a different story altogether. As it turns out, there are a lot of free sounds out there. Like... a mind-boggling amount. And 99% of them are utter shit. Seriously, pretty sure people put sounds on there specifically to troll indie game developers. Then you have to wade through the licenses... and trim the songs... and change the volume... and add fade ins/outs... and sync the sounds with the animations... very tedious.

Somehow though, after searching for a few days, I managed to find decent sound effects for literally every action in the game. Admittedly, some of them are weaker than others (who knew that sound quality consistency would matter so much?) But by god, they are in there and they already add a huge amount to the overall game.


MUSIC

For the demo, we have decided on two (possibly three songs) songs that are an absolute necessity. Battle music, boss battle music, and possibly a battle victory song. For the actual background music of Molsha, we found a nice ambient loop that works insanely well without needing dedicated music, per se. Which leaves these battle themes as the sole remaining musical... uh... issues. If you know anything about me, I am one picky motherfucker when it comes to music. Unfortunately, with only a few weeks left, it's not like we have the time/money/expertise to develop/acquire the kind of music that I would want... thus, to the Unity asset store we go. Don't expect any miracles here... after a cursory glance, it looks like the offerings are brass, brass and more brass. And some percussion. Then brass. So yeah...

DEMO AVAILABILITY

After a bit of dicking around (technical term), we figured out how to build a (WINDOWS!) installer for the game. This was not exactly as easy as I expected it to be (long story short, it seems that Unity does not put assets contained in the "Resources" folder into the "sharedassets" file it generates. The solution was to manually place these ourselves... are... are you asleep?)

Since we obviously have to have the demo finished for the conference (or not, might just get drunk instead), we plan on releasing this to any who are interested as well... at some point. We'll probably have more information on this later, but if you are someone who wants to try the game out (and provide feedback, of course), please let us know via a comment/direct message. We'll try to have this available ASAP (if not before the conference, then shortly thereafter). Presently, we have only tried this demo on exactly two computers... I expect that we'll find a lot of fun shit out whenever multiple people attempt to install this thing on their various desktops/laptops/lawnmowers.


LINGERING ISSUES/BUGS

"None. Zero. No lingering issues or bugs. Application runs flawlessly and at 60 frames per second. Always."
-Said no programmer ever

There are a few notable issues--we still need to add a way to essentially 'reset' the game once a particular person has played through the demo. (ALT+F4, then re-running the application is not an acceptable solution) This will not be difficult--just tedious.

AI issues: occasionally, an enemy character will walk directly up to an ally and then proceed to do absolutely nothing. Not sure what this is about...

Interactable objects do not currently persist throughout scene loads--what this means is that if you open a chest, unlock a gate, trigger a cutscene, and then go to another scene, you can then return to the previous scene and re-trigger all of those things again. We already have this working for enemies--ie, if you kill an enemy then go to another scene, then return, that particular enemy will continue to be gone until its spawn timer resets. Thus, we have the framework in place--we just haven't implemented it for interactable objects.

Dialogue: need to spice up some of the exchanges between characters so that the player has some idea of what they are actually doing in the demo. Currently, they just look at each other and grunt. In the original game, the overt purpose of going to Molsha is to essentially survey the damage and look for survivors. (Spoiler: there aren't any) In the demo, however, the goal is to find and defeat the boss of that particular area. While this won't vary dramatically from the overall game, it would be nice to have the dialogue/cutscenes/exposition set up as similarly to the real game as possible.

UI: Multiple revisions have inevitably broken the main menu. Andy is currently whipping it back into shape, but it'll still be pretty bare-bones; the character will have access to the "Status" and "Items" subpanels but we are not sure if we'll have equipment switching implemented by the time the demo rolls around.

Framerate: Honestly, this deserves its own blog post. Maintaining a consistent framerate is probably the most fundamentally important thing that tends to get overlooked. Until it's too late. This is for good reason: because it's a bitch to figure out.

As an example, that song that one dude wrote about having 99 problems (but a bitch ain't one) is actually about maintaining a consistent frame rate for the games he develops in his spare time. If you pay close enough attention to the lyrics, it's obvious that he's talking about overclocking/vertical syncing/different shader profiles and so on. I can relate.