State Of The Union
What’s up, people? No, I’m not going away for another 2 years. Life has happened over the past month, but now, I’m back to it!
So yeah, long gone are the days where I can put in 8 hours a day of work, 6-7 days a week. I mean hell, I was already doing that while holding down a full time software engineering job. I was 24-26 during those times. I’m now 36. I’m married. I have a house. I have an almost 2 year old daughter. Yeah, not happening.
However, to be fair, I can’t blame it all on that. There is this other thing, called Destiny: Rise of Iron. That launched 9/20, and being the hardcore player that I am, I had to experience all parts of it, on my Hunter, Warlock, and Titan. Story missions, new strike, Iron Banner, and most importantly, the new Wrath of the Machine raid on both normal and heroic modes. I’m sorry! I just had to do it, and get it out of my system. New content shouldn’t be dropping until their annual spring update, so I’m good now, I promise!
But enough about non-Rose of Eternity stuff, because you’re not here for that. Here are the highlights of things I’ve been working towards:
Character Sheet Display On Highlight
After I finished up prototyping displaying terrain details when moving the tile selector around, I figured I would take a stab about character sheets. You know, the standard issue GUI that shows a portrait, name, some stats such as hit points, and other things.
First thing I needed was a Character class that could hold all that data. That was easy enough to implement. This class can technically be the parent class for all units you willl see on the battlefield, ally and enemy alike.
Next, I had to get some sort of on screen representation of them. For prototyping purposes, I decided to just use a 3D capsule object, which already had some default colliders on them. Obviously, it will be replaced by an actual sprite, but that stuff doesn’t really matter at the moment.
Once I had the capsule prefabs defined, all I had to do was drag and drop the Character class script on them, and they were good to go. From there, via the inspector for each of the 2 characters in the prototype, I entered in the appropriate values, including some old portraits I dug up from The Coming. One, made by long time collaborator, Oli Ferrando, the other, most likely included in the original set of assets for Neverwinter Nights 1.
From there, I had to catch events where the tile selector hovers over the capsule, and when it does, pop up the Unity GUI object, which is already set up to read the appropriate data from the Character class.
If you look at the GIF for this post, you’ll get an idea of 2 cast members that will be in the game. One is wholly new, the other, well, if you played the old games and paid attention, you might know who he is.
Movement Tile Highlighting
I’ve been having one hell of a hard time figuring out how to refer to it. But you all know it well. It’s the tiles that are highlighted indicating where the selected party member can move. I did a shit ton of research on how best to implement this, and while I didn’t do it the most efficient way, I was surprised as all hell that it just sort of… worked.
Forgetting for one moment about how I actually calculate which tiles the party member can move to, there’s the entire part of how to display it. Remember, my tile map is a single mesh, which the appropriate number of vertices and triangles for the size of the map I need. Even though you see what look to be individual blocks with their own sprite on them, it’s really just one large texture that has had the sprites dynamically added to it in the right spots.
So if I was doing this right, I would figure out a way to re-draw the texture, but this time, wherever the party member can move, I would need to darken/highlight that sprite before applying it to the larger texture.
If that seems like a lot of work, well, it is, which is why I implemented a poor man’s version.
I simply created a square 3d object that had a height of like 0.5, set the material color to blue (50% or so of transparency), and decided that wherever I needed to show where the party member could go, I would simply spawn one of those squares at that spot. And when they weren’t needed anymore, just destroy them.
Hell, even in this terrible solution, it would have been smart to at least use some caching or something, so that I wasn’t instantiating a new one every single time.
And therein lies the problem. I’m working on a prototype. It doesn’t have to be perfect. I don’t have to spend all the time scaling things. I just need to get things working, so I can determine if this is the proper path forward (engine wise). I know all of this, and have probably blogged about it before. But I always get caught up in doing the right thing, and it brings things to a screeching halt because of it.
At the end of the day, even if my laziness, the performance is quite good, and never dips below 700 FPS while playing it via the editor.
As for the implementation of figuring out which “tiles to highlight”, I poked around for a bit, and found stuff like the oft mentioned “Flood Fill” algorithm. Again, not really wanting to spend too much time on anything, I wrote my own method, that ended up working out quite well. Even better, it literally worked the first time I tried it. As you can expect, I was happy as hell!
As you can see in the last few frames of the GIF, I’ve selected the party member (well, you can’t actually see that, but trust me, I’m doing it), and the combat menu has popped up. So yeah, that’s what’s next. More specifically:
Creating a state machine to handle all the various states that are starting to bloat my code
Work with dynamic menus
Pathfinding for the party members
Most important is the state machine, as that will control the entire flow of the game, all the systems, and whatever else I end up creating. It’s the heart, body, and soul of this game. This, I need to get right (within reason, I can’t go to crazy and spend a month doing it!)