A Timelord's Travel In Thedas | Alazander's Blog | Baldur's Gate II Redux | Community Contest | Creations of AmstradHero | Dark Sun Glare Blog | Ossian Studios | The Sanctum | RP Singh

2016 : Aug | Sep | Nov | Dec
2014 :
Jan | Feb | Mar | Apr | May | June | July | Aug | Sep
2013 :
Jan | Feb | Mar | Apr | May | June | July | Aug | Sep | Oct | Nov | Dec
2012 :
Jan | Feb | Mar | Apr | May | June | July | Aug | Sep | Oct | Nov | Dec
2011 :
Jan | Feb | Mar | Apr | May | June | July | Aug | Sep | Oct | Nov | Dec
2010 :
Jan | Feb | Mar | Apr | May | June | July | Aug | Sep | Oct | Nov | Dec
2007 :
Jan | Feb | Mar | Apr | May | June
2006 :
Jan | Feb | Mar | Apr | May | June | Oct | Nov | Dec
2005 : Aug | Sep | Oct | Nov | Dec


So, I was supposed to start working on some version control. To be fair, not a lot of work has to be done. I just need to create a Github repository for the project, create a prototype branch, and check in the code. But damn if I'm not getting distracted integrating sounds and music into the game!


You know, it's a weird thing regarding sound effects. On all the other Rose of Eternity games I've made, I never had to put that much thought into the bread and butter SFX. Menu cursor, confirmation button clicks, etc. It was already in the game, and out of everything I was doing to make those earlier games as custom as possible, those effects (if changeable at all) we're not on my radar.

Fast forward to today, and well... It's a thing now. I actually have to implement it. And let me tell you, I had to sit back and think a lot about it. Because I've never thought, "Oh yeah, when moving the cursor, it has to sound like this!". As I said, just not on my radar. I ended up looking up some videos of other RPG's to get a feeling for what they used, what worked well, what didn't, etc. I also fired up some stuff that I had on hand.

Since I'm not looking to spend $ on anything during this prototyping phase, I ended up using Fantasy Menu SFX from the Unity asset store. It's good enough to get me going, and has everything I need at the moment.


Ah, music. If SFX is something I have never given any thought to, music is the complete opposite. I'm always thinking about how to integrate music into my games. Anyone who has played them, or followed this blog for a while knows how important video game music is to me. Hell, I'd list it as one of the main pillars for my games.

One thing that I've long wanted to do (I'm talking about since the good old NWN days with Cry The Beloved) is have dynamic music in my games. Not, what they call horizontal dynamic music, where the music changes to another track when something happens in the game, say a combat encounter starts, or you leave a village and enter the forest. Well, I actually do want that as well, but that's not what I'm talking about.

I'm talking about vertical dynamic music, where you have a track that plays, and then depending on the event, maybe some instruments are added to it, say, percussion. Nintendo has been doing this for years now. Think about the music in some Super Mario 64 water levels, where the music removes some instruments when Mario goes under water, and adds them back when he comes out. Or Super Mario Galaxy during the first Bowser fight, where the longer you fight him, a chorus is added to the music.

One thing that has really inspired me is the music in the 3DS Fire Emblem games. Up until that point, besides a few songs here and there, the music in those games was passable. It wasn't terrible, but it wasn't the best. All of a sudden, starting with Fire Emblem: Awakening, it's like they got a whole new budget or something. The music is absolutely superb, and one of the best parts of it is the dynamic elements to it.

For most levels, there are "calm" and "fire" versions of the songs. "Calm" is when you're in the menus, selecting what unit you want to move, etc. "Fire" is when an attack/heal/ability/etc. is happening on screen. The way it transitions between the two is magical to behold, and for me, one of the best parts of the game. You better believe that I immediately went out looking for the soundtrack.

Now, their implementation wouldn't work for me, because all the combat will take place on the board without transitioning to some "attack" cutscene. The switch to the "fire" music would only last 1-2 seconds at most.

No, the way I have figured out to use it is with using the range between allys and enemies. Basically, if anyone is within range of an enemy (or vice versa), the music will change to the "fire" version, and then move back to "calm" when not.

At first, my implementation just didn't seem right. The music did switch, but it was jarring. It was then that I realized that I needed to smooth the transition out. I needed to slowly fade out the old music, while at the same time, fading in the new music. Functions like the below ended up working out great for me:

    private void TransitionMusic(AudioSource audioSource1Stop, 
AudioSource audioSource2Start) {
        print ("TransitionMusic");
        StartCoroutine (FadeOutMusic (audioSource1Stop));
        StartCoroutine (FadeInMusic (audioSource2Start));

    private IEnumerator FadeInMusic(AudioSource audioSource) {
        float volume = 0.0f;
        while (volume < 1.0f) {
            volume += Time.deltaTime;
            audioSource.volume = volume;
            yield return null;

    private IEnumerator FadeOutMusic(AudioSource audioSource) {
        float volume = 1.0f;
        while (volume > 0.0f) {
            volume -= Time.deltaTime;
            audioSource.volume = volume;
            yield return null;

Once I had this in, oh man, that dream I've had for, well, 10 years, finally came true. Hearing the music change when getting within range of enemies was awesome.

Add in the other SFX I added, and well, this game is seeming more and more like a game.

Good times.

Till tomorrow...


Ah, good ole Unit Tests.

When I joined the industry in 2004, my company, Vindigo, was all about Extreme Programming. One of the pillars of it is test driven development. Unit tests in particular are pieces of code that test particular components of your code, usually the public methods in your classes. I won't go into all the details of it, but unit tests give you some level of comfort (when written properly) that if you make changes to the functionality of your application, if tests pass, you probably didn't break that much stuff.

So from the start of my career, I was taught the right way to do things. Then, many years passed, we got shut down, and in the next stage of my career, test driven development sort of fell to the wayside, in favor of "Get this shit out the door now!!!". \_(ツ)_/

Recently, it has come up again as something that is very important, which I am very happy about. Like I said, I know better, but sometimes as a developer, you just don't have time to write tests. Sometimes, stake holders don't truly understand them, they just want results, and fast,

So now we come to my game. Even before I started, I knew I wanted some level of unit tests, at the very least. This game will be, undoubtedly, the largest project I've ever undertaken. Add to it the fact that it's going to be a commercial product, and well... I know I just can't rely on QA. So I did a lot of research on the matter, and learned all about the Unity Test Tools and how to make use of them.

It's actually pretty straightforward, and today, I was able to implement a couple tests classes, one for my TurnOrder class (determines whose turn it is to move), the other for my TileData class (holds information like terrain details, current unit standing on it, etc.).

I feel good that I'm moving in the right direction, and it's better that I started doing it now, versus scrambling to do it late in the game.

Tomorrow, I'll look to write some more unit tests where applicable, then start looking at doing something else I know damn well I should have been doing from the start: Source control.

Till tomorrow...


The development train keeps up its momentum with the latest implemented system: Map Scrolling. Yeah, I know, it's not exacly sexy, but it's something that is super important, and key to the look and feel of the game.

Now, as I've said over and over again, I'm still in prototype mode, so I just whipped up something pretty rudimentry. I know there are ways to to improve it, however, it does what I need it to do, and that is all that really matters.

As for how it's implemented, it comes down to the following:

  • You can move the camera left/update/down/right with the AWSD keys

  • If you move the mouse cursor to the end of the screen, the map will scroll in that direction

  • The movement class has a boundary, defined by the size of the tilemap itself. This makes sure that you can't just keep scrolling in any direction forever.

The only real issue thus far (besides just a general level of polishing) is that when scrolling is started by the mouse cursor being on the edge of the screen, it only goes horizontol or vertical. No diagnols at all. Diagnol movement does work with the AWSD keys, so I'm sure it's something small I'm missing. But not going to waste any time on it at the moment.

Something else I'll be keeping my mind on in the future is Pro Camera 2D. This will, presumably, do everything I want to do, out of the box. I'm very careful about not using anyone elses assets, until there is no other recourse. But it's something to keep in mind if I end up needing to focus on other things down the line, instead of wasting time re-implementing camera movement logic.

Anyway, gf course, after I added this new scrolling functionality, you know I had to make a larger map to take advantage of it. It was at this point that I had to go back to my dreaded CSV files I used to dynamically load the maps at run time. Ugh. I felt like I was that guy in The Matrix who had been watching it for so long, he could pick out the girl in the red dress, or whatever he said. I'm sitting here making this map, looking at a spreadsheet of numbers, losing my mind, but at the same time, sort of seeing the patterns form enough to know what I was doing.

There is some software out there, called Tiled Map Editor. I have know about it for a while, but didn't want to deal with it due to the fact that I would really need an all inclusive solution, inclduing allow me to set triggers, waypoints, units, etc., on a map. This software would only allow me to create the map.

However, I just found out that you can export your maps into a CSV file. While I haven't looked at it yet, it might end up looking to be in the same format as mine, and that could be a boon. A sort of middle ground for speedy development of different maps, while I continue to prototype things. As with everything else, I'll just keep it in the back of my mind, as I begin to move on to other important things.

Finally, with regards to keeping things in the back of my mind, well, that's a bad idea. Sort of. I shouldn't exclusively use my mind to remember things. I should use software. For Rose of Eternity - Family & Country, I used the very open Google Code, which apparently shut down in 2016. I already knew it was going to shut down at some point, and archive whatever used to be. I'm a little annoyed I can't find what old project, but... Yeah, anyway, I'm thinking about using the free version of Trello. I just need something visual so I can keep everything together as this project continues to grow.

Till tomorrow...


Even though I knew exactly what I wanted to work on today, the morning started out very slow. I was attempting to do some work in the bedroom while my daughter watched some cartoons, but that didn't work, as she was more impressed with sitting next to me and pressing every single button on the laptop. Then, she laid on me, I decided to "rest my eyes", and a couple of hours later, I woke up, feeling like shit.

I ran off to the gym, got a smoothie afterwards, some tennis balls at Kmart after that, and made my way home. It would still be a few hours until I got into my groove. But damn, once I did, I was very happy with the results!

Today's plan was pretty simple. Take the existing backend structure I implemented for turn orders, and make a GUI representation of it. At first, a lot of the time was taken up by me trying to implement the math involved to position each unit in the proper place, and then I decided to take a step back, and see what Unity had to offer out of the box. As it turns out, there was a lot.

I quickly stumbled across the GUI Auto Layout components of the new UI system, and was good to go from there. Now, all I have to do is add the unit to the panel that has the auto layout on it, and they're automatically added to the right spot. If they're removed, the next one moves up, and if they're added again, they'll be at he back of the line. And of course, I need to make sure to call back to the data class to make sure all the non-GUI stuff is updated as well. Pretty straightforward stuff. Here's some sample code:

    public void AddUnit(Player unit) {
        Image unitImage = Instantiate (imagePrefab);
        unitImage.sprite = unit.portrait;
        unitImage.transform.SetParent (_panel.transform, false);

        _images.Add (unit, unitImage);
        _turnOrder.AddCombatant (unit);

    public void RemoveUnit(Player unit) {
        Image unitImage = _images [unit];
        unitImage.transform.SetParent (null);        
        Destroy (_images [unit]);

        _images.Remove (unit);
        _turnOrder.RemoveCombatant (unit);

Next up is for me is to go back to the data side of things, and actually implement the priority queue, based off of the speed of the unit. Also, I'll need to add more units to the map itself so that turn order GUI can fill up a bit, just to get a better idea of how it'll function.

With regards to adding more units, I think I'll be needed a larger map soon, and with that, I'll need map scrolling :)

Ah, the honeymoon phase of things continues!

Till tomorrow...

11/18/16 -Friday: NEXT UP... UNIT TURN ORDER...

I've been a little busy with work lately, getting ready for a pretty big release in the coming weeks. It sucks, because it's taken so much of my time that I haven't been able to do as much game development as I would like. But, such is life...

So, after I finished working on the pathfinding prototype a few days ago, I realized that I needed the ability to switch back and forth between allies. I spent so much time trying to get the pathfinding working that I didn't do too much thinking about what comes next. It was pretty clear to me that I would need some "Turn Order" system, which would essentially be comprised of a priority queue and some value that the queue could be prioritized off of. For now, just due to lack of a character stat system in general, that value will be based off of a characters SPEED attribute.

I mean, it's exactly as you would expect it. Whoever has the highest speed will be at the front of the queue. If someone has 2x the speed on someone else (whether naturally, or through a spell or something), then they'll have the chance to move 2x before the other person can. The concept is pretty straightforward, it's just going about and implementing it that will be the work.

As of now, I just have a plain old List object, where I'm adding the existing party members to. Whoever's turn it is, only they can be selected to move. Once their turn is over, they'll be removed from the list, then added at the back of it, and it will be the next person's turn. Rinse, repeat. Next up will be some GUI work so you can actually see the turn order on the screen, which will allow you to better plan your next move.

I don't plan on spending that much time on tihis little prototype, but I hope to get a good deal done over the weekend.

Then, I can move on to yet another prototype. Heh, you never really know how many systems are in a turn based strategy RPG until you start making one :)

Till tomorrow...


In my last entry, I ended with saying that I was going to watch another quill18 tutorial on YouTube, and as expected, I came away with lots of new information, as well as an algorithm for pathfinding, which you can see in today's GIF.

Last week, I had some rudimentry movement in place, as a placeholder. Now, the character/unit/ally/whatever is now actually following a set path of tiles calculated using Djikstra's Algorithm. I won't go into all the technical details (if you care, follow the link), but I think this illistration below does a good job of showing exactly what is going on:

The starting point is the south west point, the destination is the north east point. From the starting point, or node, if you will, it continues to branch out towards all surrounding nodes, and when it finds the destination, it will then calculate the shortest path to said node.

On the wikipage, there is some pseudocode, which quill18 used to create his method in his tutorial. I happily took advantage of the work he did for everyone, and integrated it into my Pathfinder class pretty easily. Within a few hours, I was generating paths of nodes (which was easy enough to translate to my TileData class, since it's more or less the same thing... in fact, I should combine the classes, but I'm rambling now...) to make use of whenever I selected where the character should move. Taking those generated nodes, I simply iterated over them, node by node, and had the character transition from tile to tile. Pretty simple stuff.

Oh, and those red tiles you see pop up at the end? That's just some other prototyping work I did to indicate where the character can attack once they've finished their move. I'll get back to that at some point.

Now, some people might be screaming, "Why are you using that algorithm? Why not A*?!!!". Well, it's mostly because quill18 decided to not use A *, and because I actually had restraint for once, and decided to simply get something working. Without a doubt, A * is the better solution. And when the time comes, I'll implement it as well.

Finally, just wanted to end on where my head is at right now. In short, I'm in a good place. My Destiny days seem to be behind me, and I'm finding more and more that I just want to come home, eat dinner, hang out with the family, and once they're off to bed, come down to the man cave to work on the game. Plus there's the time I have on the train.

There's also a co-worker of mine who is also working on a game using Unity. We have our little "Motivation Monday's", which sort of gives me a reason to knock out a lot of work over the weekend so I don't come up empty handed while we show off what we've done. Speaking of the weekend, last weekend was certainly my most productive thus far. It felt like 2006! I think I put in 6-7 hours total on Saturday, another 2-3 on Sunday.

I'm also experienced enough to know (and if you have read my journal, or continue to read this, you'll either know how often I say, or will notice how often I'll say it in the future) that this is the normal peaks and valleys of the emotional state of a game developer. Things are going great right now. I'm energized. I'm focused. I'm hungry. Maybe next week, I won't be any of those things. That's why when I feel like this, I just get it in. No bullshit, no distractions, just good old fashion work.

Till tomorrow...


Well damn, look at that! I'm back, and it didn't take a few months. Maybe I can keep things going this time :)

So, keeping with my rough bullet list of things I wanted to work on, I started the initial work on pathfinding for the characters/units in the game. Actually, before I could even do that, I had to take the spaghetti code I currently had, and try to break it up into logical pieces, so I could then implement a basic state machine to control everything going on. As of now, I have the following states defined:

    public enum GameState {

This has changed many times in the past week, and I'm sure it will continue to change as time goes on. What might make sense as a single state ends up making more sense as two. Or, sometimes I fold up two into a single one. It's all over the place right now, and that's okay, since I'm learning as I go.

Once I had this set up, before I started looking at actual pathfinding logic, I just wanted to test out moving the character from one tile to the other. I already had a pretty decent idea of what I wanted to do (having previously done similiar work while doing contract work on The Shadow Sun).

I basically needed to do 2 things:

  1. Create a function that would slowly move from one tile to another, over x seconds

  2. Make said function a coroutine that is called from the state machines Update() method.

Using my previous experience, I was able to cook something up pretty quickly. But, as you can see from today's GIF, the character isn't following a path towards the final tile. It's just going right to it.

And that's exactly what I'll be working on next. Integrating true pathfinding. Lucky for me, quill18 has a youtube series on it that I'm going to watch tonight. I had previously watched his series on tilemap creation, so I'm expecting some good stuff.

Till tomorrow...


11/1/16 -Tuesday: BACK TO IT...


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!

What's Next?

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!)

Till tomorrow...

Website contents copyright (c) 2006 by Leonard Bedner