March Progress Update!

Hey everyone!

There’s a whoooole lot of stuff to catch you up on since last month’s update. To be up front, V0.06 did not take the spotlight as was initially planned. While I’m certain this will disappoint some of you, we’ve made a ton of progress this month, and I think it’s for the better in the long term. That being said, you guys absolutely deserve a playable update as soon as possible, and trust me when I say I feel the heat to get it to you! To soften the blow, I’ve come with a bribe in the form of H artwork concepts :D. First though I need to make you suffer through pages of development related stuff! 

Story and Development Notes Overhaul

It started innocently enough! My main goal for the first week of the month was to put together the remaining details for V0.06, with the end objective being a completed design document to use for the remainder of the cycle as I’ve done with the previous two major releases. I’d honestly been dreading this because the last major revision to the main story was at the beginning of last year, and I had compiled a crap ton of notes on the subject since then. So many in fact that it quickly became a bigger chore than I envisioned due to them being mixed in with other development notes. So, I took a step back and decided the first thing to do was to get organized. 

While I had originally planned to just scour my notes for story content, I ended up merging and refining content from over 80 files down into a tagged and catalogued 22-page document (now 34 pages) that will be used from here on out to store and organize literally any development related note. This is something I’ve needed for a long time since I often get random ideas and have no way to properly organize them other than to create a separate note file (that I’ll never find again when I need it down the road). The way I’ve done this is I’ve created a tagging system in which I can search entries by general, predefined tags as opposed to content. This means notes and ideas don’t have to be stored in any specific order, and any content that falls into multiple categories can still easily be found since I can just tag it with multiple tags.

This new system has already paid off in huge ways, as having everything in one place has already allowed me to heavily refine some significant gameplay and mechanics changes that we have envisioned for post-V0.06 (not including what you’ll see later in this update). While these were relatively minor tangents, this whole process opened up Pandora’s Box when it came to the story. Revisiting and organizing all the story notes I had piled up gave me a week-long case of projectile vomiting awesome ideas on how to improve the story. I seriously couldn’t write fast enough.  Basically, leaving it to marinate for a year was great, because I was then able to approach the rough draft that I had with a clear and critical outlook as opposed to the tunnel vision I developed when I banged it out originally. 

When I began that process at what I think was the beginning of week #2 in Feburary, one of my first obstacles was remembering all of the critical details hiding in the then 32-page story document.  One of the things that helped me to do this was to visually plot the story. While trying to think of how to properly do this, I remembered these xkcd comics from awhile back that showed visualizations for the plots of some popular movies.

Well, as it turns out, someone actually created an application called Plotweaver for generating these “narrative charts”. It took a day, but I hammered out one for Malise and the Machine. This was meant entirely for my reference, but I made you a relatively spoiler free version highlighting only the part you’ve played through (up to V0.05).  It’s actually already severely outdated at this point, but it should at least show you the scale of the main story of the game. (It should go without saying, but in case there are misconceptions: the rest of the game is going to be completed at a faster rate than the early parts… so don’t be afraid of what’s left to go :D)

After working through it and being able to visually see the story with the chart, not only did the details come back to me quickly, but solutions to previous problems I had (as well as ways to improve weak points in general) started to become clear.  Unfortunately, the solutions involved some major story surgery. At that point, I could have chosen to put off making these changes in order to get v0.06 out a couple of weeks sooner, but the obvious choice for me was to go ahead and get it done now so that there are no conflicts later. So, there’s my huge-ass explanation for working on story for two weeks straight. Unfortunately, without driving you straight to spoiler town I can’t elaborate too much, but I’m really excited by what I’ve done so far, and by extension I hope you’ll trust me that it will pay off. 

Gameplay / Mechanics Changes

While I don’t want to spoil the story, there are a couple significant changes that have been motivated by the story rewrite that I can talk about. The biggest one is the likelihood of a third playable character :D. We’ve tossed around the concept since I wrote the original draft, but pulling the trigger on it allows for some of the major story changes that weren’t viable before. 

A second thing I’ve been looking at is changing the way skills are tied to body armor/outfit. I went through a couple different ideas when overhauling this concept. The first idea was actually to tie skill loadouts to the character’s equipped weapon type instead of armor. This would alleviate an issue we were having with story segments where the lovely ladies are… indisposed. By that I of course mean we would be making battles a possibility during story events where the characters aren’t armed. I thought that tying all skills to weapon types would work, but it revealed another major problem due to future plans for characters to be able to switch between weapon types in battle (see #3 in the below list). I identified three distinct problems with the current relationship between armor types, weapon types, and actor skills.

• 1. The actors may be disarmed during some story scenes. Currently, combat while the characters are unarmed can’t really exist, thus it really limits what role combat can play in some story scenarios. This is especially disappointing since H content is so engrained in battle, and could make for some great interactive H events.
• 2. The actors may be forced into new outfits during some story scenes. Tying armor type to all skills means that all a character could do in combat in these situations is attack, guard, or use items since the character would have no skills equipped for the “non-combat” outfit type.
• 3. A balancing issue exists due to the concept of changing weapons in battle. A character could utilize the 4 extra glyph slots entirely for non-weapon based skills such as Reconstruct, which in my opinion is not only super strange but also hard to balance against without overcomplicating stuff.

I came up with two solutions. One is to remove the idea of changing weapon types in battle. This however simplifies my vision for combat down the line a lot (think of weapon types as how some games use “stances” … basically they offer different strengths/weaknesses for a given battle situation). This solution would also limit characters to a whopping grand total of four skills in battle at any given time. I like the other solution better, which adds a new layer of depth to the combat system. Here’s the rundown of proposed changes… it’s big and intimidating since it’s super detailed, but it’s actually quite simple since what we have now is sort of a stepping stone in this direction.

• Add an ‘Unarmed’ or ‘Fist’ weapon type for all characters. The game will default to this weapon type if the character has no weapon equipped.
• Separate skills into ‘Weapon’ and ‘Class’ skills. Weapon skills would be in the left position on the command tetrad, while Class skills would be in the down position. ‘Guard’ would essentially just become a ‘Class’ skill (available to every class), and could be swapped out if desired.
• The skills in the Weapon Skills tetrad would be entirely dependent on equipped weapon type. The ‘Weapon Skills’ icon would be different depending on the currently equipped weapon type. It would show a silhouette of the weapon type in front of a tetrad panel.
• Give armor/outfit types an associated Class that determines what skills can be equipped in the Class skills tetrad. Armor types would be colored based on the default Class they offer. Note that some skills can be compatible with multiple classes. This is, essentially, exactly what we have going on now, however identifying “class” as an independent feature from armor type would allow for the player to potentially change the class granted by a piece of armor through some process later in the game if they wanted to keep the visuals/H behavior of another armor type. This would also theoretically allow for a character to assume a class granted by another character’s armor types without the need for a literal shit ton of different artwork varieties.
• The class that an armor type assigns would be shown in the tooltip popup for the armor (these aren’t implemented yet… think Borderlands / virtually any MMO / Diablo).  The character’s current class would be displayed in the Status menu, and would be identifiable based on the color of their Class Skills tetrad in battle / the Tetra menu. 
• Give the Weapon Skills tetrad a neutral color for all characters. The Class Skills tetrad would assume a color based on the character’s current class.
• When a character is wearing an outfit (or lacking an outfit entirely) that does not offer a Class, the Class skills tetrad is inaccessible in battle. 
• There may be an ‘Unarmed’ weapon skill for defending to mitigate the lack of a Guard skill, or Guard could simply replace the Class Skills glyph (down position on the command tetrad) when wearing a non-Class outfit.
• Consider adding passive skills directly into the Class and Weapon skills tetrads due to the number of extra glyph slots available with this idea. It was previously thought that there would need to be a separate menu for these so as to not take up space in the battle tetrads.

Since I assume that this solution will be implemented, I’ve gone through and re-written a lot of story scenes to make them more interactive by including battle situations where there previously couldn’t be any. 

I want to mention that both of the above ideas weren’t really up for consideration a year ago because of how much busy work it took to render out and process a single character portrait. Because of the optimizations we made earlier in this cycle, additional weapon types and event-specific battle outfits are much more plausible now. 

AltairPL’s New Experimental Engine

Your eyes aren’t tricking you! The goal of this experiment was initially to remove as much reliance on RPG Maker as possible, and to replace it with more modern libraries for video, memory management, input and so forth. AltairPL began experimenting with this concept a few months ago and has been working on it intermittently since then. It has since developed into the possibility of an entirely proprietary engine.  Obviously, this is exactly as complicated as it sounds, so keep in mind that this is a long-term goal and not something to expect any time soon. That said, there have been some amazing early results that merit sharing. To guard against misconceptions though, I’ll say that the awesome features mentioned below aren’t promises, but for now are simply possibilities we are working toward.

It's probably no surprise by now that the game has been growing out of its skin. The primary reason we’re looking at this now however is that RPG Maker has some problems that will require significant work to get around for a project the size of Malise and the Machine. Secondarily, our access to things like video, audio, input and how we package the data are all heavily limited. Therefore, since reason #1 means a lot of work has to eventually be done anyways, we’ve been looking at alternatives that will not only solve these problems but also provide other benefits such as performance and improved visuals.

What’s grabbed our attention is a library called SDL_gpu, which is an open source library for high performance, modern 2D graphics that utilizes OpenGL and is based/dependent on SDL. The most obvious benefit here is that it’s hardware accelerated, meaning it actually makes use of your graphics card as opposed to only the CPU.  What other benefits could possibly merit such a big change? Here are just a few off the top of my head (this is the part where you shouldn’t get too excited too soon… but that won’t keep me from doing so anyways):

• HD resolution
• Variable aspect ratio (widescreen, yay)
• Customizable resolution settings
• Fully configurable key/button mapping for controls
• More freedom in how we implement things
• Native builds for Linux, OSX, and with time probably many more (e.g. Android, iOS, etc.) – no web bullshit like RPG Maker MV is using.
• The possibility to use advanced shaders and visual effects
• 64-bit version

Now for the fun part! During the third week of February, AltairPL actually got the game running using the aforementioned SDL_gpu graphics library. I personally wasn’t expecting this to happen for some time, but since it has we’ve been able to run a whole set of performance comparison tests. The results are, in short, extremely promising, and in my opinion completely validate the effort required to carry this experiment to completion. I’d like to share some of those results with you :D. These tests were performed on APL’s computer, which has the following specs:

• AMD Phenom II X6 1090T 3.2 GHz
• 8 GB RAM
• Radeon HD5970 2GB Graphics Card

Here are the frame-per-second results for basic image rendering:

SDL/GPU (new graphics library):

• 4 images – 1550 FPS
• 53 images – 555 FPS
• 277 images – 200 FPS

RPG Maker:

• 4 images – 110 FPS
• 53 images – 36 FPS
• 277 images – 26 FPS

Ten to fifteen times better performance! Obviously, the graphics card acceleration is a big help. Here are results for a basic test pertaining to rendering the largest map we currently have in the game (the containment pen): 

4 basic images + 2 Containment Pen parallax images

• SDL: 1220 FPS / 109.8 MB RAM
• RM: 74 FPS / 159.8 MB RAM

Loading time of those 6 files:

• SDL: 2.207126 seconds
• RM: 4.152238 seconds

From this we can see that the new graphics library also shows significantly improved RAM usage and much fast loading times for big images like maps. 

The above results are from simple rendering tests; however, I’ve taken some screenshots showing the performance of the actual game running. We consistently experienced a 4-5x performance gain throughout all scenes we tested. Keep in mind that even though basic rendering works, there are a lot of things that don’t yet, so text and windows aren’t displayed. Also, positioning is off for some objects. You can see the FPS in the top left corner of each screenshot.

• Title (1024x768)
• Title (1080p)
• Menu
• Battle

The big takeaway here is that performance will virtually be a non-issue after this is complete. Not shown are some other tests we did with 1080p, all of which showed a similar drop in FPS (only 25-30%), meaning that the possibility of HD in the future will not be restricted by performance. We’re obviously really happy with these results, but there’s a deceptively long way to go to make the switch happen. Currently APL is investigating ways to simplify the interfacing between Ruby and C, which has been causing him a lot of uh, mental trauma. 

By the way, I want to point out that this switch will in no way diminish the work done up to this point in RPG Maker. The Ruby code and databases for the game itself will still be used, so virtually all of the work that had been done on optimizing performance will directly carry over.  As far as artwork is concerned, I've been rendering almost everything in high resolution all along, so we have that as well.

Artwork Progress

We’re finally to the fun stuff!

If you remember, last month’s update had us finishing up some test maps for V0.06.  TK was hard at work at the beginning of the month figuring out and putting together the render setup for the new environments. It took a full day of testing on his part to figure out the new render setup process, as we are now doing shadows and lighting somewhat differently (even from the recently completed Access Tunnel revamp maps).  I was able to sneak in some time to do a test run for processing the shop area map, and I’m incredibly pleased with the results. It almost looks like we know what we’re doing now!

Since APL and I have since been working on other things, TK plowed ahead and started creating tilesets for future maps that we will need down the road. You can check out his progress here!

The last few days of the month however I spent entirely on making some concept poses for skills for the Police enemies. 

March Goals

I still have a few key topics I want to flesh out with the story overhaul, but after that we will be hitting V0.06 harder than ever. AltairPL finished up the majority of his work on the battle overhaul early this month, so he’s in a really good position for v0.06 and will likely be continuing his efforts on the new engine. Audio guy has been focusing on sound effects the past few weeks, which is more important than ever since a new engine will mean we can no longer use RPG Maker stock sounds (this is no skin off my nose though, since I know we can do better). 

As always, thanks for your continued support!