Developer Diary #13

[Mike]

Design

Dev diary number 13, eh? Unlucky for some, but not us as July's been a very busy and productive month, just as well as the weather in the UK's been so rotten. I completed the list of all the items that I was telling you about last month - we finally have a comprehensive list of everything you'll be able to buy and equip in the game. No doubt the stats that I've given to them all will change immeasurably between now and when the game ships, but it's a starting point to work from and that's the most important thing. Once that was done, Lee and I worked on sorting out the format of the sheet so that we could automatically export data from it into the game. So now we can just update values in the sheet, press a big "export" button and those values will change in the game too. The really clever thing is that it doesn't just work on simple values - many of the stats of the various items change based on the Level of the unit that's using them. So, rather than a single value, they have equations that govern what their values are for any given level and Lee's made the exporter work so that it will export these equations too. All of this took a while to do but it's going to save so much time when we're trying to balance the game that it was time well spent.

Since that's been completed, we've moved onto another exciting phase of the game - the first completed level. We've been playing about with different levels up until now, testing out the various game components as they get introduced into the engine, but we've never tried to get an entire level working from start to finish. Until now...(dramatic music).

I wrote what's called a User Story - a short bit of text that lists the various events that would happen as a player played through the level - and this helped us see what systems still needed to be put into place. So far it's mostly been the objective system that we've been pulling together. We had single objectives working before but now we can link objectives together so that completing one will trigger the creation of another one, or an onscreen bit of text, or a camera move, or all of those at once. It's all very cool and makes the level feel much more complete.

Rather than start at the beginning, we actually decided on a level about a third of the way through the game as the one we'd work on first. That might seem a little odd but the reason is that early levels don't tend to have all the game's features in place, you introduce them slowly so that the player has a chance to get used to them and doesn't get overwhelmed. But, by a third of the way through the game, most of the core systems are in place so we'll be able to cover most of the features that are needed for the rest of the levels.

That's the plan anyway; I'll tell you how we get on next month. Toodle pip!

[Lee]

Code

NOOOOOOO!!!! 

I just spent over an hour writing my diary entry only to press the wrong button at the end and lose it all. I hate it when that happens, but fortunately it isn't very often. I might struggle to pluck up the same enthusiasm to write it all again, but I'll give it a go Morale of the story: don't hit "refresh all" rather than preview if you don't have a copy of your forum post.

Sorry it is late *again*. I'm pretty rubbish at remembering to do it. I was very kindly reminded on Friday night.

Anyway, as Mike mentioned in his diary, we have now begun building the levels. This is a very exciting point as we start to see all the hard work from the past months come together to start making a product. As always with things like this, it is only through using systems that you find their flaws or weaknesses. Our first task was to get all the items in the game. I wrote the system for this months ago, and it was based around the idea of having an individual lua script file for everything. The idea was to allow any item to do pretty much anything by overloading any of the default data or functionality. It worked well; however, what it overlooked was the pretty massive need for inter-object balance. I would say now, with hindsight, that that is much more important than easy overloading of features. A game like ours consists of a few hundred individual objects, from spells, weapons, characters, armour and so on. The hardest job, therefore, isn't customising the specific behaviour, but making sure that all of the variables for each of the objects makes sense in the big picture. To cut a long story short (the previous entry had the long form) we devised a new system which revolved around setting up all of the objects in a spreadsheet, writing a script in the spreadsheets scripting language to export all of the information as a series of nested lua tables, and then writing another lua script that would, at game load time, load this big exported table and condition it for the game, basically by presenting it to the rest of the system as though it were a unique script file. I still allow the possibility of loading a specific script for any given object to layer over the top of this data but we have not had any need so far.
This allows us to use all the conveniences of a spreadsheet for balancing (ordering, scenarios, graphing, statistical analysis) as well as maintain the possibility of using custom functionality per item. Oh, and a great side-effect of using a proper language for your data representation is that it is trivial to export equations (2+ Level*4, or more complex) straight to the game from the spreadsheet.

The second main body of work was with the editor. As I've mentioned in the past, I took the decision to build the editor in the actual engine using the engine's UI system, rather than the more usual approach of building the editor as a stand-alone application with the engine maybe embedded in it. This makes it very convenient to quickly jumping between the level editor and the game, and allows the possibility of having a very fine line (or no line at all) between the editor and game logic. All of this was done quite some time ago, but as we got into building some real levels, a few difficulties emerged with the way I had structured our objective/logic flow system. Basically, our level designs require the designer to set up a series of objectives (capture this point, kill that guy, get to this point), events (do this when that happens), and actions (lerp the camera to this point, put this message in the UI). In addition, there is a control structure to coordinate all of these things. Imagine it like a tree structure that branches based on several conditions. These behaviours can be run in serial, parallel or triggered based on some other event (such as time, or a series of other behaviours completing). I had built a script system to allow all of this to be built and it worked pretty well. The problem with it was that it imposed a mental context-switch dropping from the 3D editing environment to a text editor. Also, it was quite prone to mistakes as a lot of the game objects are referred to by name. These issues made it quite slow to build levels and we really needed to be able to try things out quickly. With this in mind I decided to create a system where we represent each of these logical behaviours as 3D objects that can be connected up with other behaviours and other items in the world. These things are then placeable and editable in the level editor along with all the other stuff. So now, if you want an objective which is "Kill this boss guy", all you do is place the guy you want to be killed, place a "Kill named enemy" objective next to it, connect the objective to the guy so that it knows who you are talking about and you're done. There is a bit more to it as you will most likely want the "Kill boss guy" objective to trigger once some other things have been done, or you may want to introduce it with a cut-scene. Either way, just a few more clicks creates the necessary links. So far, it seems to be working pretty well. I thought I'd just include a quick little scene-grab from the editor to give you the idea. I'm not going to explain precisely what is going on, apart from saying that all the little glowy objects on grey pedestals are the logical objects and all the lines denote their relationship with other logical elements or other objects. I'm sure you get the idea.


Well, we're now deep into this new phase of our development. The new mode is all about producing one fully complete, shippable level. It is a great way of testing everything out and showing up the gaps in our systems or the edge-conditions of the game design. We'll likely be in this mode all the way until the end now.

[Mal]

Art

Busy busy busy, is the best way describe the past month, and I imagine future months. Not like me to be the last to post my diary. I'll endeavour to be more punctual in future!

This month is more Monster based shenanigans!

Character creation thread