Developing with Unity (Pt. 9)

The problem with choosing how to develop the next features is choosing how to develop the next features.

While there has been a drought unequalled regarding the development of any of my projects in Unity that doesn’t mean there aren’t things you haven’t already seen. Such as the early development screenshots from the transition to Unity 5. As I’m sure I said previously, the transition wasn’t that bad as it was mostly on the editor side of things that everything went a bit awry. The code, which was the bulk of the project, was pretty much functional from the moment the new version loaded.

That said, there hasn’t been that many developments since then for a good few reasons.

The recently updated Adventurer's Camp.

The recently updated Adventurer’s Camp.

One of which is that I’m still questioning how I want to approach the development. Such as- do I keep the party or have it a one person thing? Many of the newer RPGs don’t feature parties and those that do are usually, in the case of Dragon Age: Inquisition, or Final Fantasy XIII, heavily reliant on tactical AI to get the others to do anything. As in, the days of things like Final Fantasy VI where you had a four person party that you could control each turn are long gone. Mostly. But it’s something I like- so I’d love to do it if I could.

The next set of issues lies with the skills. I don’t know how I want to do those- skill tree or no? Multiple levels or no? Upgrades or no? Who knows? I don’t! If I did I wouldn’t be having these many problems. But, the skills are also a big and expansive part of the project so they take a good long while to update/change around. Which is a lot of time wasted if done in error.

The information screen (where you can learn about the game world).

The information screen (where you can learn about the game world).

The character screen (complete with party members, skills, functional inventories, and functional equipment).

The character screen (complete with party members, skills, functional inventories, and functional equipment).

Finally, the last set of issues, of sorts, lie with the assets. As I’m not that great at 3D modelling and probably could never learn how to do it in a reasonable time frame (if at all) there’s little to no chance of providing my own assets to use. Though I have found some great free Unity-provided assets and I do have some great general fantasy assets in mind- there are no concrete choices yet. I’d like to get some, I’d like to get some others, I’d like to really get some of them… but there are so many choices. Many are required, though. Which opens up another can of worms- the integration of each set of assets together to create something that doesn’t feel stitched together.

Still I hope you enjoy the new development screenshots.

The Expertise screen (with categories for the different resources you can gather).

The Expertise screen (with categories for the different resources you can gather).

Truth is, I’d have done a video but this version of the game just isn’t ready for a video yet. Having switched back to first person, from third person, and using a new first person controller at that, basically means I need to figure out how to pause the character motor in menus. Otherwise you’d get sea sick trying to watch me navigate the menu system.

All of the above taken into account, if I could get a functional battle system, and actually build a new area, this would be playable. Funny how that works. Where the project is going from here, when it will be finished, if it will be finished, and many other questions will lie unanswered for a while to come. But, I will, as I do, remember how the whole C# thing works. Also, how Unity works. So this isn’t likely to be the last you’re going to hear from me regarding Unity.

Have a nice week, all!


Upgrading to Unity 5

I’ve been excited about few things as much as I was excited about this the other night.

I wasn’t too interested in the upgrades that came along with Unity 5 (mostly as I never read the upgrade notes) but after somehow finding myself looking at them the other night, realising a lot of once Pro licence features were now in the Personal licence, realising the Personal Edition was a thing, and generally being all a flutter with the various things that I could possibly now do with it- I just had to get it. For those who have downloaded previous Unity versions this one seems to be a bit heavier, takes a bit longer, and downloads a bit more from the internet during install.

The standard assets in Unity 5 have been updated and now feature many awesome things that you previously didn’t get. Such as high quality water and ocean prefabs. There’s also a few trees utilising the SpeedTree features. Not to mention a few really useful models, some prototyping things, and general awesomeness abound.

Unfortunately it doesn’t include some of the things that were included in the previous standard assets like Skyboxes and the number of textures it offers is a wee bit shy of what it used to offer. However, if you still have the assets from Unity 4, or if you have a project that uses them, you can simply copy them over and they’ll update mostly without issue to the new version. There are some things that you’ll need to go through and sort out (or at least I did) such as the Skyboxes which you need to fix for the HDR settings. It’s pretty simple, though. They literally give you a button that you press and it makes it all nice and shiny again.

However, when all is said and done- the fifth version of Unity is beautiful. It really is. There are some really nice additions to the base functions, the character controllers for both third and first person are massively improved, there are some nice test assets (including cars and jet planes), and if you have a nice collection of assets otherwise you will be able to bring this all together for a great project. I’m really stoked about the water, the new shader options, the new physics options, and the whole SpeedTree deal personally.

For those who visit the blog regularly you’ll know that I have a few Unity projects on the go at the moment.

I have the first- the very first thing I ever built in Unity- which I likely won’t finish/update. I also have the second and the major project (I guess you could say) which has been a bit shaky for the last month or so. Besides finalising the combat and equipment systems and creating a new area it’s pretty much playable. However, I don’t know what I want to do with it yet. I have already revisited the skill system once and I don’t necessarily want to waste the time doing so repeatedly due to my inability to decide on a path and stick to it.

The major questions in my mind are all about the progression in the game. Is it going to be story based? Mission based? With a party? Or on your own? I have all the relevant systems implemented to do all of the above but it’s about deciding which to stick with and follow. Which causes me no end of stress.

I have, finally, kind of, decided on the assets I would like to use. So that’s something at the very least!

Have a nice week, all!


Developing with Unity (Pt. 8)

Skill systems, fine silk ties, item systems- these are a few of my favourite things.

You remember in the last Developing with Unity post that I discussed how I feel that the item system is usually the make or break for a game for me? No? What- you mean you didn’t read it?! What kind of audience are you?! I jest. I love you. Like a man loves fine silk ties.

Or like this man loves fine silk ties.

I’m also rather taken to skill systems. While my poison is usually something along the lines of a point or progression based skill tree- I am pretty flexible. If the skills are good or interesting then I will take to it regardless of whether or not it features some way to invest in, enhance, or completely change skills. This is why, after playing around with a battle system script some, I started thinking of ways to revamp the skill system for my characters. I wasn’t bold enough to implement a point based system but I did give each class its own particular flavour.

I’ve worked a lot on the individual systems in the game trying to polish various things and get them to a “near final” state. This includes the equipment system where the entire set of items you will find in the game are now in, once equipped they are saved and loaded when next you play, the basic initial equipment is now added to the characters on creation (and all associated statistical bonuses), food can be eaten, junk can be looked at with a contortion of disgust, and so on. The tooltips are separated and besides some functionality which has been left out for the time being- it’s all there. The functionality that isn’t there is so ridiculously easy to add in as well.

The inventory is the biggest pain in my shapely rear at the moment as I don’t have any way to save it. Well, no, tell a lie- I could save it- but I don’t want to. Why? Well, many reasons. One is that while I could use the same save and load method I used for equipment for the inventory it’s a lot of work. It’s tedious. It’s time consuming. Which doesn’t put me off at all. But I don’t want to think of a better idea later and then curse myself for not adding that in instead. Or, worse still, adding it in later and spending more time on it.

Given that you can acquire, equip, and use items and that the demo isn’t going to be incredibly long (the first one anyway) there isn’t really a need to have a persistent inventory yet. When you get deeper into the game and past a couple of quests then it will become a necessity.

I’m sort of hoping that you can make one team and keep using it over and over after the first demo. In the first demo it’s all about getting a feel for the game.

By the time the second demo comes along (if it comes along) the inventory system should be saving itself and/or loading itself. But until then it’s not really on the high priority list. Seems like a silly thing to say, I know- but it does make a strange sort of sense. To me at least.

Have a nice weekend all!


Developing with Unity (Pt. 7)

Items, equipment, and all things you can loot from corpses! Or chests.

Following on from the previous post I began the project anew. All old scripts, all old assets, and all old project files were scrapped in favour of something a little more ambitious. I switched focus from a single character third person ARPG to a three person party RPG. I’ve included some concepts that wouldn’t be too out of place in a CRPG and really I’ve been working on systems more than anything. Character creation is much more difficult when there’s three of you, there are classes, and there are class specific skills included!

But the character creation and party abilities are more or less finished now.

I’m going to be adjusting the size of windows and presentation and things like that in the future. But for now it works, it has bells and whistles, and it saves correctly. Loads correctly, too. Be a bit awkward if it didn’t. The next task was the HUD which is pretty simple in this case as there aren’t many screen elements you need/want as there’s a whole menu elsewhere.

Behold- camp! Also, GUI. Also, character statistics!

Behold- camp! Also, GUI. Also, character statistics!

Which brought me the biggest beast of this, and, well, every project I’ve worked on thus far- items. The wonderful things that make you yelp in delight or snort in disgust. There are many different ways to work on them, to implement them, to provide their bonuses, and to separate their bonuses between different item classes. To be honest, this is the one section of the project that I absolutely dread as, to me, the items and the loot are often the make or break for the enjoyment of a game.

There are a lot of questions in my head when I think about items. What makes a really good item? What makes a really poor item? How do I make really good items stand out without diluting the feeling of awesomeness when you find one? Is that last question even a possible scenario? Many, many things.

With what I’ve got currently outlined in my project files I don’t have a huge amount of equipment, but I do have crafting, and I do have items you can’t craft which are inherently good, but there’s no reliance or need for either. You don’t need to craft to get good items. But, equally, you don’t need to rely on good drops for good items. I’ve also started working on the master script for every object in the game that can drop equipment, items, gold, crafting materials, and more. There’s also a partially working equipment system which you can throw a few items into. I’ve got to finish that and then find a way to save the inventory you have and equipment you’re currently wearing to the save file.

The good news is that most of the menu is done, too. All sorts of goodness already exists and there are parts I can reuse from the character generation script to make it much easier to progress to a fully working menu. It’s a lot of work- but it’s less than it would be if I couldn’t reuse things or if I didn’t have a project file drawn up.

After these elements are all fully working and available it is time to tackle the wonders of a combat system. Which is going to be a pretty big part of the project in itself.

Have a good week, all!


Developing with Unity (Pt. 6)

Full speed… reverse?

As odd as it may seem considering my recent progress with my Unity project I am thinking of starting over. Fresh. Something new. Something different. Or, as is more likely, the same but better than it currently is. Now, before you brandish your pitchforks and torches- I have my reasons! Let me explain! Oh, why won’t you let me explain?

To be honest I didn’t really know what Unity could do. Or what I could do with it. So I went into this project pretty much blind. I didn’t have any of the resources or the statistics or just about anything planned out. I’ve been winging it the whole time, which, so far, hasn’t worked out too badly. However, as I add new features like skills and the components attached to those features it is starting to become somewhat… tedious? Cumbersome? Unwieldy?

As an example think about any skill from any game you’ve ever played. It has a cost, sometimes a cooldown, sometimes a duration, and it can generally be improved. In this example that is four new variables that need to be introduced. For a simple skill. Which, while it is easily added to the code, it is not initialised with the rest of the statistics unless we start a new character, or add in something to set those values. So, every time I add a new skill I’m adding several new values which, as I haven’t planned them, are pretty much made up on the spot, which then I need to get working or else the GUI and keybind and everything else doesn’t work as it should.

While (as noted above) this is all very easy from a coding perspective it’s a more difficult experience for the testing and implementation phase(s).

Therefore, if I had just a simple framework and had something to work off of it would be a lot easier to do. Now, while I could also just draw up the framework and add it to this one, which wouldn’t be overly difficult- I want to trim a lot of the fat out of the code. I want to get all of the bloated code and strip it out completely.

That and I haven’t really thought about where I want things to go and how I want the character to progress. Plus, I do want to add classes with class specific skills and some other things that will make it a lot more enjoyable to play. Or test. As the case currently is. This doesn’t necessarily mean a lot of work for me in the short term as a lot of this is coding related and I can still use the bits that aren’t overly bloated with unnecessary code. It does mean I would be starting again from scratch.

But I reckon within a couple of hours I could have a basic and working character creation up and running.

To be fair, much of the time, if not half of it so far, was spent testing new components and working out all the bugs and various errors that a simple script can introduce. Not always. Some just work. But only when I sacrifice a goat to the Goddess of Harvests under the first full moon of every month. So, sadly, not very often. I don’t think it will be too detrimental at this point as most of what I have is just systems and statistics. With a framework, a set of statistics, and an actual reference I could probably get through it several times faster.

Have a nice Sunday, all!


Developing with Unity (Pt. 5)

Character creation creation is a blast. No, that’s not a typo- it’s a week of work!

One of the things I’ve had since the very beginning is a very crude character creation system. It’s not pretty, it doesn’t have textures, and it’s basically a box- but it works. It also allows me to build a general framework for things like statistics, statistical formula, which values to save, which to load, which need to be set at the beginning of the game to a default value, and really how to get everything working when there is a reason to have a character creation system.

Recently I’ve taken the time to update all of this to something a bit more pretty and a bit more functional.

I’ve also added in some basic skills and skill levels so that you can actually unlock/learn a skill on your first level during creation and distribute some attribute points. However, these functions also leave a lot of room to build in things like different character races, traits, and other neat things like that. While, at the moment, I’m not planning to have those- it never hurts to have the ability to.

Low resolution background textures that look awful are the best!

Low resolution background textures that look awful are the best!

That and it doesn’t look like a completely horrid grey box on a black background. It’s now a grey box on a low resolution skybox texture. Improvement? Maybe! The point is that everything is roughly where I want it to be and there are some neat parts of it (like the skill choice complete with skill windows) that I can pull out and use in other parts of the GUI. This is probably as close to done as it will get until I start texturing. I am quite happy with it, it serves its purpose, it gives information, and it allows me to clear my values and start over when I make major changes.

The other thing that came with all of this was developing a way to make skills actually usable. Previously I would show a blank GUI.Button where the skill would be, but, no longer, it now has functionality complete with cooldown. All sorts of background calculations go on and calculate if you have enough mana, if the enemy is in range, if the cooldown is active, and so on.

Therefore, with the basic combat system from the previous post, and the improvements in this post, the combat is really starting to take shape.

You can wander around, encounter enemies, fight enemies, kill enemies, receive experience, receive gold, get hurt, get healed, die, save, load, and do many other things. The inventory system is also functional in the sense that it’s there but it doesn’t actually do much. However, it does display the gold value and items found in lootable objects can be added to it. The next step in this journey is to begin to build some kind of equipment system and to actually get those items to do something. Which probably isn’t as difficult as it sounds as I have all the values for the items already created and stored.

Then we’ll be at the point where the character is created, can encounter enemies, can improve their equipment, and can work towards levelling up. Quest systems and some kind of log to follow once all of the terrain bugs are sorted out. Then it’s onto story and such. Oh and dialogue, quest rewards, bosses, dungeons… the list is quite long.

I have to admit that I’m in a little over my head with this particular project but I don’t regret trying to do it. It’s a challenge if nothing else.

Have a nice weekend, all!


Developing with Unity (Pt. 4)

Isn’t it great how a camera finds you and follows you around?

Just like that guy who followed you home from school every night. Except less creepy, more essential, and less likely to result in a restraining order or other legal action! It’s one of the unsung parts of game development. When you think about everything you see when you first load any game (the GUI, the character model, the environment, the monsters etc.) you never think about the one thing that makes it all work- the camera. Without the camera the GUI has no canvas with which to display precious information. Without the camera there is no way you’d be able to see your character and the environment around them.

While systems, statistics, formulae, and other goodies make everything do what it is supposed to- cameras show you that it’s working. Or not working. Yet, funnily enough, you never really think about that and how to attribute cameras to an object in order to persistently follow its adventures.

The other thing about cameras is that the angle, rotation, and type are very important in what kind of game you make. Something like Diablo II could be made with a first person camera but a lot of the core design, the graphics, and interactions would need to be changed. Likewise, while The Elder Scrolls V: Skyrim could be made in isometric top down style, it would sacrifice a lot of the detailing already present in the world.

So, in short- cameras are the best.

But within this there are many questions revolving around the control system. For instance, most first person games don’t have a point and click control system as it wouldn’t work overly well, while they are also reliant on key binds, and more attention is paid to exploring up close and personal. In isometric games, while key binds are present, they aren’t as required for most functions as you can click the elements on screen, and often you click to move. This means some games inherently work better with W, A, S, and D while others are better point and click.

All of these little details swirl around my brain as I think of how to build my camera and how to follow my character through the world.

I have opted for the point and click method as that is what I would prefer my game to be. Something where you can click the terrain, explore the world, click chests, and generally it fits the art direction I am going for. However, I am encountering a few bugs switching from an over the shoulder to point and click camera rotation.

Mostly in the case of higher terrain elevations that the point and click method cannot compute methods to reach. While there are likely some ways you could make it compute those methods- I’m actually not too bothered as I’m not set on what I want my starting zone to look like. I know I want a beach. Maybe. Which is why I can easily restructure it as a lot of what I use is stored in prefabs anyway. So I can simply bring those models back into the game world fully customised.

Time has also been spent updating the various systems in the game and polishing things such as combat so that, in a crude sense, but one with a few bells and whistles, I have a basic outline for magical and special attacks. I also have an outline for attack speed. While my older scripts already calculate a number of combat formulae.

So, basically- lots of good stuff!

Have a nice weekend, all!