Inner Circle Update for February 24 2017!

Hey guys!

There are a few topics to talk about this week, so I’ll get right into it! 

New Demos Added to Soundtrack Downloads

I’ve just added three new demos to the soundtrack section for $15 patrons and up!

AltairPL’s Engine Progress

The big accomplishment this week is that AltairPL actually got the game running using SDL_gpu (the new 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 this week. 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 (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 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.

TK’s New Tileset Assets

Since I’ve been off in story land, I sent TK ahead to start tackling assets that we can utilize for future areas. You can check out his progress here!

Story Progress

I’ve been making further progress on my story overhaul this week. I still have a few key topics I want to knock out details for to ensure no conflicts in the V0.06 story, but as promised I plan on spending the last days of the month working on some H artwork concepts! Here’s some proof :D.  

Aside from general writing, I’ve made advances in a couple big areas this week. 

I followed through with my document optimization techniques from the prior week and all story relevant dialog is now directly within my main story document. This may not seem important, but when you have to hunt down a scene in game or the event editor every time you need to verify a detail about what a character actually said it becomes a worthwhile effort. In addition, I’m able to keep conversations modular and independent from story events by hyperlinking to the conversations/cutscenes in the story outline. This means if some new story element contradicts the placement of a conversation/cutscene and I need to move it, I just have to move the hyperlink.

I spent a full day hashing out further problems with the idea I mentioned last week regarding skills being linked to armor/weapon types and how it limits the possibility of battle during certain story scenarios. 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. There are only so many scenarios where our damsels can be saved from H scene peril by some outside force, however it’s much more exciting when the player gets to take the reins and the girls fight their way out :D.

Sorry for the book! That’s about it for now.  If you have any ideas on how I can prevent the crowd from eating us alive on the 1st when we reveal V0.06 isn’t ready yet let me know o_O!