Nick Pawlowski

No recent postings; I’m sure you’ve noticed. I got the inventory system put back together the way I wanted it, as well as the armor “picker” for the character screen. In fact, that screen is pretty much finished- maybe a few nit-picky things left, but the meat of it is definitely there.

I’ve gotten myself into a few other projects at the moment, though, which has left Forge of Asha on the back burner:

One of my projects at work has been the “revamping” of the visualization our machine uses. Because of some proprietary libraries we have to use to communicate with the machine’s PLC, we’re stuck using Visual C# 2008 to program it. In addition, the guy who wrote the initial version of the HMI’s visualization really didn’t understand C# or windows programming in general, so it’s a memory hog and extremely inefficient. However, none of us have had time for anything more than band-aids over the last couple years, so the visualization has been slowly spiraling deeper and deeper into a massive rat’s nest of inefficiency and redundant code.
However, I recently came up with a way to bypass those communication libraries altogether- our PLC uses the CoDeSys programming language, and one of its features is the ability for multiple PLCs on the same local network to send lists of variables to each other using some specialized CoDeSys protocol. I managed to deconstruct that protocol, and have tricked the PLC into thinking that the HMI running our visualization is just another PLC on that network, so now they can exchange information back and forth without relying on those outdated libraries.
This means I can finally modernize our visualization to take advantage of all the improvements and features that Visual Studio has implemented in the last eleven years. Of course, it means I have to write a new visualization from scratch, and the largest part of this job is packaging up the code for my “PLC communication emulation” method into something that my coworkers can easily reuse, so it’s a bit of a task.

Another work project is something along the same lines- one of the biggest memory/processor sinks in our visualization is the periodic writing of historical process data to a SQL database. On some of our machines (new enough to be complex, old enough to have touchscreen HMIs that still run Atom processors with 2GB of RAM) the entire screen will freeze up for 10-15 seconds whenever a SQL record is made (for whatever reason, threading doesn’t seem to work properly- maybe it’s a problem with the old processor, or maybe it’s a Visual Studio 2008 limitation). We’ve looked into CoDeSys libraries for writing to the SQL database directly from the PLC, but the licensing is extremely expensive.
However, if someone else figured it out then surely I can too, right? Turns out yes, I can. Microsoft was extremely forthcoming with regard to the details behind their TDS (Tabular Data Stream) protocol, used to communicate with a Microsoft SQL Server. It took hardly any time for me to recreate this protocol in CoDeSys, and I managed to get something together that wrote huge data records to the database within milliseconds with absolutely no lag on the HMI.
Of course, reading from the database is slightly more complex, since it also sends along enormous amounts of metadata about the table in question, so it’s still a work in progress.

Lastly, as if my actual career weren’t enough, I recently started my own app development company. I’ll hold off on advertising it here until I’ve got a website that’s slightly more impressive, but I’m currently working on something that was kind of a request- someone I know has been looking for a particular type of alarm clock/system that just doesn’t seem to exist out there currently- not bug-free, anyways. After thinking about it just a little bit, I realized I could make something like that with no problem, and it would actually be pretty useful for lots of people.
I’d been toying with the idea of my own software development company/studio for a while; I actually bought the domain for it over a year ago. But I only just got the business license and registered with the IRS and Dun & Bradstreet within the last couple weeks.

On top of the projects I’m running at work, I’ve got a large project coming up that’s going to have be working at a job site for about 4 weeks. Usually, by the end of the day, I’m too tired to put any effort into software development, so I just want to grab a book or watch some TV (the internet connection at the hotel we stay at is just barely above dialup speeds, so no Netflix).
So I think it might be a little while before I have any significant progress to show off in the game.

I’ve made a lot of progress with the character screen over the last week or so, ever since getting the spiral stat/skill thing worked out:

Of course, except for the spiral (which you totally can’t tell above, but I finally figured out how to get anti-aliasing on the LineRenderer, so it looks much smoother), everything here is just a placeholder. I’ll come up with some actual images and textures to use later on (yes, I know that the icon for “punch” is a kick, and I don’t care), but these let me see how the layout will look, and test out various features.

I’m especially proud of the “select a weapon” popup- it took me a while to come up with a good way to do that, but I’m starting to embrace how flexible Unity’s prefab system is. I spent a long time trying to embed dynamically-generated text and images inside of a Vertical Layout Group, housed inside the Content block of a ScrollView, and it was an absolute disaster. Something about dynamically generating the stuff inside the Content block completely threw off all the size fitters, and the end result was very Picasso-esque. I probably could have spent a few more days getting it all worked out, but I realized it would be way easier and faster to just create a prefab for the icon-name-description weapon block on the inside, and jam them inside the Content of a ScrollView without any need for a Vertical Layout Group. After all, they’re all the same size, so I know exactly where they need to be positioned.

After that, it was basically just getting all the mouse-over behavior working right as far as highlighting and clicking things, and then replacing them on the character’s “equipped weapon” blocks.

You can’t see it in the screencap above, but right underneath where the “select a weapon” popup appears is the Equipped Armor block- that’s what actually contributes to your Soak value aside from your Might stat points and your Endurance skill points. As soon as I started working on that, I realized that I had sort of painted myself into a corner with my inventory system. My plan is to have one inventory “pouch” that holds all your items, whether they’re weapons, armor, key plot items, or combat consumables. However, so far I had only implemented combat consumables, and my combat code expects the list of inventory items to only include consumables.

I really don’t like the idea of having a “Weapons Inventory,” “Armor Inventory,” “Combat Inventory,” and “Miscellaneous Inventory.” But I also *really* don’t like the idea of rewriting everything in the combat code to support such an all-encompassing inventory list. I realized, then, that this is pretty much a textbook scenario for implementation of inheritance in classes. Most guides and books use animals for the examples- “Pet is a class of animals with four legs, Cat is a class of animals that eat mice, Cat inherits everything from the class Pet” kind of stuff. So, what I need is an InventoryItemClass that implements some basic stuff, like “name,” “description,” “purchase cost,” “icon sprite,” and an ability to return a list of items filtered by type (for example, only combat consumables). Then, WeaponClass will inherit from InventoryItemClass, but also include “damage dealt,” “skill used when attacking,” “melee or ranged,” and stuff like that. ArmorClass will also inherit from InventoryItemClass, and include “soak value.” Perfect.

After spending the last week tearing my hair out trying to make a spiral that matched the image I had in my mind, I feel like I’m starting to identify with some of the characters from that old Junji Ito body-horror comic.

I started working on the layout for the character screen, and realized that I really didn’t have a plan for portraying skill points and stats. In the game, they’re represented by dice just like in Mini Six, the tabletop system I created the (current iteration of the) story in. However, I don’t want it to feel like the digital version of a tabletop game- I want it to just be a story-driven game. Nothing against Baldur’s Gate, or anything else that integrates mechanics from roleplaying games into their stats, but I think that sort of thing narrows the audience down a little bit.

So I needed a way of representing the values of skills and stats. In this system, each skill is associated with a stat, and the points you put into that skill are additive with the base state when it comes time to “roll a check.” For example, the character might have 3D+1 (three six-sided dice plus one pip) in Might, and then they’ve added an additional 1D+1 into their Brawling skill. The next time they try to punch someone, they get to roll four dice and then add 2 to the result (since Brawling relies on Might). Initially, I thought about just showing some large symbol as a dice, and then fractions of that symbol to represent pips (three pips equal one dice, since the average roll on a six-sided dice is going to be about 3), but that just didn’t feel unique enough- it reminded me of health and pieces-of-heart from the Zelda games.

Next I considered just a single bar, with all the dice converted into pips for a single number. The “stat” pips could be shown in one color, and then the skill pips would get added to the end of the bar in a different color. I felt like this was a closer representation of the actual value, but even less unique as far as roleplaying and stat-based characters go.

Eventually I settled on cross between the two- each pip could be represented by a symbol that linked to itself, and they’d spiral around an icon that represented that particular stat. When the character earned pips, (for “leveling up”) I could just show it as whatever symbol I ended up using to represent the pip in the dialogue box. Now I just had to find some symbol that would tesselate into a spiral like that. I was picturing something like a hexagon, but smushed so that its “inner” sides were smaller than its “outer” sides. I spent hours looking for something that would work, with the constraint that I didn’t want the symbols on the outer radii to be significantly larger than the inner ones- that would imply that the skill points you earn at higher levels might be “worth more” than skill points at lower levels, and that’s not what I wanted to convey.

There just doesn’t seem to be any such shape- I’m sure it’s some sort of mathematical constraint, but it felt weird to be able to sort-of picture it in my mind but not be able to get it down on a piece of paper or find anything similar in Google Images. I finally settled on using just a regular spiral, but with segments of equal arc-lengths and thickness. I could still color them differently to indicate stat vs. skill, though I’d lose out on showing that symbol when the characters earn skill points (probably not that big of a deal in the long run). Something like this is what I was picturing now, and it felt much more reasonable:

Apparently, though, I completely underestimated how difficult it would be to reproduce this in Unity. First, I ended up having to use the LineRenderer object to get anything like this at all (unless I wanted to have a million different sprites to piece together every time I wanted to create a spiral). Unfortunately, it looks like the LineRenderer isn’t really intended for UI objects, and doesn’t work on canvases that are shown as an overlay (which took a while to realize), so I ended up having to create a new Canvas in camera space instead to draw everything on.

Drawing the actual spiral is actually very simple- I wanted an Archimedes spiral, where the distance between the coils doesn’t change as the spiral gets larger and larger. That’s a simple formula in polar coordinates, and converting polar to cartesian is no big deal. The tricky part, it turned out, was getting segments of equal arc-lengths. The formula for calculating the arc length of a portion of an archimedes spiral is… daunting:

It’s complicated because it involves integrals of trigonometric functions and exponents- this isn’t something I wanted to attempt in Unity. I found someone who came up with an estimate based on radius by assuming a circle instead of a spiral, but it didn’t work out very well for me. In the end, I finally just cobbled my own equation together based on trial and error- it’s definitely not a mathematically-accurate formula for calculating anything useful, but on the scale I was working in, it gave me a visual approximation of equal-ish arc-lengths:

Now it was just a matter of prettying it up. It was no trouble at all telling it to draw the different segments in different colors/materials based on whether that segment was part of the base stat or part of the skill points. I generated another spiral behind the whole assembly that was just black in color, and sized so that it would look like an outline for the segments. Then, in front, I placed a round image with an icon representing the base stat. Easy-peasy, right?

Except I started getting caught up in how Unity draws LineRenderer objects again. That second Canvas object I made to hold the spiral worked great up until I added the stat icon- for whatever reason, that icon seemed to completely ignore the “sorting order” I created for the UI components, and rendered behind the spiral instead of in front of it. I spent days modifying layers, render priorities in materials, sorting orders, adding/removing/modifying canvases and camera settings- something about the LineRenderer object just threw everything off, and nothing was acting quite the way I expected it to (after checking out Unity forums, it looks like I wasn’t the only one disappointed in how hard it was to work with LineRenderers).

I did eventually get everything working, though I had to go back and redo all my calculations for “is the mouse cursor hovering over this object or piece of text” because I had to drag all my UI objects out of the “overlay” mode and into “camera space” instead. And so I finally have a spiral that renders the way I wanted it to, after an entire week of messing around with it. Time well-budgeted? Probably not. But it’s a good-looking result:

I guess it’s a good thing I’m not under any sort of deadlines.

It’s been over a month since I got back from Borneo, and there’s been a lot of catch-up at work and around the house. Plus, I seem to have picked up a new hobby (macro photography of local bugs), so I have a plethora of excuses for not getting back to work on the game right away.

Excuses, but not reasons. I think, in reality, I’m hesitant to jump back into it because I finally got it to a state where it actually looked presentable. I mean, not as a game, but at least as a work in progress. As soon as I recommence work on it, I’m going to have to take it apart again, and that means making a mess that I *just* got finished cleaning up, that might not be “clean” again for months.

I realize that’s all nonsense, but that’s where my mind is right now. I’ve been putting it off for too long, though, and so I’m upgrading Unity (looks like there was a major version update recently) and biting the bullet: time to get serious again.

So where are my priorities?

• Fix all of the inevitable broken bits that come with upgrading to a newer version of Unity
• Implement some sort of in-combat dialogue system (along with a way of determining which dialogue to use when; I want the combat scene to be completely modular)
• Bring up some sort of character stat screen from within combat (in case you want to check stats/weapon specs/etc; I think in order to keep it simple I’ll be preventing the ability to swap weapons/armor mid-combat)
• Start working on the “full version” of the character stat screen, to allow you to level abilities, swap out gear, and view other information. This will be used during the “down time” scene, which should be the next major phase of the project after combat.

But first: coffee

Well, not entirely. But over the last few days I’ve had to completely reorganize and redo huge chunks of code, and each time it’s started as just a minor “well, I need these two animations to be able to play at the same time” sort of thing, and turned into a “861 compiler errors? How is that even possible?” sort of thing.

I’ve got it back to a (mostly) working state, but I think I’m about to do it all over again, because I just realized there are no animations or health bars when it comes to the “happen every turn” status effects (like bleed damage, for instance). The function I created that runs the “start a new turn” function basically resets everything back to normal as far as things like “currently playing an animation,” “waiting on the user to select a target,” and “selecting a weapon to attack with” statuses, but it also runs the upkeep functions for each special status in effect. Some of them are pretty minor, like the one that boosts an ally’s defense, but for something like “on fire,” I need to be able to play a burning animation, show the affected unit’s health bar, change their sprite over to the “just took damage” animation, decrease their health, and then check and see if I need to kill them off or not. And then if they died I need to figure out what to do if it was about to be their turn (or was already their turn).

And again, like usual, this is sort of a mixed bag- on one hand it’s super-frustrating having to keep going back and redo stuff I’ve already done over and over.

On the other hand, it’s really forced me to optimize my code a lot more than I normally would have by now. Optimization is something I’ve typically saved for last, after I know everything actually works, even though I know that goes against every list of “best practices” in the book. But getting rid of superfluous loops and awkwardly-named variables earlier in the process definitely makes the later-on-down-the-road steps a whole lot easier, so I’ll count it as a net gain.

So what do I have left to work on?

• I’m still tweaking stuff with the “special abilities” in combat, mostly because I’m trying to get them to share code with the “use item” function- they both do exactly the same thing, except the specials have cooldowns per person, and the items are dependent on how many are left in your inventory.
• I need to refine all the concurrent animation stuff- I thought I had it worked out, but after realizing that I forgot to account for things that happen right at the start of a new turn, I can see that there’s still plenty left to do.
• I need to implement some sort of in-combat dialogue; I’m hoping I’ll be able to re-use most of the dialogue code I set up in the non-combat scenes. I’m not sure how often I’ll actually use dialogue during a combat sequence, but at the very least it will be necessary during some of the “boss battles.”
• At the moment, none of the weapons have pop-up descriptions (well, they do, but they’re all blank), only two of the items have names (and only placeholder descriptions), and only a few of the specials actually have any code associated with their DoStart(), DoUpkeep(), and DoEnd() functions. I can’t decide if I want to go ahead and get all the “fleshing out” of the combat stuff done now, or save that for later once I have a better idea of what sorts of weapons, specials, and items will be necessary throughout the course of the game.

And, you know, the whole rest of the game, of course. But for now, I’m just looking forward to getting the combat stuff out of the way so I can start working on the “fun” parts. Next week my wife and I are headed to Borneo for the honeymoon we never got the chance for; I think it will be good to have that forced distance from my game and the obligation to work on it, so long as I can get it to a good stopping point before we leave. There’s nothing worse then having to pick something back up that was in the middle of a major mess.

Recently, some friends sent this video my way:

Not only do I love game development “behind the scenes” videos (especially when the creator is obviously passionate about what he’s made), but I love Dead Space, so this video was right up my alley. It went into surprising detail about the technical aspects of the scene in question, and even just the design philosophy behind Dead Space as a generality. Watching things like this always gets me pumped up and excited to work on my own game.

The main problem, at the moment, is that I’m still a long ways from being able to work on the “creative” parts. Right now I’m still working my way though the combat system. On one hand, I don’t want to sink too much time and effort into this aspect of the game, since I’m not planning on combat sequences being that frequent (off the top of my head, I’d say about a dozen over the course of the entire game, maybe even fewer). But on the other hand, I want to make sure I avoid the combats feeling like “throwaways” – they need to feel just as unique as the rest of the game.

I’m having a hard time coming up with things to make combat seem special, like more than just a standard JRPG-clone’s battle. The mechanics will be loosely based on AntiPaladin’s Mini Six tabletop roleplaying system, and I’ll be adding in a few “special abilities” that can hopefully add a little flavor. Outside of that, the only thing I can really think of to spice up combat is to add dialogue to try and bring it back into the plot. If I go that route, I need to make sure the dialogue doesn’t get too repetitive, and is interesting enough that people won’t just “click to make it go away” and focus on finishing the battle instead.

Even implementing that, though, is still “mechanical” in nature, rather than creative. I’ve come to recognize these motivation slumps throughout my process, but I don’t really have any surefire way of getting through them. Mostly I just have to rely on knowing that once I get this stuff taken care of, I’ll be able to work on parts of the game that will actually be more fun.