Archive | April 2014

Last Pre-release Update

First of all, sorry the posts have been infrequent lately, I’ve been bogged down with work. I’ve had a recent revelation that my latest project is due this week (in two days) rather than next week, which gives me a lot less time to work with than I’d hoped. I should be okay since my game had been going quite well up until now, but I still have several things left to do (hopefully today). These are:

Giving my second monster a turn.

At present, the player party fights against two trolls. Unfortunately (or fortunately), only one of these can actually act at the moment. While this is fantastic news for our characters, it’s not so great for me. This shouldn’t be very hard or time consuming to do, but it’s key, so I’m planning to do it next.


The finished game will hopefully be much more interesting to look at.

AI – Decision Making

At present, the enemy randomly chooses a player to attack. Part of our brief mentions that enemies must have some form of decision making when it comes to choosing how to attack. I’m not entirely sure how to go about doing this, but I’m hoping I work something out soon. I may have it so that the enemies prioritise characters with low HP, but are otherwise random. Another possibility may be adding a ‘taunt’ move to a character that makes the enemies more likely to target him (or both).


The next thing I’m missing is an ability that can affect multiple targets. For this, I plan to give the main character a skill that heals the entire party. This should be short and painless to implement (hopefully).

Implementing the Morale System

The next thing I get to do today is to implement my Morale System. This is half-way implemented already – every time a character makes an action, they lose 1 MP (morale point). What I have to do now is have it so that when a character is at 0 morale, the player no longer decides on their actions and instead that character will continue to attack mindlessly until they’re dead or the battle is over. This is something that else that shouldn’t be too difficult to do, but it may be more time consuming than I’m expecting.

Attacks must have a chance to miss

This is fairly painless, but I haven’t gotten around to it yet. Basically all attacks (from both players and enemies) must have a chance to miss their target. For this I plan to simulate a dice roll (get a random number from 1 to 6) and if it’s above 2, have the attack land – otherwise, it misses. This isn’t a particularly clever or advanced system, but it meets the brief and should be fine. I can also customise this to be different for each character and thus making some more accurate than others, but the plan is to leave it all at the same level.

Implement the gold system

A major part of my game is the gold system, which is currently completely missing from the game. Despite that, it’s actually super easy to throw together. When the player wins a fight, they should earn gold – this gold is used to upgrade the town and increase the strength of their party. This is something that won’t take long at all to implement (but on top of everything else, I’m going to be very busy today).

Fix GUI Resolution Issues

Another short but probably not sweet issue I have to fix is the GUI. Currently the main menu and town scenes have some errors when playing the game in different resolutions, because the script hasn’t been written to accommodate them. This isn’t a huge issue and I know exactly what to do to fix it, but it will take some time. So maybe it’s more sweet than short after all?

Pretty up the battle environment

As you can see from the screenshot above, the battle scene currently looks – for lack of a better term – like ass. I’ll have to throw some assets in and make it look a bit prettier, without clogging up the scene too much with pointless objects.

Clean and comment my scripts

Lastly, I’ll have to clean up my project a bit. This stuff won’t be visible inside the game, but it’s important as far as how I’m assessed. The assets in my project need to be organised a little better and I need to go through my scripts to make sure my commenting and formatting are okay. This won’t take too long either, hopefully. I’ll also have to write a post-mortem, come to think of it.

That’s it, folks! I’m pretty swamped today, but if I don’t get this project finished before I go to sleep I won’t have time to finish all my other work before it’s due. Because of that though, there’s every chance I’ll be uploading the final build of my latest game as well as the post-mortem to my blog tomorrow some time (not tonight, because as soon as I’m done, I’m going to sleep).


Feature Update: Village Upgrading

In my upcoming game, players will be able to upgrade their home village in certain ways, at the cost of gold. These upgrades will buff the player’s party in combat in different ways, as well as allowing them to explore new areas of the town.

The town will start in a very bare-bones state, with nothing but walls and a road:

Screenie Town

From here, the player can talk to a certain character in the village to purchase upgrades. These upgrades will be given out in a linear order – currently, there are no plans to allow the  player to customise their village, just to improve it.

Town Screenie 2


Here’s a visual outline of the village progression, but remember it will play out a lot slower than this:

Town Screenie 3


Town Screenie 4


Town screenie 5

Keep in mind, this is still very early and everything is subject to change. Upgrading the village is definitely planned and is already functional, so I very much doubt it will be removed, but you never know what to expect. This hasn’t been very well polished yet, either, so certain things will look different in the final game.


If you have any questions or comments, you can reply to this post, or get in touch with me through the ‘About’ page.


Small Update

I’m back on track, and the village has been rebuilt more-or-less the same. There seem to be a few differences, but nothing that makes it any worse from the original.


I’m planning to change the area outside the castle to something more interesting, but equally resource ‘unintensive’ (I’m open to suggestions).

The camera’s been reworked nicely – it now functions almost completely how I want it to. Currently, it rotates nicely around your character and won’t clip behind other objects. Instead, it smoothly moves to where ever the nearest solid point is between where the camera should be and where the camera actually is. The only thing I have left to do is put a clamp on how high and low the camera can be pointed – this isn’t a big task, it’s just one I haven’t gotten around to yet.

Otherwise, animations and movement have been tweaked slightly. They work in pretty much the same way as ever, but now look and feel a tiny bit better. I honestly shouldn’t be worrying about stuff like this at such an early stage, but having to rebuild my first level gave me an opportunity to play around with these kinds of things anyway.

My next big goal is to get a nice GUI happening, if I can ever wrap my head around the free version of NGUI. I’ve always had trouble with making decent GUIs in the past, so I’d like to get it right this time. I’ll post a screenshot of it as soon it’s made. From there, I’ll move on to the battle system, or “the actual brief”.

Will keep you posted.

First problem (of many to come)

In game design, like in all design, the designers come across design problems (design). Today, I thought I’d be extra productive, so I built an upgrade system for the base to test, film and upload to the blog for all to see. Unfortunately, after building my game, it decided to delete everything I’d made so far, except for my scripts.


The first build was merely a setback!

This isn’t as disastrous as it sounds, but it has set me back a few hours at least. Luckily, since my scripts are safe and snug inside the asset folder, I can reassemble everything the way it was (more or less) and get it functional again. It’s also taught me an important lesson I learn every time this sort of  happens – I need to back up my work a lot more frequently. At the moment, I tend to back it up never, which might not be often enough.

Captain Plan-It

So, with my last (unenjoyable) project out of the way, I’m free to work on my next one – which has already been a lot more fun and exciting, and I’ve only been working on it for about an hour.

My newest game is a 3D turn-based RPG, also made in Unity. It’s a bit daunting – I’ve never tried to make a turn-based game before and I’m not even sure where to start. So, I started where I always try to start – by making it look awesome.


I ended up giving in and spending a fair bit of monies on assets for this project, which I justified by telling myself I’ll use them in the future (which I hopefully will).

The game is about a young anime stereotype adventuring with an older and a younger stereotype as they do missions and make some money, which they use to upgrade their base. This means that the above base will look less interesting at first, but the player will slowly build it up with acquired gold. While this sounds neat and complex, it’s going to be boiled down to a pretty simple system. The player will be able to buy upgrades for their base, but it’ll just be a single upgrade button at a time – the player won’t have any choice in what to buy or where to place it.


The player can choose to go on missions, which will have randomly generated enemies to battle. I’m not 100% on how the system will work yet – I’m thinking that there will be three types of mission to choose from; easy, medium and hard. The enemies in the missions will be in a set level range for the player to attempt. For example, easy missions may have enemies from levels 1 – 10, whereas medium missions will have enemies from 10 – 20, and so on. Because this is really just a prototype (I have a 4 week time limit), levelling will be quite quick and easy.

These missions will award the player with gold and experience – the gold is used to upgrade their base, and experience is used to level up and become stronger. There will be no gear system, because that’s well beyond the scope of the project at the moment. Upgrading the base will reward the player will a higher ‘Morale’ stat. Morale is a resource that will be critical to combat in the game – each turn, every character’s morale will reduce by 1 point, until it reaches 0. At 0, the player will lose control of the character that’s ‘panicking’.


I went with this idea because I wanted some kind of gameplay dilemma a bit outside the norm of a regular RPG, as well as some kind of substantial reward for upgrading the base. I’ve also never enjoyed RPGs that reward the player for drawing out combat and playing defensively – I always felt that turn-based RPGs are slow enough as it is. I’m not sure how this system will pan out, but I’m looking forward to seeing how it goes.

There will be three playable characters in this game. The main character is that white haired, blue-coated guy wielding an impossibly enormous sword in the above screenshots. Another is the older man seen in the second screenshot, who will also serve as the mission menu and mentor. The third playable character is a bit younger than the other two, but I don’t have a screenshot of them yet.

As far as story goes, I have a rough idea of what I want to do, but nothing’s set in stone. Again, it has to be fairly light-weight to meet the time limit.

I also plan to be a lot more dedicated to the blog with this projects, with updates at least twice a week. The exception is this week – I have two other major assignments due quite soon, so they’re currently the priority. I’m going to be uploading more screenshots, as well as hopefully some gameplay demos and videos on this blog. Image

This is all just a plan at the moment and the only functional part of my game is the town (which you can explore in third person). I’m a lot more excited for this project, though, and after this week I’ll have more time to dedicate to development than I did with my last two games, so it should turn out a lot better. Hopefully, I’ll be able to keep you updated this time.