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

Fiancée Game – 05 – Wandering Encounters

Estimated Hours of Work Since Last Update: 4

   As with last time it’s been overlong since I last posted about Fiancée Game. I’d love to give the last excuse as last time (work being busy), but I don’t really have anything to blame but my lack of putting time aside to program. Still, a bit of work has been done!

Message System
   I’ve implemented a buffer system for message handling. Previously all messages would appear in the message box the instant they were ordered. This tends to get confusing in combat where you might make multiple attacks which will quickly fill the message box without actually letting you know what the results of the attacks were.

   Fiancée Game now prints messages in the buffer word-by-word until the buffer is empty. I think this is a much better way of doing things. I do want to implement a ‘lock’ system to the message system that prevents the player from taking action until a given message has finished displaying. I’m thinking that this will mostly be used in combat. I’d also like to get the ability to play sounds along with messages implemented, but it’s not a high priority at the moment.

Encounters
   In working to get the combat system up to a playable state, I’ve added wandering encounters. As it stands they take the form of floating capsules that meander randomly around the map. They respect walls and pits, so you don’t see them appearing out of nowhere or floating in the air.


Here comes trouble.

   As it stands, all random encounters are with a set group of enemies (a trio of kobolds, for now). I do want to implement randomly selected groups of enemies. Doing so won’t be too much work, but I wanted to get something playable implemented before doing anything complex with it.

   The Fiancée has stated that she’d like to eventually be able to clear areas out but have other (likely optional) areas that have constantly respawning enemies that she can use to grind levels should the need arise. I see nothing wrong with this, though I’m sure figuring out a system of persistence between game sessions is going to be a bit of work.

   My eventual plan, I think, will be something akin to Gauntlet where there are monster spawners that can be destroyed to stop the flow of monsters in a given area. I do plan on having set encounters (boss monsters, rare optional fights, and so on) that are only ever there once and do not respawn. I also plan on having some spawners that the player cannot destroy so that the player has areas to grind out levels if they need to.

Combat
   The core combat system is in much the same place as it was as of the last update. I’m hopeful that, having finished working on the above, I’ll be able to put some serious time into getting it fully functioning. There are still some things I’d like to finish with the message system (notably the locking system mentioned previously) before I get everything working fully.

Equipment
   I’m thinking strongly of overhauling how special properties function on equipment. I’m thinking of moving away from each property being its own class and instead simply making them into variables on the items and having the effect of the property based on the variable.

   This would mostly be for simplifying things on my end and wouldn’t really be noticeable from the player’s side of things since items that have unique properties would still have them, they’d just be a unique variable instead.

   Of course, I could always stop being lazy and instead program a proper effect handler but I’m currently undecided.

Read More Fiancée Game – 05 – Wandering Encounters

Fiancée Game – 04 – CharGen

Estimated Hours of Work Since Last Update: 8

   It’s been a lot longer since the last update than I’d intended, apologies for that. Life does, as they say, have something of a tendency to get in the way. My day job has been extremely busy of late and, between that and longer hours at my second job, it’s been cutting into my free time for both Fiancée Game development and LPing.
   That said, I’ve managed to squirrel away a few decent chunks of time over the past month-ish to work on things and get some additional systems implemented. Let’s dive in, shall we?

   Here’s a quick look at what the above eight hours have turned into:

Character Creation
   I spent around three hours getting character creation implemented into the game. It’s fairly simple looking, but it does what I need it to do. The player can name themselves, choose a class, and roll their attributes before beginning play. I decided to go with randomly rolled attributes because my fiancée really enjoys both the randomness and the “one more roll and it’s all 18s” aspect of the system.


Character generation is basic, but it does what it needs to do.

   There are the beginnings of some deeper systems in play here. Skills are going to be something that I’ll be needing to implement to finalize character creation. Three of the four classes begin play with a predetermined skill (the adventurer being given a skill point instead). In addition to a starting skill, each class begins play with a small bit of gear appropriate for them along with a pittance in gold — I’m thinking between 50 and 100 — enough for a night or two at the inn in town and maybe a healing potion.

   The only things left to be implemented in character generation are a “Begin Play” button and the ability to spend randomly generated bonus points on ability scores. Outside of that it’s fully functional.

Combat
   Up until now combat had more or less only been implemented in the UI sense. I’ve not got some basic fighting implemented, at least on the player’s side. The player attacks properly (with calculated miss chances), with the appropriate number of swings depending on weapon(s) equipped, and deals appropriate damage based on their equipped weapon and other assorted statistics.

   The current systems I have in place for attacking are likely to be re-coded in their entirety before combat is finalized. I want to separate some functions and I have to implement weapon properties, which should be an adventure.

   Once player attacking is where I want it, I need to work on the enemy’s ability to retaliate. I’ve currently got a handful of ideas on how I want to do this based around assorted types of enemy behavior. I want to make it so some enemies favor using special attacks (spellcasters), while others will favor attacking but might occasionally use a special attack if they have it (general critters). There are going to be sub-types to the AI, I think; a spellcaster, for example, with special abilities keyed towards healing its allies will probably have AI written around making sure all of its allies HP are greater than 50% and healing them when it isn’t. That kind of stuff. I’m looking forward to it as I’ve never really dealt with anything resembling complex AI before, even in a turn-based setting.

Equipment
   Amidst working on all of the above, I also went back and re-wrote how the game handles the player’s equipment. Nothing major, but it speeds up the various look ups I have to do for determining final statistics and whatnot.

Read More Fiancée Game – 04 – CharGen