Author: Gene

Fiancée Game – 08 – A Little of Everything

Estimated Hours of Work Since Last Update: ~15

   As per protocol it’s been a while. As per protocol life has been busy for me. Alas, it seems that whenever I finally get into a good rhythm of working on Fiancée Game that everything gets chaotic all of a sudden. Strange.

   Anyways, I’ve got an update. A fairly substantial one. Lots of stuff has been done in the ~5 weeks since my last post. I also set up a Trello page if you’d like to follow development as it goes on, minus the witty banter that I know you all come here for. I’m not going to go over every little thing that I’ve done, but I’ll cover the major stuff here. If you want a more granular look at everything that’s taken place for this update, use the link to the Trello page above.

Of Tooltips and Optimization
   The most time consuming thing I’ve worked on for this update has to have been either tooltips of game optimization. I completely rewrote the tooltip system from the ground up. It’s a lot faster now. Like, a LOT faster. It also supports multiple kinds of tooltips instead of just tooltips for items.


We now have tooltips for stats!

   While I was working on tooltips I’d noticed some fairly heinous slowdowns. Fiancée Game typically sits at around 400 FPS on my system. For whatever reason, tooltips were slowing this down to about half that (!!!). The reasoning behind this was how I was displaying them. I’d originally had the tooltip display running once per frame for every object that could display a tooltip because I was being a lazy ass (and it wasn’t particularly harmful to the FPS early on). However, as time went on, the number of objects increased and running the same bit of code ~100 times per frame does have an impact on performance.

   The fix was easy enough. I stored all objects that could have a tooltip in a global list. Once I’d done that, I moved the displayTooltip function from those objects to my IO handler that checks the list once per frame. If it finds that an object should have a tooltip displayed it displays it. There is now no FPS loss for tooltips.


I also prettied up item presentation a bit. Item subtypes were added, too.

Skills and Leveling
   Gaining levels has been implemented. I’m still fooling with experience point requirements but I’ve got the larger details set. I’d originally expected a fairly low max level, but I’ve gone back on that. Instead of the level cap being the original ~20 that I’d initially planned, I’ve bumped it to 100. Why? Well, future-proofing, for one. I don’t expect that the ‘base’ Fiancée Game is going to have enough content to it to even remotely hit the level cap. The Fiancée™ has, however, demanded that there be future expansions, so I’m leaving room for those. I expect the base game will be completed in 30th to 40th level range. Or more, assuming she grinds a lot. Which she does.

  Currently gaining a level nets you some extra health and energy based on your class. You also get ability score points and skill points. The rates that these points are gained vary based on the level band you happen to be in at a given time. Skills and abilities are gained quickly at lower levels, but less frequently as the levels pile on.

   There’s currently no grand fanfare when you gain a level, just a message in the message box. I’ll eventually get some sort of graphical flourish implemented so that the player knows they’ve gained a level.

   I’ve begun implementing skills. I currently have all the basic skills for the rogue skill tree implemented. While getting skills working (and getting the UI put together for them) I discovered that I’d have more room than initially intended — almost twice as much space, actually.


We also have tooltips for skills.
There’s still some formatting work that needs to be done.

   My original design for Fiancée Game was to have four tiers of skills. With the new UI put together I have room for seven. I spoke with The Fiancée™ about this and she was okay with the idea of an expanded skill system. We brainstormed how we were going to handle the extra tiers and settled on a ‘specialization’ system. How it will work is that the first three tiers of skills for a given skill tree are considered ‘basic’ skills and anyone can learn them. Tiers four through seven are considered ‘specialized’ skills and when you hit a specific level (I’m leaning towards around 12, or so), you’ll pick a specialization and be stuck with it for the rest of the game. You can have a specialization in each skill tree that you’ve invested a certain number of points into.

   Each skill tree will have three specializations (the rogue’s, for example, are acrobat, assassin, and thief) that offer different styles of play within a given skill tree. Using the aforementioned rogue specializations: the acrobat is for avoiding damage via evasion, assassins are great for single target damage and damage over time, while thieves are good at stealing things from enemies and getting more treasure in general. In addition to unlocking specific active abilities with each specialization, a specialization will grant passive bonuses as well. The assassin, for example, will grant bonuses to damage with daggers and will add a poison-based damage over time effect to the rogue’s bandoleer/fan of knives and dagger toss abilities.

   I’d originally thought to lock the specialization trees behind skill point expenditures, but with the rate that skill points and ability score points are gained I’ll likely just go with a “you have to find the trainer” method instead. I think it’s better this way anyways since it will encourage exploring the world more than just hoarding skill points instead of spending them on interesting skills.

The Stuff I Work On Instead of Fixing Bugs
   It hate bugfixing. Not because it’s hard, but because it’s time consuming and often tedious. I fix critical bugs, but most smaller niggling bugs remain, or have been given band-aid patches.

   Instead of fixing the bugs in my old spaghetti code, I instead implement totally unnecessary features that really should wait. But they don’t. Because I hate fixing bugs.

   So, what has this amounted to? Three big things as of right now. First was loot piles (and examine text):


My inner loot whore is breathing heavily right about now.

   I programmed loot piles mostly as an exercise of boredom. I’d just finished debugging some god-awful bit of combat-related horribleness and wanted to add something to the game as opposed to fixing things that I’d broken. Loot piles were the result. They’re hand placed but I have the ability to fill them with random goodies from a list as well as have a chance to not even spawn. Yes I fully intend to plug one of these things in somewhere that has a 5% chance to spawn and then another 5% chance to spawn some stupidly powerful item. Because I can. And because The Fiancée™ needs to know that this game hates her.

   With the loot piles I also implemented examine text. It’s fairly simple: if the player right-clicks on an object in the world it pops up a bit of descriptive text in the message box. You can examine objects, but not things like walls or doors (I would hope that we all know what those are). I eventually want to have it display the description somewhere more prominent on the screen, but there’s no rush for that. I’ll probably use this descriptive text system at some point in the future to give hints to the solution of puzzles or the location of secret areas.

   Up next came in-combat damage splats which I shamelessly burgled from the excellent Eye of the Beholder games — buy them on GoG (or, failing that, watch either my or Captain Planets’ LPs of them (#shilling)):


Believe me when I say that my splats were… lacking.

   While I’m generally opposed to adding ‘pretty’ things unless they’re necessary at this point in development, I’ve felt that combat needed some feedback-related love for a while now. I added these because, dammit, who doesn’t like seeing damage numbers flying around?! I fully intend to have combat-related sound effects implemented for the next update.

   And, finally, monster spawners:


It spawns things that want to kill me.
Joke’s on it; player death isn’t implemented yet!

   These were implemented because, frankly, I got tired of having to restart the game to continue killing stuff. I guess it’s a good sign that I like running around murdering things. Means the core gameplay isn’t completely terrible. It’ll be better once I’ve gotten more combat-prettiness implemented and have got the skill trees filled out.

   Oh, and I also implemented a basic music player. No screenshot for this one (still haven’t mastered filming sound waves quite yet), but it’s there. Music now changes depending on whether you’re in combat, exploring, creating your character, and so on. I’ve got the music player implemented in such a way that I can have exploration music changed based on tile that the player is standing on. This will be used for per-zone music. Handy stuff. I mostly play with the mute on, though, since listening to the first ten seconds of the same track over and over again has somewhat begun to grate on my nerves.

Bugs that I Did Fix
   Only a few bug fixes for this update. Truthfully most of the bugs that are currently running around are so minor that I just ignore them the majority of the time. They’re things that I’ll need to take care of eventually, but I think it’s more worthwhile to be implementing new features than fixing them. Still, I did take care of a few:
   – Enemies weren’t dying when reduced to exactly 0 health.
   — Pretty simple mistake. I was checking an enemy’s health improperly (health >= 0 is alive), easy fix.

   – Fixed a reference bug for enemy Attack values.
   — This was another easy fix. I’d borked up the reference code somehow and each enemy was referring to the next enemy in line’s attack. I didn’t even notice this until I was working on a boss monster whose attacks really shouldn’t have been missing and yet inexplicably were. Sneaky little bug.

   – Fixed a camera display issue that cropped up when the player was on the edges of the playable area.
  — This bug was caused by how I have the player peer forward and down when standing on a ledge. The script itself works by referencing the cell ahead of where the player is standing. If the player was at the edge of a map there’s no cell to reference (null reference error) and it would lock up the camera. I simply added a check to make sure to only call the ledge peer when the player was in an area it would actually work.

In Closing
   While I haven’t had nearly as much time to work on Fiancée Game as I’d like to have over the past month, I’m more than happy with the amount of work I’ve gotten done in the time that I did have. Hopefully things will keep moving along this quickly! Thanks for reading!

Read More Fiancée Game – 08 – A Little of Everything

Fiancée Game – 07 – Enter the Companion

Estimated Hours of Work Since Last Update: ~11 plus a 4.5 hour dev stream

   Hey, a weekly update that’s actually on time! Not only that, but I’ve hammered out a decent amount of work this week, too, due to catching a really nasty head cold and otherwise not being up to doing much around the house.

   Last Saturday (the 2nd) I even streamed some development of Fiancée Game and had a really good time. Definitely going to do that again!

   Anyways, enough about all of that, time to dive into all the new things I’ve gotten plugged into the game this week!

The Companion
   The player’s companion has been implemented to the point where it’s combat effective. It derives all of its stats off of the player’s, so as the PC gains more power so does the companion.

   I still have to implement some display information for the companion and I feel that I need to tweak his final stat values a little bit, but overall he feels like he’s about where I want him to be.

UI
   I dislike UI work. I find it incredibly tedious, even though Unity makes it easier than doing it by hand. Still, I actually got a decent amount of it done this week with regards to adding a character sheet to the game.


So I hear you have a thing for numbers…?

   I would say that I spent between four six hours getting the character sheet implemented to its current state. Most time was actually spent getting the information I wanted in the space that I had. As you can see above, there’s still room for just a little bit more information in the ‘Secondary Stats’ section but I don’t have anything to put there yet. I also still have to implement variable display for resistances, but I’m not in a rush to do that since they aren’t taken into account by anything yet. Graphically it’s a work in progress and I haven’t even started on the Companion character sheet, but it should mostly be copy/paste work. I also need to implement the character sheet (and skill sheet) closing the inventory and minimap when the player opens them on a screen with a resolution that has a width less than 1080 because otherwise they obscure the player’s inventory and gear.

   I also spent a few hours completely rewriting how the game handles tooltips. The previous method was sloppy and slow, now all tooltips pull their functions from the global functions script instead of having to do everything in their own script. I also changed how they display a bit; now if they’re an item or a skill they show the icon of whatever you’re mousing over in addition to providing the relevant info.


An item tooltip! Still a bit of a work in progress, but I like ’em better now.

Combat
   The combat saw a bit of work this week due to the addition of the Companion. I had to add functionality to all current ‘kill the thing’ scripts so that enemies will properly damage the Companion and so on.

   During the Dev Stream I implemented a victory screen that pops up after combat and gives the player a chance to grab their post-murder rewards. Assuming they survived. Item drops are added to a small ‘loot’ list and can be taken if the player desires. I’m planning on re-writing how the loot slots function in the coming week since they don’t currently support the rewritten tooltip system.


We survived a fight and even managed to snag an item out of it!

   In addition to the spoils of battle, the player can now gain levels. Currently a level grants you some bonus health and energy based on your class, three points to allocate to ability scores, and a skill point that can’t be used for anything quite yet. I’m hoping to have a rudimentary version of the skill system implemented by next week but it’s going to require some work on other systems to tie in functionality for things like passive skills.

Bug Fixes
   As per protocol there were a handful of bugs that I set out to take care of this week. I think that from now on I’m just going to copy/paste my notes on bug fixes instead of going into long paragraphs over them. So, for this week, I fixed the following:
   – Enemies at low health (2/22 HP on a kobold chief) have a full health bar display. Probably an error in handling the display as opposed to math error.
      – Yup. Display error. Didn’t take into account enemies with 1% – 9% health, only 10%+.

   – Null item returns when rolling for loot for a creature that has a loot table but doesn’t throw out any loot. Probably not really an error, just a poorly placed Debug.Log command.
      – I didn’t take into account the player just not rolling well enough to get loot. Whoops.

   – Torch timer counting down when not in ‘exploration’ mode.
      – 30 second fix. Made sure that the timer only counts down in exploration mode.

   – Doors (and secret doors) facing N/S don’t work because reasons.
      – Code was correct, but the script was referring to the door’s button’s worldspace position instead of the door’s. This lead to… problems.

   – Fix borked particle effect on N/S doors.
      – I was incorrectly getting the parent object’s rotation. Looking at the base rotation instead of getting it as a Euler angle.

   – Player Health/Energy bars do not move on the Y axis when re-positioning them in the UI. Has to do with their vertical resizing.
      – Linked their position on the Y axis to their parent object’s Y position. Easy fix.

   – Finally fixed all the null reference exceptions to things that exist. Was due to scripts looking for stats at the time of creation. I pushed the referencing code from Update to LateUpdate so everything has a chance to set itself up for proper referencing.

   – Gold drops at the end of combat are borked. Waaaaaay too high.
      – Was rolling dice based on min/max gold for an enemy instead of generating a number between min/max. Rookie mistake!

In Closing
   This was a really solid week for me with regards to getting things implemented in Fiancée Game. I’m hoping the coming weeks are as fruitful.

   As you might have noticed from the screenshots above, the worldspace looks a bit different. I’ve scrubbed out all of the realistic looking graphics and I’m aiming for a more 8-bit/16-bit feel to how the world looks. I just think it works better this way, plus it gives me an excuse to avoid having to 3d model decor for the world, I can just use 2d sprites instead. Fun!

   In the coming weeks I want to finish up the UI work that I need to do, which will amount to finishing off the Companion’s character sheet as well as the skill sheet. I also want to get tooltips implemented for non-skills/items so that a player could, for example, mouse over their might score and it would break down where its total is coming from.

   The biggest upcoming hurdle is that I also want to get skills for both players and enemies implemented into gameplay. Once that’s done I’m going to have to do some work on getting a proper AI routine put together for the enemies in combat. My experience working with AI is dated (very dated) so it should be a learning experience, to say the least. I’d also like to do more development streams; I had a really good time with the last one, though I’ll probably keep them a bit shorter than four-and-a-half hours.

   Until next time!

Read More Fiancée Game – 07 – Enter the Companion

Fiancée Game – 06 – UI Work and Combat

Estimated Hours of Work Since Last Update: 12 to 16

   Unlike the past few updates, I’ve been putting a fair amount of work into Fiancée Game over the past few weeks. My goal is to get something playable in her hands by the end of July. I’m fairly sure that if I really bust my butt, I could have something playable in her hands by the end of next week.

   I don’t want to say that this post is going to be massive, but there’s a pretty decent amount of stuff to go over since last post, so, y’know, hold onto your butts, or something!

UI System
   I’ve moved all existing UI elements over to the new UI system introduced in Unity 4.6 (we’re currently in version 5.3, I made most of these elements before Unity 4.0 released) and gotten them jiggered so that they properly place themselves dynamically on the user’s screen.


All elements of the UI dynamically place themselves based on resolution.

   Most of the elements were easy enough to transition over, but I had to reprogram the minimap in its entirety. It was something that needed to be done since the previous method I used to draw tiles was hardcoded to the size of the minimap and was something that I’d always intended to replace.

   While the minimap looks and functions identically I can now, with the re-write, make it scale to be as large as I want it to be. This scaling will be useful later on when I implement a larger ‘world map.’

   I implemented health and energy numerical displays to the player portraits. I’m hoping to eventually get status effects on them, too. Think Baldur’s Gate minus the red coloration on the portrait itself.

Music & Sounds
   I’ve added rudimentary support for a music player to the game. I’m planning to expand it to play music based on where the play is in the world. I don’t expect this to be too difficult to implement since I’ll likely just be reading what music to play based on the tile the player is in. I’ve already added music_Exploration, music_Combat, and music_Boss elements to the dungeon system so it shouldn’t be too painful to hook this into the music player. It’s definitely something low on the priorities list, though.

   I eventually also want to hook the ability to play sounds into the message system. This will mostly be used in combat to play sounds when attacks hit or miss, and when abilities are used. I could also use this for adding sound effects to certain cells when the player enters them.

Combat
   The combat system has seen the most work over the past few weeks. I’ve implemented a rudimentary combat loop and enemies now fight back (currently only with basic attacks). I’ve also finally gotten around to implementing enemy name displays and even threw together a (poorly drawn) health display system for the enemies you’re facing in battle. I still want to add some visual feedback (blood splatters, enemies shaking around when hit, floating damage numbers, et cetera) to combat to give some feeling to attacks and whatnot.


Fite me IRL, ye scrubs!

   I currently need to implement a victory/defeat screen so there is a chance for the player to obtain precious loot from defeated enemies, or taste defeat after a total party kill. I also need to stop putting off the implementation of the player’s companion.

Bug Fixes & Functionalizing

   The third enemy present in combat had been causing issues for a while where the game would not properly display its name and its attacks really didn’t do anything. I’d put off working on this until I got to fleshing out the combat system itself. The fix was simple enough, I was just passing a target variable incorrectly. Easy fix, but in doing so I noticed a few other bugs that had crept into the code via lazy copy/past proofing. That’s Late Night Coding™ for you.

   Player health bar displays were bugged (read: not actually displaying health) due to
changing how player health is displayed in-game. I went back and fixed
them. Also fixed a display error that cropped up when health was reduced
to less than 0 and then increased to a value higher than zero again. I still have to implement the companion health bars.

   The biggest bug I fixed was actually with how the combat system read monster stats. Early on I’d run into a bug where sometimes enemies would die even when you missed them without having damaged them in the past. I had no idea what caused this bug, but it revealed itself in earnest once I’d implemented health bars for enemies. Looking into it, it had to do with how C# (and most programming languages) handle copying data. For example, if we were to use the following code to instantiate a new object (assuming that class_Enemy is a class containing an enemy’s stats):
  class_Enemy enemy0 = new class_Enemy();

   We would expect it to create a copy of the data present in class_Enemy within the new enemy0 object. It doesn’t, instead it creates a reference. Why is this? The reason is because by default C# makes a shallow copy of data when you copy it in the above way. What does this mean? Basically this:


Thusly have we learned the value of a deep copy over a shallow copy.
And yes, I’m aware of the typo.

   What this means is that if you change a value in the reference for one object that uses that reference, it changes it for all objects that use that reference. So, if, for example, I had an enemy with 5 HP and dealt 6 damage to it, ALL enemies with the same reference would take that 6 damage.

   While this isn’t a problem in some cases like the player where there’s only one of them, it cause issues where we might need multiple copies of an object that have slightly differing stats. This would be an issue with the item system, too, if I weren’t using static items. It’s certainly something I’ll have to keep in mind in future games, though.

    Finally, I spent several hours segregated a lot of code into its own functions. This makes it easier to call for various things I might need to use it for. Dealing damage, for example, was previously hardcoded into attacks, now I’ve separated it into its own function that can be called wherever I need to do so. This is super handy and cuts down on useless code bloat. There’s still more to be done, though. Lots of old Late Night Code™ remains and needs to be replaced or optimized.

In Closing
   I’ve gotten a lot done in the past two weeks. Substantially more than I’d intended to, in fact. That said, my list of ‘things wot need done’ is still growing more than it’s shrinking. For every feature I implement I make note of things that I want to do to polish it (I want enemy health bars to have visual effects when they take damage, for example) and that bloats out the stuff that I need to do. Most aesthetic features are noted as ‘low priority’ so I don’t feel a need to rush on them compared to more important things like getting various systems implemented.

   I’m thinking that the next thing I tackle will probably be adding the player’s companion to the game followed by implementing proper victory/defeat screens in the combat loop. Past that? Who knows. Maybe some world building is in order. But before I do more building I want to fix doors being bugged…

Read More Fiancée Game – 06 – UI Work and Combat