Mischieviots: Year #2 of development wrapped up! news

Mischieviots: Year #2 of development wrapped up!

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:

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

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:

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

• 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

• 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:

Scroll Crafting Blog Post
Orb Crafting Blog Post

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.

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.

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

(before)

(after)

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

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. You can also read a little bit more about it here.

Here's a short cut scene I made to test out the majority of the features available for them:

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!

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:

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.

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.

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:

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

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!

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!

Want More?

If you're interested in reading more about Mischieviots, or catching up on older posts, feel free to visit us at: