I did say that I would talk about the trait system this month, but I’m still doing a lot of work to get it into a shape that I’m happy with, which means that a lot of how it works is still a bit up in the air. So instead I’m going to talk about something that’s more finished in terms of its design, which is how the game generates crimes and feeds information from them into dialogue trees and combat scenarios. This is how the bulk of the story content in the game is generated, so I think it’s worth spending a bit of time explaining how it all works.
Dev Blog 9: A Brief Update
Unfortunately I’ve spent a lot of the past month dealing with a family medical emergency, so development on the game has had to take a back seat. That’s why there hasn’t been a September update to the dev blog yet. I have gotten some things done that I’m pretty happy with, but there’s been a lot less work than in other previous months.
I’ve finally picked out some fonts. So far I’ve just been using the default Unity font, but now that I’ve got a user interface which is much closer to what I intend the final interface to look like, I needed to get a proper font in the combat UI so that I can make sure things are properly sized and readable. There’s no guarantee that I won’t decide to change the font later, but I think it’s more likely than not that the ones I’m using will be sticking around.
I’m using fonts downloaded from Google Fonts, which is a fantastic repository of fonts that can be used absolutely free in commercial or non-commercial projects.
Dev Blog 8: UI Overhaul
The pace of development has slowed down a bit over the past month due to family obligations, but I have nearly completed a pretty significant overhaul of the way the combat sections of the game look. The user interface has been completely overhauled, both to look nicer and to fit in better with the new isometric viewpoint. Like a lot of people, I’m a big fan of the interface design in Into the Breach, so I’ve been referring to that game as one of my main inspirations in terms of how to do UI that communicates effectively in an isometric 2D game. After the jump I’ve got the first new screenshot that I’ve taken in quite some time, so let’s take a look at that and then I’ll go into a bit more detail about the changes and the new visual design.
Dev Blog 7: Dialogue Engine and Combat Improvements
I didn't get around to writing a development blog post for June, but I did get lots done during that time, so this dev blog will have to get caught up on two months worth of work. The main thing that I worked on in June was the dialogue system, while July saw a number of improvements to the combat engine. I also made the decision a couple of weeks ago to change the perspective from a flat cartesian co-ordinate system to an isometric view. So let's dive into what's been added to the game over the past couple of months.
DIALOGUE
I considered writing my only dialogue tool, but before I got around to it I discovered the excellent ink tool released by Inkle Studios, who are most well known for the excellent visual novel 80 Days. ink is the framework that Inkle Studios uses in their own commercial games, and I found that it fit my needs perfectly. The dialogue portions of The Last Virtue were always planned to be a bit visual novel-ish (if you've played The Banner Saga, the dialogue trees there are pretty close to what I'm aiming for stylistically), so it seemed like going with ink would work quite nicely and save me a lot of work as well.
Dev Blog 6: Why The Last Virtue Doesn't Have Levels
I've held off on announcing a title for this game for a long time, but I've had a title picked out for a long time, and I don't think there's any particularly good reason to keep the game untitled, so I may as well reveal it now.
The game is going to be called The Last Virtue. The meaning of that will make more sense as I explain more about the story and setting, but that's a topic for a different blog post.
Most of my development time in March was spent on improving the hub that the player returns to between bounties. The hub will work a lot like the ship in the recent XCom games or the camp in The Banner Saga, where there are several sections of the hub that you can click on to view or modify various aspects of your party. I'll probably return to that part of the game in a future blog post, once more of it is finished and it looks nicer. Instead, I want to use June's development blog to talk about one of the design philosophies that I'm pursuing, which is that unlike virtually every role playing game you've ever played, characters are not going to level up over the course of the game.
LEVELS SUCK
I've disliked how character levels are treated in role playing games for a long time, and I knew early on in this project that I wasn't going to use them, but I decided that it was worth writing a blog post about this aspect of the game after reading a couple of old posts by Raph Koster, who was the lead designer of Ultima Online and creative director of Star Wars Galaxies. Here's a summary of Koster's thoughts from his post-mortem of Ultima Online:
Levels still suck. I don’t know what the complete replacement is, but I am troubled by how addictive the experiences we’re making are (like, seriously addictive, ruin-your-life addictive) and I think levels are a large part of that. Plus I still find them divisive of players and a forced limit on interaction, however convenient they may be for advancement ladders. They are a bad model in terms of adding ongoing content to your game, in that you always have to add at the top end, and you have database deflation problems. Lastly, I have trouble fitting in many of the mechanics we were successful in putting into UO, such as crafting, onto standard level systems.
Dev Blog 5: Level Generation Algorithm
I'm a bit late on the April update because I spent last weekend at the Halifax Game Jam, where my team produced the endless flyer Flight Club. However, April was a pretty eventful month in terms of development. I've continued to update the UI in the combat sections of the game, so it keeps getting a little bit better and more usable with each passing month. There's also now a complete (albeit fairly bare-bones) game loop, where you can select a bounty/quest, go into a combat section to complete the bounty, and then return with your reward to the hub section. May is the month when I'm implementing a lot of the hub functionality, but I'll get to that in the next dev blog.
The main thing that I spent April working on was the level generation algorithm and the level editing tool that makes that easier. Up until now there's been a single hard-coded combat area in the game, but now I've put in place most of the code that will be necessary for generating unique areas for each combat. I'll spend the rest of this blog post explaining how the level generation actually works.
Dev Blog 4: Continued Adventures in Quest Generation
I'm a bit late on my development blog for this month, but it's not for a lack of progress. I've continued to work on the game at the same pace I've been going at for several months now. Unfortunately, there isn't much that I worked on in March that I can really show off.
Most of my development time in March was spent continuing to refine the bounty generation algorithm and related user interface design. The game will now generate a series of quests/bounties for the player to choose from, and when you select one it now sends you into a combat based on the bounty that was selected. This basically just links up things I've discussed in other recent blog posts, so it might not sound very exciting, but in terms of the game architecture it's pretty neat to see it come together. Up until now most of the systems have been siloed off from each other, but now they're getting linked together in ways that make it feel more like a real game, and some of the procedural elements are starting to come together.
I've already got some really neat stuff done in April, but I'm going to save that for next month's development blog when it's a bit further along. At that point I'll write up how the level generation system works. It's a key system to the game, a big part of what makes the combat unique and replayable, and I'm pretty excited about how it's shaping up, so next month's dev blog should be a lot more interesting.
Dev Blog 3: Quest Generation and Some Combat UI Upgrades
In the last dev blog I had a lot of systems updates to talk about, but nothing to show off in terms of visuals, which can be kind of boring. In February I did a lot more work that I can share in screenshots, particularly new UI elements. It's all still programmer art that will eventually get replaced with real art, but it's still useful from the standpoint of hooking everything up and writing code for the underlying systems. I also finally got around to adding camera controls, so you can change the zoom level and pan the camera around.
I checked a lot of little tasks off my to-do list, but there are two main additions that I've made to the game that are worth discussing in some more detail here. Since I've mostly been talking about the combat engine so far, I'll start by showing off some work I've been doing on the combat UI, and then I'll jump into the second major system (and the first one that takes place outside combat) that I've been working on.
Dev Blog 2: Settling on a combat model
I made progress on a lot of components this month, although they're mostly things that run under the hood and don't make for very good screenshots. The biggest thing that's been added is character classes, which I'll get to in a minute. I also finalised (I think) how the combat model is going to work. I also want to briefly touch on some of the smaller things that I've worked on that might not be as exciting, but are pivotal to making the game play well. In particular, I did a lot of work on the interface so that important bits of information (like how many hit points an enemy has left) are easy to find. Up until now almost everything has been in my head and it would have been impossible to play without a bunch of knowledge that only I had.
The Combat Model
The most important thing I've been trying to figure out with the prototype is exactly how combat is going to work, so that I can start implementing abilities and do a bit of balancing to make sure it all flows smoothly and is fun to play. I knew I wanted to do something that involved action points, but I had a few ideas that I wanted to test out to see what worked best.
Artist Wanted
Pykrete Games is looking for an artist with the ability to create 2D art for a tactical RPG that is currently in development. If that sounds like you, please get in touch at pykretegames@gmail.com.