Wrapping Up Year #3!

Video Thumbnail
Mischieviots First Trailer

This month marks the anniversary of Mischieviots 3rd year of development! I’m actually quite impressed that I’ve stuck it out this long and to this day am still learning so much about game development itself.

If you’re interested in how much things have changed over the years, you can read all about my prior two years wrapped: First Year and Second Year.

The biggest news to talk about is that, on Feb 26, 2017, Mischieviots (“The Gathering”) was finally released to the wild! That’s right, you can finally play this goofy little game of mine. If you haven’t yet tried it out, you really should!

So, what’s else happened this past year? There were so many little things I couldn’t possibly think of them all, but below are some of the major highlights I did remember:

Let’s start off with a quick overview of the year:

  • Our friends finally got names! (yeah, yeah, in year #3)
  • Added tons of sound effects and map ambiance.
  • Updated monster encounters by making them spawn on the map and wander around a bit.
  • Combat flow improvements (several iterations)
  • Continued memory management and performance improvements.
  • Added In-Game tutorials to let players learn some of the basic mechanic’s of the game.
  • So many visual, interface and cosmetic changes that I can’t even begin to list them all, so here’s a few of my favorites:
    • Screen shaking
    • Walking through small things like flowers
    • Updated inventory and Equipment comparison window.
    • Experience Window Improved.
    • Status Messages
    • Afflictions window

Major time sinks:

This year didn’t involve any major time sinks like the previous years since they involved mostly the core engine/mechanics design and implementation. Outside of a few bug fixes and added features, it’s been very stable and reliable, making all the prior effort worth it.

If I was to list anything for this year though, it’d probably be the time spent during sound/ambiance; although that wasn’t exactly a time sink as it was an entirely new system being introduced.

Future plans:

This next year I’m planning on setting my focus on working through all the content needed for the all the chapters being planned out. I have big ambitions for the overall story/plan, so we’ll have to wait and see how far I actually make it I guess!

Of course, adding in more polishing/features etc will still be on the plate, so I’m always on the lookout for suggestions and feedback from players.

Our friends got names!

I can’t believe it took me this long, but I finally got around to giving our little friends the names and also came up with a short little biography for each one. Here’s our cast of friends in order that you’ll meet them:

Knight: Finley
Scottish for “Fair-haired hero”. Our main character in the game has no significant background and has pretty much spent his entire life aimlessly wandering around from tavern to tavern pretty much accomplishing nothing.
Amazon: Gerarda
Old English for “Brave Spear Woman”. Nobody is entirely sure where she came from. One day she just showed up in town for a competition and amazed everyone with her combat skills; she was immediately offered a job in guard duty and hasn’t left since. She dreams of big things in her life other than just being a simple guard grunt though and is always looking for something else to do instead. She doesn’t talk a lot, but when she does, you’d better listen!
Archer: Frezza
Italian for “arrow”. Fezza has spent many years learning the fine art of archery and has become quite good at her trade. She prefers to live among animals in the forest and isn’t a huge fan of large cities. There are only a few people she would call a true friend, but will do anything in her power to help them when in need.
Mage: Lilura
Basque for “Enchantment”. While very early in her development as a mage, Lilura is a quick study and really likes it when she can fine new shiny magical things to play with. She is good friends with Frezza going back many years and too prefers the more solitude life away from larger cities.
Bandit: Calvin
Latin for “Hairless” or “Bald”. Born with a full head of hair, which his parents were never able to keep control, he was named ironically after his bald great-great-uncle. He was raised to be a free spirit and always speaks his mind, even if it means peeving someone off. Unfortunately, due to unknown events, he was left with nothing but hit wits and attitude to carry him through life; resulting in his life as a bandit.
Dwarf: Gus
Gaelic for “Strength”. He’s Dwarf, enough said!?! Grumpy and very strong willed, Gus has spent most of his life focused on combat training, exploring caves and obtaining as much loot as he can. He’s not an overly great conversationalist, but tries his best when required. Gus isn’t a big fan of free-spirited people though, then tend to annoy him!

 

Sound effects and Map ambiance

I must admit, when I first started this project I hadn’t given sounds or ambiance much thought at all and put only basic placeholders into place. I figured I’d only need to expand on them slightly when the time came to needing more. Boy, was I wrong!

I hired a great guy Jack Powell to work on sound effects for me along with some ambiance for the maps (birds etc). When we first started out I thought that we’d only need a handful of sounds for specific needs (spells, attacks etc). As we dug further though and discussed things in more detail, it soon became apparent that Jack knew much more than me about sound options and how best to present them.

So off we went together on a fantastic adventure as a developer/musician duo working out all the best ways to get the sounds we really wanted. Jack making suggestions on where/how sounds could be used best and me coding things like crazy trying to make it all happen. And it paid off!

We ended up with a very intricate and detailed system of sound “layers”, each one assigned to all kinds of actions/events in the game, allowing us to control and time sounds in almost every part of the game at any time. Many of these sound layers overlap and also have variations of the same thing to reduce loop exhaustion (like walking).

Then we turned our focus onto ambiance (sounds played when wandering around the maps). We used the same layered system from above for birds, bee’s, bugs etc which play at “random” intervals, but still have a very natural feel to them at the same time.

We then decided that some sounds should get louder as you got closer (like walking up to a lake). This resulted in a “sound wave” system I came up with that produced exactly this. If you listen carefully in game, you can hear the sounds of water splashing get louder as you draw closer, then fade out as you walk away. You will also hear multiple splashing (also at various sound levels) from lakes should you be near several at any time. It’s all very subtle, but worth it!

In the end we created a very rich sound quality throughout the game as a whole. I couldn’t speak more highly of Jack and the effort he put into this process. If you’re looking for sounds for your projects, grab him!

Monster spawns / encounters

My original implementation of monster encounters started with the old JRPG style where you have “random” (algorithm, not actually random) encounters which would immediately force you into battle with them.

In recent months I decided to try out something a little different. I wanted to keep the same algorithm for encounters themselves, but instead of forcing the player directly into battle, I would spawn monsters on the map near by the player.

When spawned, these monsters will show up as little pink markers on the map showing their locations. This allows you to choose to walk up to and engage, or simply ignore them and continue onto whatever else you were doing. There could be up to 6 at any time, but might be less if they happen to spawn in places you can’t reach (lakes, mountains etc).

After a certain amount of time, which varies on per monster spawned, the monster markers will change to darker color indicating they’re about to wander off. A short period after that they’ll disappear off the map entirely and you’ll need to wait for a new batch to wander in again.

I’ve done some lot’s of play testing with this new setup and the leveling still works out to be about the same; assuming you go attack things frequently and not ignore every time.

For those who like the immediate encounters, they can choose to turn them back on and not use the spawning. You can change this in the options area of the game.

Here’s a quick little GIF showing the monsters spawning in the forest and walking up to one:

Shortly after the original implementation, I felt that they we’re a bit too boring just standing around waiting to be attacked. So I decided to change that and make them move around a bit when they had room to (sometimes they spawn in places where they can’t move, and thus won’t still). This ended up with them being far less static and much more lively looking:

WanderingMonsters.gif (401×257)

WanderingMonster2.gif (500×302)

Shortly after that, I decided that the direct left/right was also a little bit too static looking and I added a small (random) vertical incline/decline to their path making them a little bit better:

I believe since this I’ve slowed them down slightly, but has been much remained the same since.

Combat flow improvements

Over the past year, I’ve made several changes with the flow and how turns are used; some very strict while others were way to beneficial to either the player or the monsters.

For the first official release, I was using a “everyone gets a turn, then start over” design in which the players chose an action, their character immediately took that action then waited for their next turn. All the monsters would still need to take their turns also and if the players turn was ready before they finished, you had to sit around and wait for them to finish.

The wasn’t too bad overall, but at times you did find yourself wanting a bit more action in the flow. Recently I decided to revisit this mechanic and try to improve the flow of action a bit better.

I started off with allowing the player to no longer have to wait to attack once their turn is ready, instead they could attack right away (you still have to wait for your turn to be ready though). I then made the monsters a lot more lively by making them attack any time the player isn’t keeping them engaged (if all your characters are waiting on turns, the monsters will keep attacking until you return).

This one change made a huge improvement in the overall “feeling” of combat. There were times though that I felt you’d rolling over the enemies too quickly though, so I continued to look for additional solutions. After several variations I eventually found a nice balance between monsters and players that I’m happy with.

At this point, monsters still attack when the player isn’t keeping them busy, but I’ve been able to adjust turns in a way that they attack about 50% of the time of the player (two player attacks per monster). Should the player start to lose the battle though (deaths), the monsters become “over confident” and will slow down their attacks giving the player a chance to possibly win still.

This seems like a nice balance so far and will probably be the direction I keep going forward. In response to the changes though, the monsters had to be “beefed up” slightly since they don’t all get to attack like before. So although they will hit harder now, they hit less often.

Also, after further consideration, I decided to remove the dual combat styles and no longer support the “simultaneous” style and focus instead on the improving the newer system I’ve been working on (as above). I also don’t believe it was ever used much, if at all, since it was not the default style.

Memory / Performance Improvements

As with any long-term project, the desire to make it as robust as possible is always there. Throughout the entire year, I was always keeping an eye on memory usage and looking for places to make performance improvements. There were many minor changes, some that might not have even been overly beneficial, but were made anyway for future-proofing.

My recent venture into porting over for the iOS mobile device showed me several additional places where things could be improved. Here are the more recent changes I made:

  • Significantly reduced the number of sprite sheets used for spell/effect animations by using Spriter animating instead. This was something I wanted to do for a while, but kept putting off, I’m really glad I did it though because using the same Spriter engine for both characters and effects is a great benefit.
  • Unfortunately iOS devices required having loading screens for every map visit due to iPhone 5 memory limits. I may reconsider later no longer supporting iPhone 5 and remove/reduce the loading screen requirements.
  • Significantly reduced layers in several of the maps to improve loading times and memory usage.
  • Changed the spawn behaviour for monsters to allow for better management of memory.
  • Revisited loading screen mechanics several times to get the best performance from them.

Added in-game tutorials

One thing I’ve learned is that writing tutorials is hard and making them in-game is even harder!

I found myself setting out with a plan in mind, then quite often not being able to get the point across without a large “word dump” on the player. I went through many, many variations of the tutorials in game before settling with what I have now.

I did have a lot of help from a friend (Thanks again Tony!) who helped out with many of the steps and layout used in the tutorials and the overall “feel” of them. To be honest, I still find myself fiddling with them to try and improve them (not such a bad thing I guess).

Cosmetics, Polishing and User Interfaces

I’ve made a ton of changes this past year in all kinds of places adding in minor visual improvements, polishing etc. So many that I’ve long lost track of them!

One major difference this year was that I picked up several packs of icons/graphics that I’ve been using for items, spells etc throughout the entire game. I really like their style and they seem to fit well with the game overall.

A lot of interface changes were driven through player feedback during the Alpha/Beta stages prior to the first release and they were all very helpful. Many of the changes just came from my own imagination also over time and some were just added in because something was annoying me 🙂

Here’s some of my favourites from this past year (no particular order)

Screen shaking

A while back someone suggested to me that I should add in screen shaking during combat for special attacks to make them feel more “exciting”. Not only did I add it there, but I also added it to a couple places during mini-cut-scene’s also. I also wrote up a short article about how I did it using LibGDX in case you were interested.

Here’s a couple GIF’s showing off the screen shaking in two places:

CaveExplosionShake.gif (499×299)

Walking through small things on the map

This was added just for fun because I saw it being used in someone else’s game a while back.

When you go up to some small things on maps (such as flowers, plants etc). You can now “walk though” them and have the plant either be in front or behind you as you pass through.

It’s a subtle in the game and doesn’t add much value except for polishing, but I kind of like how it turned out:

Updated inventory

When visiting the vendor or looking in your inventory, previously you had no way to do a full comparison of the equipment piece your looking at against all the characters. I added a little window that allows you to see the benefits and losses a certain piece of equipment will have on all the members of the party. This should help everyone decide if they should purchase the item and who could make the best use of it.

Experience Window Improved

After some feedback from players, it was observed that most didn’t even realize that the window displayed post-combat showing their experience also allowed them to review what benefits a character gets should they level up on that last battle.

Previously you had to click on their “panel” that showed the character and it would open up a separate window with details, but it was never made obvious that this could be done; so many people missed it.

I updated that window to better show all characters in one place (no more scrolling needed) and also made it more obvious that you can now step into a separate window to review details on a level up of that character.

Here’s what the new experience window looks like:

javaw-2016-11-20-01-52-51-268

Added status messages

Previously when characters were under the effect of longer term spells such as confusion, slow etc their name in their console would switch in/out with that affliction until it goes away.

I added in a small icon beside their name/affliction to show it full time regardless of the rotation of name/affliction. I also added a small number over the icon to indicate how many turns (if applicable) that effect has remaining and then sort by that number from highest to lowest.

Due to space limitations though there will only ever be a maximum of 4 shown and any additional messages/icons will be displayed as the oldest are expired/removed.

Not all spells will end up in this list as some of them are designed to be “secret” and you’re just going to have to learn how they work 🙂

Added afflictions window

Shortly after adding in the status messages from above, I realized that it would be handy to be able to learn more details about those afflictions. I decided to add an “Afflictions” window to the main action menu allowing the player to review/read what is currently on that character:

Conclusion

When I first started writing about this past year I didn’t think I’d have a lot to say, but it seems there actually was a lot accomplished. There wasn’t as much technical problem solving this year, but instead mostly usability and polishing changes.

I’m looking forward to working through all the new chapters in the coming year along with anything new idea wise I might come up with.

Thanks for reading!

0

Our friends have names!

I’ve finally gotten around to giving our little friends the names and also came up with a short little biography for each one. These may change in the future, but for now I’m just happy I finally picked something!

Here’s our cast of friends in order that you’ll meet them:

Knight: Finley
Scottish for “Fair-haired hero”. Our main character in the game has no significant background and has pretty much spent his entire life aimlessly wandering around from tavern to tavern pretty much accomplishing nothing.
Amazon: Gerarda
Old English for “Brave Spear Woman”. Nobody is entirely sure where she came from. One day she just showed up in town for a competition and amazed everyone with her combat skills; she was immediately offered a job in guard duty and hasn’t left since. She dreams of big things in her life other than just being a simple guard grunt though and is always looking for something else to do instead. She doesn’t talk a lot, but when she does, you’d better listen!
Archer: Frezza
Italian for “arrow”. Fezza has spent many years learning the fine art of archery and has become quite good at her trade. She prefers to live among animals in the forest and isn’t a huge fan of large cities. There are only a few people she would call a true friend, but will do anything in her power to help them when in need.
Mage: Lilura
Basque for “Enchantment”. While very early in her development as a mage, Lilura is a quick study and really likes it when she can fine new shiny magical things to play with. She is good friends with Frezza going back many years and too prefers the more solitude life away from larger cities.
Bandit: Calvin
Latin for “Hairless” or “Bald”. Born with a full head of hair, which his parents were never able to keep control, he was named ironically after his bald great-great-uncle. He was raised to be a free spirit and always speaks his mind, even if it means peeving someone off. Unfortunately, due to unknown events, he was left with nothing but hit wits and attitude to carry him through life; resulting in his life as a bandit.
Dwarf: Gus
Gaelic for “Strength”. He’s Dwarf, enough said!?! Grumpy and very strong willed, Gus has spent most of his life focused on combat training, exploring caves and obtaining as much loot as he can. He’s not an overly great conversationalist, but tries his best when required. Gus isn’t a big fan of free-spirited people though, then tend to annoy him!

 

0

Updated targeting system

This week I revisited the targeting system to see if I could improve the behaviour of it since some testers found it to be a bit too “click needy” (too many clicks).

After various attempts, I decided to go with these steps needed:

  • Press down and hold while sliding over all desired targets to select.
  • Releasing when over any target will start the attack using all current selections.
  • Releasing when not over a target will clear the selections allowing you to start again.

This created a really nice/quick smooth flow to targeting that I think will work well on both desktop and mobile devices.

With these changes, the UI that previously had all the buttons on it was not longer required, so instead I added a small “Help” button in the top left of the screen for those who might need it.

Here’s a quick screen shot of the help screen:

And here’s a really quick video showing the basics:

Video Thumbnail
Updates to Combat Targeting
0

Spell Updates: Reflect & Bounce

Originally the two spells bounce and reflect were using the same animation which sometimes made things confusing. With that, neither of them had any indication that they were currently active either.

I’ve recently added in overhead icons for both these spells and although they are still using the same animation, each one was given a separate color so you can determine which one is which just by a visual check.

There were also several bugs that seemed to sneak their way in over time since the original creation of these two spells and I had to spend some time this week working them out. I believe I’ve since resolved all the problems though and have created a couple of GIF’s showing off their new visuals.

Reflect: Causes all spells cast upon the target to be reflected back upon the caster instead.

spell_reflect

Bounce: The counter-attack against Reflect. This allows you to “bounce” spells off an ally and bypass reflect above. A secondary result of this also allows you to bypass other “reactive” spells such as Shell on the targets also!

spell_bounce

0

Updated status messages

Previously when characters are under the effect of longer term spells such as confusion, slow etc their name in their console would switch in/out with that affliction until it goes away.

I’ve now added in a small icon beside their name/affliction to show it full time regardless of the rotation of name/affliction. I’ve also added a small number over the icon to indicate how many turns (if applicable) that effect has remaining and then sort by that number from highest to lowest.

Due to space limitations though there will only ever be a maximum of 4 shown and any additional messages/icons will be displayed as the oldest are expired/removed.

Not all spells will end up in this list as some of them are designed to be “secret” and you’re just going to have to learn how they work 🙂

statusmessages

0

Updated Inventory and Vendors

This past week I’ve been working on making some changes to the inventory and vendor windows to add some additional improvements to them. Below are some screen shots showing what’s been added and a little bit of detail on how each one can be used now.

Character Equipment

In the window where you assign equipment to a character, previously I had all equipment for that character along with what was also assigned to others (although grey’d out) all in one place.

I’ve now separated those two lists so you can still see what everyone else has assigned if you want, but in a second list reducing clutter while working with the current character.

javaw-2016-11-13-00-50-06-314

As before, clicking on any of the item slots will filter the list to display only the items related to that slot. The screen shot below is showing the result after clicking on the amulet slot , thus showing only amulets. Any item in green is already assigned to the current character while uncolored means it is available for slotting (unused)

javaw-2016-11-13-01-23-33-219

Main Inventory

Previously this window was used only for managing items in your inventory but I’ve since expanded it to display equipment and the new junk section. When working with either Items or Equipment you can click on the “Junk” button at the bottom of the description area and have that item/equipment moved into the junk bag. This allows you to reduce clutter in the main tabs for things you intend to sell later (see vendor later).

Items

The “Use Item” available on the Items tab works as it has before allowing you to use that item either on other characters (such as potions) or immediately (like map or beacon).

javaw-2016-11-13-00-49-13-306

Equipment

When on the equipment tab, you can also “quick equip” any piece listed there to a given character. This will automatically assign the selected equipment piece to the character and place the previous piece into the bag again making it available to others. There is no stat comparison in this area, to do more detailed work you should use the character equipment window shown above.

javaw-2016-11-13-00-49-33-663

javaw-2016-11-13-00-49-41-281

Junk

Once an item/equipment is placed into the junk bag, clicking on the Junk tab lets you review them and also restore them back to their original location should you decide to keep them. The Junk bag is stored with your game save and can be maintained across multiple play sessions.

javaw-2016-11-13-01-29-14-236

Vendor’s

The vendor’s have been given and small overhaul also adding in a more obvious buy/sell switch along with separate of items and equipment into their own lists to reduce clutter.

Buy

In the buy tab you also gain access to the “Buy Back” section. Any time you sell something (see sell below) that item/equipment will end up in this list allowing you to buy it back should it of been sold by accident.

Note: The buy back list lasts only as long as the current play session and is not stored with the game save at this time. It can be later, but for now I don’t feel it’s needed.

javaw-2016-11-13-00-50-29-564

javaw-2016-11-13-01-33-21-540

Sell

In the sell tab you’ll see the same separation between items and equipment along with the Junk tab. When visiting the Junk tab you are now able to sell anything there as wanted. When sold, these too will end up in the buy back section for retrieval should you change your mind or sell by accident.

javaw-2016-11-13-00-50-36-415

javaw-2016-11-13-11-02-07-976

0

Introductory cut-scene

This week I’ve wrapped up an initial version of the introductory cut that the player will see when first starting a new adventure. I don’t want to give away all the details, but here’s a couple GIF’s showing some of the events.

Getting caught cheating sucks:

tavern_throw

When trying to save someone doesn’t go as expected:

save_amazon

0

Java Game Distribution Options

This past week I decided to spend some time looking into options available for distribution of my game now that the time is drawing closer and closer every day.

Since my game is written in Java, technically it is “run on any environment with Java installed”. However, this typically isn’t always the case. Many environments may not have Java installed and expecting the players to install Java separately is generally annoying.

I wanted to make the player experience friendly but still be available on as many systems as possible. This lead me to search out various option and I’ve recently tried out 3 different tools to try and fill this requirement. I’m not going to go into huge details on each tool, but wanted to give my quick thoughts on each.

Launch4J
This is a fantastic option for those only looking to provide binaries for Windows systems. It is very full featured and easy to use. This checks the users system for Java being installed and if not, gives them the opportunity to install using one I suggest. It also has the option to include one with the package to be installed or used directly.

Packr
Brought to you by the folks who also created LibGDX, the library I use as the basis for my game. This also produces an environment specific binary but does so for Windows, Linux and Mac. This tool is specifically designed so that you also package a “stripped down” JVM along with the game avoiding the player needing to install one or ensure they have the correct version.

ExcelsiorJet
This is a commercial product, but certainly lives up to its own hype. This product allows you to compile a single binary that contains both an environment-specific JVM (their own) the JAR containing your own code/assets. They also provide extensive options for both compiling and distribution (installers etc).

Their price tag is a bit hefty for the average developer, but for larger companies I think they’re pretty reasonable. They do offer lots of options for smaller developer studio’s and even a free version (no Mac support though). They also offer free full licenses to those who release their product as non-commercial which you have to apply for. I applied, but as of this post I haven’t yet to hear back.

I’ve tested their application on both Windows and Linux. Windows was extremely easy to setup and gave me no issues. Their Linux installation was rather convoluted due to it being written still in 32-bit and I was trying to install on a 64-bit Linux environment. I can’t really blame them for this, but do hope they will release a 64-bit version to avoid complex installs. Once installed though, it worked perfectly without any issues.

Pro’s/Con’s
Launch4J and packr both leave your JAR containing your code external to the binary so it is not hidden from the players. This means you may still want to obfuscate you’re code using a tool like ProGuard to reduce snooping.

ExcelsiorJet’s design combines everything into a single executable thus hiding the JAR file from the player making it extremely difficult to obtain. This does, however, require you to have an environment to build upon for each OS supported because it compiles their custom JVM and native executable for that environment specifically. This is a great advantage for performance, but does add more complexity to the build/distribution cycle for a typical non-commercial Indie developer.

Packr comes with pre-compiled native binaries that allow you to execute the provided JVM and load your JAR file within it. This allows me to avoid having to build the native binary myself.

Including a JVM in all 3 cases does increase the download size of the game, however the ability to have a JVM included with it I believe is the better option to ensure compatibility and ease of use.

What did I decide on?
Since I’m just starting out and my game will be released for free, I’d like to avoid having too much complexity in my release processes.

ExcelsiorJet’s design is complex, but hugely advantageous to those who have the ability to use it to its full extent. Due to the price tag, st this point though I’ve decided to leave it on the side and may revisit later for a larger version of this game or future games. If they should provide me with the free license deal they offer, I will most likely return to this as my final solution.

Launch4J unfortunately only generates Windows binaries which left it out of the race early on. It looks like they’re heading toward providing options for other systems in the future though so I will continue watching for updates.

This leaves me with Packr, which I think overall is my best option going forward as it let’s me have the easiest access to building for all 3 environments without too much effort and I can build all of them from my one machine without the need to setup separate environments.

I still have to work out some details for Mac/iOS releases, but this has been a good step so far.

Thanks for reading!

0

New sound effects and combat animating

This week I decided to change how character combat animations are provided. Previously a single attack only had one type of animation assigned to it (ie: chop, thrust, slash etc). Now, when the character goes to attack, the game randomly chooses from a list of available animations to show. This allows a much better variation during combat.

This idea stemmed from our new sound effects that have started trickling in this week since each of them also provided variations of attacks and I wanted to be able to use as many as possible.

I actually like how it turned out so will likely update many more weapons to use this variation.

Video Thumbnail
New attack sound effects and animation combinations

 

0

Day/Night Cycle

I decided to add/try-out a day/night cycle in the game. It only affects the forest and town since the caves are indoors. The day/night state is also applied to the combat and is updated while you fight.

Below are a couple of screen shots of two versions of combat at night that I first started off with. The first one fades only the background leaving the characters at full light, while the second one darken both.

Here are the two for comparison:

combat_fading

After some consideration and feedback, I decided to try a mix between the two. What I’ve ended up with is darkening the background with a slightly higher reduction than the characters, but the characters are still darkened themselves a bit. This seems to be the best solution so far.

javaw 2016-08-14 09-53-20-514

0

Featured Post

Wrapping Up Year #2 !

Logo_800x600

This month marks my 2nd year of development of my 2D RPG. Wow, I can’t believe it’s been another year already!

Many things have changed this past year as development has been mostly focused on game-play components rather than the core engine itself.

The core engine work was mostly wrapped up last year, you can read more about it here if you wish. Since then only minor changes have been made to it; mostly minor bug fixes and changes needed to support new features introduce in the second year. I’m still very happy with how all that work ended up and it’s still very much the driving force behind everything done in the second year.

Oh and yes, I finally came up with a name! It wasn’t until last last couple months though, so I’m still very much a slacker. The name I decided to go with was “Mischieviots”. This is a fun play on words between mischievous and idiots; it pretty much wraps up the personality and behaviour of our little friends while they go on their wild adventures within their world.

So, what’s new this year? My, where do I start….

Let’s start off with a quick re-cap:

Biggest changes this year:

  • New character/monster artwork
  • New Music!
  • Cut Scene’s
  • Scroll crafting
  • Orb crafting
  • Loot chests
  • Vendors
  • Tons of new UI for character/game management.
  • Added profiles to allow multiple players on same devices and have their own “save space”.
  • Added “Save on server” option to allow for save files to be shared between devices.
  • Created a bunch of spells for fun and their animations.
  • Created one special attack for each player character to start off with.

Major time sinks:

  • New artwork animating
  • Spriter Engine Development
  • Decision Tree / Configuration Visual Designer
  • Character/Monster balancing

Future work:

  • Tons and tons of items, equipment, spells, special attack etc are all being planned.
  • Still focusing on finishing up the initial mini/tutorial adventure to provide full proof of concepts to obtain some initial feedback.
  • Create a user guide on the website for explanation of all the interfaces and how everything works.
    • I believe most of the features are self explained, or at least easy to figure out, but I want to make this guide just in case.

Character/Monster Artwork

I started this year off with purchasing a ton of character/monster artwork from an artist. It’s “stock art” so you’ve likely seen it before in other games, but I fell in love with the style and felt that they matched up with the idea behind the game (fun and goofy).

None of this artwork was animated though, so I had to teach myself how to do animating. It was a bit of a learning curve, but I believe I’ve gotten better over time.

I decided to use the software “Spriter” to do my animating as it seemed to best fit my needs at the time and still enjoy using it now. I did end up purchasing the pro version to support the developers and give myself the few extra features you get from the pro version.

The “character map” feature within Spriter also allows me to swap out their weapons visually within the game so we can see different weapons on each character. In the future I might support clothing and armor changes, but that would be a major change in the artwork.

I spent a lot of time focused on the 6 main characters giving them over 20 animations each for various combat sequences and weapon choices. I still have tons of other characters to animate for “NPC’s” later on, but for now I’ve only animated a few extra’s.

Since their original animating I’ve revisited them several times (and will continue to) making adjustments as I find things that don’t feel right etc. I certainly don’t consider them finished in any way and expected many more changes in the near future.

With our friends (mostly) wrapped up, I then turned my sights onto our monsters. When I purchased the packs I grabbed every single pack he had for monsters. This gave me over 70+ unique monsters to play with! I didn’t need to make nearly as many animations for the monsters so individually they didn’t take as long, but due to being so many of them, this was a huge (but fun) time sink.

I found that I struggled (and still do) with our four-legged friends; I’ve tried my best, but plan on revisiting them many more times I think.

I also tried giving each monster their own “personality” when doing various animations, but some of them probably need to be revisited later also.

I have a lot of animations on my site for both characters and monsters, some are more outdated than others, but hopefully you’ll enjoy them:

http://www.netprogs.com/gallery/gallery-animations/
http://www.netprogs.com/gallery/animations-2/

If I were to pick my favorites, these are probably on the top of my list:

Large Minotaur: Attack - Updated

Succubus: Cast

Thug 4: Tickle Stab

Demo_Goblin_Horse_Rider_Death

Spriter Animation Engine

Once I started making all kinds of new animations, I wanted to start seeing how they looked within the game itself.

I started off extracting the animations into old style sprite sheets and loading those. After a short while though I started to really feel the pinch of the limitations of this design choice as I started wanting to do all kinds of different animations with various minor changes. This would have required an ton of sprite sheets and just wasn’t working out well. I also found many of the “subtle” animation movements I made in Spriter were being entirely lost in the sprite sheets.

This then lead me down the path to look into directly loading Sprite animation data into the game and using that instead of sprite sheets. This not only gave me much smoother animations, but also significantly reduced the number of “repetitive” sprite sheets needed. Basically I now only need a single atlas for all their body parts and Spriter uses them as needed.

Spriter (at the time) didn’t have an official “API” for exporting their animation data into games. Instead, there were a bunch of personal projects on their forums that developers could use as they needed. I took the only one that was available for Java and started playing with it.

Initially things looked really great; until I tried loading it onto mobile devices! At that point the original code really started to show some major performance and memory usage problems. To be fair, it wasn’t developed with mobile devices in mind and I was pushing it way beyond it’s intended purpose.

I decided to dive deeper into the original code and start making modifications that significantly improved both performance and memory usage. The biggest change was that I hooked it directly into the LibGDX library which gained access to their performance/memory improved classes (arrays, maps etc). I then stripped out anything I didn’t specifically need for my game requirements to allow for further performance improvements. Unfortunately that pretty much ruined the library for being useful for anyone else, so I didn’t bother sharing back the changes I made.

When I first started I was barely getting 20 FPS (and worse on smaller devices). It always ran at full 60 FPS on desktops though. When finished, I was reaching a full 60 FPS during combat on larger devices and around 40-50 FPS on smaller one’s (being my 4+ year old Android 4.0.1 cell phone).

I was happy as a clam, until I started adding more and more animations to the main characters and noticed the load times at game startup were becoming a nightmare. After some investigation I found the problem was being caused by the loading/preparation of the Spriter XML data into data objects.

The biggest problem was in the XML code that was doing the loading. It was originally part of the API I had used above and at the time didn’t feel it was needed to be updated. Once this was discovered, I then decided to scrap it and use JSON instead since I was using it already for all configuration loading and had no performance problems there.

I also took it a step further and don’t actually load the Spriter data directly. Instead, I run an external “converter” program I wrote that takes the Spriter data, compiles it into all the objects need for “runtime”, then saves those out as JSON instead. Then, when the game starts, we only load the final objects into memory and run against those. This significantly improved load times and final data file sizes.

As a final step, I then created a multi-threaded loading screen that is used when the game first starts up. Instead of loading each character Spriter data one at a time, I now load them all at the same time each one on their own thread. I then wait on the loading screen until each one indicates they have finished. There is obviously some time lost due to the overlap, however it did significantly improve the overall loading time when first starting the game so I’ve kept it for now.

My desktop didn’t care much about what I was doing, but on the mobile devices I accomplished:

Larger Device
Original: 45 seconds
Now: 8-10 seconds

Smaller Device
Original: 2+ minutes (ugh)
Now: @45 seconds. Still not great, but it’s a 4 year old cell phone, so I let this one go.

I’ve continued to make minor improvements over time, but this code has been pretty solid and hasn’t needed a lot of attention since it was originally completed.

In this past year though, Spriter has spent a ton of time making an official API design that allows future-proof implementations to be written using other languages. At this time I don’t feel the need to rebuild my API against their new one; I’m not against the idea, I just don’t feel it’s required at this time.

During all this work, there were moments of frustration, but also moments when I burst out laughing. Here’s a small GIF of when things went horribly wrong during the API rebuilding:

head_blown_off

Performance / Memory – Continual Effort

The small/old devices introduced all kinds of new problems over time as I continued to add new features and content to the game.

The severe memory limitations (36 MB) makes me have to be extremely careful in how I load and use data. Most people don’t think much about memory management when it comes to Java, but if you do things carefully you can really push it to fun limits.

Right now I can run the entire 45 minutes of the game and the GC pretty much only kicks it at the times I actually tell it to (I force it during load screens). The testing I’ve done has shown very little activity when it does kick in and there doesn’t seem to be any performance loss when it does. I will continue to monitor of course as the game expands further.

This means I can run the game locked at 36MB and haven’t run into any memory/performance problems as long as I continue to be careful about how large the maps are I load or what I choose to keep in memory verses loading at run time.

My very old cell phone I used for testing has introduced some unique issues of it’s own. Due to being such an old device it tends to show all the potential performance issues right away. This has allowed me to make changes as needed to best support it. It’s not perfect by any means, but to be honest, anyone playing a game on a 4 year old cell phone can’t really expect the best performance.

In my defense though, I can’t even use google chrome on the phone to any useful extent, and that came pre-installed with the phone!

Crafting – Scrolls and Orbs

I wanted to introduce some features that would allow the player to be able to customize their characters as they play them.

I decided to go with two crafting options:

Orbs

Crafting_Demo2

  • These allow the player to improve their character through special effects, spell boosts and statistic boosts.
  • Orbs can be both looted (pre generated) or you can craft them using our simple crafting system.
  • Right now the only requirement is to gain “residuum” from killing monsters. Use convert this residuum into orbs.
  • The list of available orbs will be provided to you along with a “sneak peek” several levels ahead in case you want to save up for something else.

Scrolls

Scroll Alchemy Window

  • Scrolls allow you to customize what additional spells each character can have.
  • Each character will be given a specific number of open slots to place these scrolls onto.
  • Once placed, the character can then cast that spell any time they have enough MP to do so.
  • At any time you can swap these scrolls out for other one’s.

There are two ways to obtain scrolls:

  • Randomly Looted
    • These are pre-generated and placed randomly into chests by the game.
  • Caster crafted
    • Any spell that is 5 levels or more lower than the caster, they can choose to craft a scroll of that spell and share it with their friends.
    • This allows you to use a certain spell more often. You just have to wait a bit to do it.

I’m also considering allowing some lower level scrolls to be purchased from vendors in the game later on as you reach higher levels. Likely these would be more the “buff” types rather than damage.

Make a mistake? No problem! Tried to test something out and hated it? No problem!

All crafting is setup so that there is no “risk”. At any time you wish to no longer have the previous crafted item, you can deconstruct it back into the original residuum that was used to create it.

You can read additional details on Scroll & Orb crafting here:

http://www.netprogs.com/category/previews/page/2/
http://www.netprogs.com/customizing-characters-orbs/

UI Changes/Improvements and Additions

So many things have changed in the UI over this past year so I’m going to try and recap on the most major one’s instead of trying to remember each little change.

Character/Map Lighting
Earlier in the year I worked a bit with shading/lighting and created some initial shaders that allow me to control lighting within a map.

Here’s a quick GIF showing what I did back then. I’ll more than likely add much more to this as we expand onto more maps etc.

Lighting3

Interface graphic’s update
I started to notice that the original interface graphics were not scaling all that well on larger desktop screen’s or higher resolution devices. I decided to keep the main look & feel, but entirely rebuilt the artwork that drove the interfaces.

If you want to see the full article, you can read more about it here:
http://www.netprogs.com/category/screenshots/page/3/

Here’s a couple screen shots of before/after of the combat screens:

(before)combat_console_before

(after)combat_console_full_screen

Mini Map’s
I decided recently that I wanted to be able to provide the player with a map to help them navigate their way around towns and larger adventure maps.

I went with the “expose only when explored” design by starting the player off with a black map and expose only the area’s they’ve visited. The exposure amount of the map is saved with their game so upon return they will pick up where they left off. Towns however are fully exposed from the start (but I can change later on a per town basis if I want).

Here’s a quick peek at what it looks like now: (ignore the fact that I’m in town!)

Mini-Map

Cut Scene’s
I also did some initial design/code to support cut scene’s. These are entirely driven through the decision tree engine that drives a lot of the game.

It’s probably best to just show you the video of the little scene I made:

Video Thumbnail
Mini Cut-Scene

You can also read a little bit more about it here:
http://www.netprogs.com/introducing-cut-scenes/

Chests & Looting
Eventually a player will want to get stuff so I decided the time had come for me to introduce random loot and vendors.

Chests will be made available on any given map with pre-generated loot. What is provided in each chest is driven through decision tree’s also allowing us to do all kinds of various checks before providing the loot. This means we can be as mean or as nice as we want when it comes time to generating loot for any given chest!

Chest Looting: Conversation

Vendors
Vendors, like most RPG’s, are just little stores kicking around the world where the player can buy various items. Our vendors are also driven through the decision tree’s allowing the vendor to do “checks” on the player possibly give them great deals (or perhaps even worse one’s) depending on the current state of the game.

This screen shot is a bit outdated, but still pretty much shows the vendor on a small screen device:

vendor_dialog

Load/Save game
I created the main menu (finally) providing the user access to load/save game, options and profiles (see below). I also added a “save server” to allow you to save several files onto our server and let you load them back onto any other device.

The screen shots are a bit outdated, but you can read more on the save/load screen’s here:
http://www.netprogs.com/category/screenshots/page/8/

Profiles
Each profile gets their own settings and save files. You can swap between them pretty quickly from the main menu also. This allows multiple players on the same device without causing confusion/collisions of their game saves.

You can read more about these here:
http://www.netprogs.com/category/screenshots/page/5/

Combat Specific Changes

I spent a majority of development time in the combat making sure everything works, moves and behaves as I expected them to under all kinds of various conditions. It’s still a work in progress, but has been turning out quite nicely.

I decided to move away from the “overlay” combat design I had originally to making it a full screen. This not only worked best for smaller screen devices, but also allowed me to have more room for larger combat sequence animations.

Here’s some little tidbit’s about the combat now:

  • Characters will yell at each other when kills are stolen from them.
  • Improved combat targeting UI (read more here)
  • Expanded UI to allow for selection of characters to revive.
  • Two specific styles of combat are available to the player:
    • Strict Turn Based (everyone waits their own turn)
    • Active Turn Based (turns are overlapped creating a more active player interaction)
  • Random battle algorithm was introduced to let us best control the spawns as desired.

Some little combat GIF’s I made over the past year:

Shocking Experience Skeletons Orcs

You can also watch some video’s from this last year showing you see how things have evolved:

Apr 23, 2016: Combat Demo

Jan 25, 2016: Combat Demo

Nov 15, 2015: Combat Demo

June 6, 2015: Combat Demo

Decision Tree’s and the Designer Tool

So far you’ve heard me mention decision tree’s and have probably gathered they are an important driving part behind the game.

Early on I wanted to be able to allow the game to be “aware” of what’s going on and allow all kinds of various checks on the current state of the game. By using decision tree’s (with heavily customized logic nodes) in almost every single major portion of the game, I am able to control almost anything I want based on the current state.

At any time there are probably 4-5 tree’s being checked when not in combat, and while in combat each character and monster have their own driving their “AI” allowing us to customize each one to have their own “personality” should we choose.

With all these decision tree’s kicking around, it became obvious that managing all these configurations could potentially become tedious, or worse, a nightmare. I decided it would probably be a good use of time to develop a tool to help manage and visually design all these tree’s.

Over the period of 6 weeks I created a very rough designer tool that allows all kinds of various adjustments etc to the tree’s with much less effort than before. It certainly isn’t perfect and I can still crash it quite often, but it is more than stable enough to be a significant time saver.

Here’s a quick peek at what the designer looks like. Very function over fashion that’s for sure!

CurrentDesigner

Character/Creature/Combat Balancing

Yep, the dreaded balancing issue all RPG’s have to have at some point.

I’ve taken into consideration all equipment, spells stats etc and have created a massive set of “base” spread sheets that I believe will allow me to create new monsters, equipment and spells without breaking down the balance too far.

As we all know nothing is perfect, nor should it be, so everything is based around the concept of “close enough” allowing for players to have slightly different experiences each time they play.

These spread sheets should at least let me notice when something is horribly out of balance before it gets implemented. Of course, there’s nothing like actual game play for proper testing, so there is tons of that going on also. So far everything does seem to match up against the spread sheet theories, so that’s a good sign!

Added Music

Last, but certainly not least, I’ve hired Chris Wickham to start working on some compositions for Mischieviots. He’s done a fantastic job capturing the spirit of the game and has made some great pieces for each of the maps of the mini adventure I’m making.

If you want to listen to the entire current set, you can visit the SoundCloud play list here:

Conclusion

Wow, this article turn out even longer than the one from my first year. Hopefully it wasn’t too boring of a read and you got to learn some new things about Mischeiviots.

As you can tell, being a solo developer, this project is taking a lot of time to get completed. I’ve still been enjoying the experiences and will continue to work on and improve the game going forward.

I’m still planning on releasing it into the wild as an entirely free game since it’s just a hobby game and can’t really compete with all the amazing other games out there. Unfortunately I still can’t give a date when something will be available for testing, but I am certainly getting very close.

If you are interested in the upcoming alpha testing, let me know and I will get in contact with you when the time gets closer.

Thanks everyone for reading!

0

Planting Flowers

I spent far too many hours today trying to work out some massive drawing issues with the new artwork I wanted to use for the maps. After driving myself entirely nuts, things finally started coming together and I was able to make it all work on all my devices!

So, as a treat to myself, I decided I’d plant some flowers 🙂

Planting Flowers

0

New Spell: Sacrificial Lamb

Another new spell ! This one fits into the “Do really bad things” category 🙂

  • Sacrificial Lamb: Choose a single ally and kill them instantly, then stealing their HP and MP and giving it to yourself !
Video Thumbnail
Do really bad things...
0

New Spells: Bounce and Reflect

Hi everyone,

Just wanting to share off a little video showing off these two new spells !

  • Reflect: Once cast upon yourself or an ally, any additional spells cast upon them will be reverted back to the attacker !
  • Bounce: Causes all spells cast by the party during the duration of this spell to bounce all your spells off an ally and onto your enemy instead !
Video Thumbnail
Introducing new spells !
0

Introducing Cut-Scene’s !

So this past week I decided to finally connect up all the little pieces I had been making that could support a cut-scene and combine them into a single configurable location.

This little video is a quick demonstration of the majority of features currently possible in cut-scene’s:

  • JSON driven like the rest of the game; requiring no knowledge of the code itself.
  • Story window display
  • Camera scroll/pan over any map using pre-defined path
  • Adding/Moving characters on the map
  • Placing “bubble” text above character head
  • Adding/Manipulating light sources
  • Add/Remove/Swap of specific layers
  • Use of sound (and music, although not in this demo)
  • Opening and display of conversations using main window.
  • Placement of sprite animations (firewall)
  • Screen fading

If you’re interested in what the JSON code looks like, you can check it out here:

http://pastebin.com/pQaxnWNr

And finally, here’s the video itself. Enjoy !

Video Thumbnail
Mini Cut-Scene

 

0

Finished my first real map !

Wow, that was more time consuming that I even remotely considered.

I generated a layout map using the tool I wrote yesterday to create an image as the base, then I opened it up in Tiled and started the process of hand creating all the details of the map.

I haven’t tried loading it into the game yet, but that is next on the list !

Here is the generated map:

Generated_Forest

And here is my hand crafted version using the above as a template:

HandMade_Forest_Resized

0

Map Generator

As a quick side track I started looking at some map/tile generation using the Perlin Noise algorithm.

I ended up creating a quick map generator program that gives me a quick visual concept of a tile map design. Basically the plan is that I’d save out the image then load it into Tiled as a background layer then use the proper images there to create a nice looking map.

I could probably spend a whole lot more time on this and get it to the point where there would be far less manual use in Tiled, but since this was just a side track I’ll leave it where it is for now. If I find I really like it and want to spend more time on it, I can certainly revisit it.

For now, here’s a quick screen shot of what the results looks like:

MapGenerator

0

Hmm, I think my little animals might be a bit too big

I’ve been working through adding the remainder of my current animations to the game and upon loading up the “little” animals, they seem to be more on the gigantic side instead 🙂

Oversized Little Animal

0

Wow, I have so much to learn !

Spent all morning playing with our new art and Spriter….

And I got one walking animation direction working for one sprite in 6 hours.

I think I might need to learn how to speed this process up 🙂

Here’s an animated GIF of the sprite!

First Animated Sprite

0

Featured Post

First year of development under my belt. More to come!

New Monsters!

This month marks the first year anniversary of development for my desktop/mobile 2D RPG game.

At this point it isn’t as much of a “game” right now as it is a game engine of which I intend to build the game upon in the very near future now that it is reaching a stable state.

This article is about my trials and tribulations of developing the engine over this past year, what I’ve learned and what I wish I had learned better before starting on it.

TLDR; (since this is a rather long article)

Things I think I’ve done well so far:

  • Memory management.
  • Final version of effects engine seems solid now.
  • Final version of visual sequencing seems solid now.
  • Entire engine has kept to the “configure everything” design we first aimed for allowing us to start building an actual game from the engine.
  • Unit testing. I’ve gone hog wild here. Almost 200 unit tests covering over 80% of the core library when executed. Although as time has gone on, I’ve been slacking on adding new tests for newer code, so this number has been dropping sadly. These tests are run constantly whenever changes are made to the core library to ensure nothing has been broken (and I do break things!)
  • The core decision tree engine used for maps, monsters, character etc (any AI really) worked quite well right from the start and has only required minor tweaks from time to time as I continue to expand on it’s requirements.

Major time sinks:

  • Core/Effects engine design and implementation took far longer than desired due to having to revisit the entire design on several occasions.
  • Visual on-screen sprite sequencing required several rewrites as I learned more about how to manipulate sprites better.
  • Android screen sizes. This one although not a lot of time lost, was a major pain!
  • Character pathing. I find myself still wanting to improve on this area. I might need to revisit it entirely at some point later on.

Future work:

  • New artwork and animations are on the immediate schedule.
  • Continued expansion of the AI and character/monster balancing (current work now)
  • The game itself ! Yep, the time is coming close and I’ll start producing images and video’s of game play from the game itself instead of just functional demonstrations.

History

As with many personal projects, this game started off as a “Hey, let’s start a new project together” with my brother (my twin!). We’ve always worked together on projects over the years but this one was going to be our first game.

We started off with the concept that we weren’t entirely sure what the “story” would be just yet, but we knew what style we were going to aim for (classic 2D turn based RPG).

So, how does one write a game without actually knowing what the game will be? Good question.

One major thing we decided early on would be that we’d try to keep everything as generic as possible. Design everything with the intention that we’d want to be able to configure it later for actual usage and not require a significant amount of code changes once that process starts.

By building the game engine entirely with the purpose of being reusable in any form was going to allow us to wait until later to actually decide what the “content” of the game would be.

In the beginning the plan was that we’d both be working on the major components together, but as life has it, he and his wife decided to start an entirely new chapter in their lives: sell old home, get new jobs, move to new city 600 miles away, rent place until new place is ready, move into new home, start major renovations and end up with a nightmare of a contractor. Needless to say, he’s been very busy this last year!

So, off I continued with the work 99% by myself. The plan was that I’d work on the core engine parts and he’d chip in with “idea’s and feedback” as much as he could. This has continued to work quite well for us in his absence.

And before you ask, nope, still no story and still no name…we’ll get to doing that, I promise !

Tools & Libraries:

I’ve been in software development for over 15 years covering many different languages over that time. Although I must admit, as my time at work has been chewing on my heals, my free time available to learn new technologies has been rather limited. With that in mind, I decided to work with a language I’m fully skilled in: Java.

Once I decided I wanted to work in Java, I then looked around for various graphics engines that could be used. This lead me down the path toward LibGDX, which has been a great library for my uses allowing me to develop for both Android and desktop using the same code. I’ve also left the door open for compiling onto iOS later on once I get access to a machine that I can do so with.

Tools/libraries I’ve been using up until now:
  • Java
  • ADT (older Android eclipse, not sure I like the new Android Studio, but that’s a different topic)
  • LibGDX
  • GSON
  • Tiled
  • Spriter
  • GIMP

Time sinks:

Oh where to start. One thing I can say for a fact is that I seriously underestimated the amount of effort some of these major components would actually take. I am glad that I was not on any schedule or deadline as I believe I would have long missed it. Lot’s of reading online of articles on all kinds of various game designs etc, it has been quite a learning experience that is for sure.

I’m going to cover some of the major time sinks I ran into over the last year:

Core/Effects Engine

I’ve probably lost the majority of time in the area of the effects/abilities engine that controls almost everything. This engine is the basis behind how combatants interact with each other and everything else. Everything from spells, weapons, character stats etc are covered by the same “effect” design.

Originally the concept of being able to use these effects was very basic. An effect is applied to a character, that character can then apply effects onto another (weapon attack and damage). Then we introduced such things as reactions (react to an effect being applied), triggers (invoke an effect through means other than directly), delays, recurring, duration, catalysts (apply an effect, but have the person it was applied to cause it to trigger by doing something else) and a whole slew of variations based upon available targets (myself, my ally, my enemy; scopes (all, group, single) and many combinations thereof.

This resulted in many, many, many rewrites of the core code. Far more hours lost there than I would ever like to admit. Although over time it has become an extremely robust system to use and all fully configurable allowing extensive and almost unlimited options.

Sprites, animations and general on-screen pain

Another massive time sink happened once I started working on the visualization of the effect instructions onto the screen using sprites. Up until this point all my “mechanics” were only being tested using unit tests and visually reading through the logs to verify the results.

Once I started creating the “sequence engine” to read the instructions from the effects engine things started to really become complicated. I ended up spending a lot of time working out the finer details between timing of sprites for displays, damage numbers, animated effects (lightning bolts etc) and being able to keep all actions properly displaying in the correct order (attack->reaction->counter->run away kind of thing).

Combine that with the fact that I also wanted to be able to control visually how these were presented on the screen. Some instructions were to be simultaneous, while others required to be sequential. This resulted in an interesting design of the sequence engine that now allows me to create any one of these combinations and simply “plug it in” to the rest of the sequences without too much additional work.

The sequence engine continued to grow but also required several full rewrites until I finally came up with the design that allowed future expansions on it without having to rewrite over and over any time something new is needed to be added.

Many nights of sleep were given up for trying to work out some of the major issues at the time, which funny enough, most of that work got scrapped during the final rewrite phases; go figure.

Path generating

Creating the code for my path building has been fun, although I believe I may need to revisit it a few more times before I stick a fork in it. Right now it is a variation of the typical A* design but with some minor differences that (at the time) I felt was needed. It works great for the most part, but still from time to time sends my little guys onto some very odd paths (although they do get to where I want them). So for now, I’m accepting it, but will come back to it later during polishing stages.

Android Screen Sizes

Handling multiple Android screen sizes started off as a nightmare. Although I didn’t lose much sleep over this one, I did end up having to revisit it many times over the last few months. I realized near the end the entire problem I kept running into was actually caused by my misunderstanding how to properly use libGDX’s viewports. Despite reading the documentation over and over again, I was still using them incorrectly. Once I made that realization, things came together quickly. Hard lesson learned there, and I believe I have the issue fully resolved, but future testing on more “real” mobile devices will tell for sure.

Memory Management

Memory management has always been very high on my list of things to try and keep an eye on. Any time I finish up any major code changes I run the application through a series of memory usage tests monitoring it for any spikes and significant memory allocations and making improvements to the code as required. Despite the amount of time spent here, I believe it has been time well spent.

Being a perfectionist

I find myself constantly wanting to “improve” sections of the code as I work on additional parts. This can be healthy in development; or so I try to convince myself. I find there are times I spend a lot of hours on something only to realize I really didn’t improve things much, just changed how they “worked”. Overall though, despite being a time sink, I believe most of it has been a worth while effort.

Going into the future

Artwork

Right now the majority of the artwork I’m using has come from www.opengameart.org (big thanks to everyone there).

I will be purchasing some stock art here shortly and will be spending a significant amount  of time on creating animations using that art. I’m not an artist, and can’t even “fake it”, but I have worked with Spriter and really enjoy working on animating existing artwork.

I’m looking forward to making all kinds of custom animations since my engine can allow me to do almost anything I want. Stay tuned, in the coming months I’ll be posting  about all kinds of new animations I hope.

Artificial Intelligence

Although the AI engine was written many months ago (and wasn’t a time sink !), I’m planning on continuing to expand on it in the coming months as I design more robust and interesting monsters. Right now the engine does allow for a large amount of customization and “personality” development so I’m looking forward to seeing how much I can push out of it.

The game itself !

Yep, the time is coming. I’ve been putting this one off because I’ve been hoping to pull my brother back into the flow for this part. He’s always been more of a “game play” person that I have since he’s been designing non-video games (card/board/strategy etc) for fun for many years and has a lot of great idea’s for content and story line.

A few months ago I did write a short article about a larger vision on how the game might work. At this point I believe this is still, for the most part, the goal in mind:

http://www.netprogs.com/category/dreams-visions/

 

Demo Video’s

Over the last few months I’ve been producing small mechanical demonstration video’s. Today I’ve made a small “Adventure” showing off some of the key parts of the game engine.

If you wish to dive into more of the mechanical video’s, here are some you might find interesting:

http://www.netprogs.com/enhance-effect-animations/

http://www.netprogs.com/effect-enhancements-speed-control/

http://www.netprogs.com/party-changing/

http://www.netprogs.com/running-away-from-combat/

http://www.netprogs.com/optional-combat-styles/

And without further ado, here is the adventure video !

Video Thumbnail
Short Game Play Demo

Conclusion

Well, this article has ended up being far longer than I had expected. I guess there is a lot to say to cover an entire year worth of development. Hopefully it hasn’t been too dry and you actually made it to the end.

Overall, this project has been a great learning experience and loads of fun. I wouldn’t have traded all those hours for anything else as I believe the knowledge gained will stay with me and has improved my skills in development as a whole. (and kept my mind from rotting from the repetitive assignment I get from work!)

Thanks for reading everyone and feel free to write and ask any questions.

 

0