Kate here with this week’s Awakening Wenesday! I decided to do something a little different and post a video of making character portraits for the game. Might be useful or at least informative!
Hi it’s Kate again this week! I’m currently busy working on character portraits for the dialogue segments of the game, so I thought it’d be interesting to show the evolution of the portrait style.
Our initial decision to use portraits visual novel style was one made by looking at the skillset and technology our team had at the time we started making the game. We’ve come along a way since then, but at the time, it was really the only feasible way to tell this complex story with lots of characters expressing lots of emotions with a limited team with a lead artist mostly grounded in 2D (my professional background before Project BC being largely comics and 2D illustration).
One of the earliest attempts I can find around interestingly shows an experiment with a character front-on, like Phoenix Wright or some dating sims:
Now, one of the main issues with this format is that it works great when characters are talking to your protagonist and feels very immediate and personal, but it doesn’t work so well as soon as you have to depict different characters talking to each other, which is quite common in VSA. In fact, characters have relationship values and character building events with each other which may not even involve Dakura at all, so it was necessary to reconsider the style to better accommodate the style of the storytelling.
After deciding on 3/4 view characters, I experimented with some different styles:
I call the first one “shoujo Dakura” because of the shoujo manga feel of the fine lines and soft colours. I was trying to evoke the feeling of the portraits from the original Vacant Sky Contention, which are very soft and pretty. When it comes down to it though, while our audience is mostly female, it’s still pretty mixed, but more than that… it’s just not really my style at all, My work is strongest when I’m working with a more solid feeling. In fact at this stage I was really still holding back on the kind of chunky lines I like to work with.
The portraits that were the “final” versions for a long time looked like this:
Because the game was set to be told entirely in Visual Novel format, I felt it was important to show a good view of the characters, so they go right from head to mid-thigh. This was…not my best idea ever due to the enormous workload it created. Every expression for every character required a new almost full body drawing. Another issue with these was that for promotions and pitches, the main characters had to be rushed through first, so we ended up with a situation where the main characters weren’t as well drawn as some of the NPCs done further down the line. You can definitely see how the drawing on Sarian doesn’t compare well to her original concept illustration, and that Naora looks stylistically slightly different, having been drawn months later.
Between making these characters and now, we discovered techniques and technology that made 3D models possible. Suddenly showing the entire body on the sprites was really no longer a huge issue. Feeling dissatisfied with the old portraits, I brought up the notion of redrawing them, this time with a Persona esque view limited to just head to chest. The test images came out great. I’d estimate they’re about three times faster to create than the old portraits were too, so massively more efficient! With less rush and pressure, I’m able to put move love into the portraits, so they come out more polished. Well, that and I’m just generally a better artist than I was when we started out here.
There are some little touches of polish here to the shading and colours that would have been a pain to add on the more arduous larger portraits. Well, that and maybe I wouldn’t have even known how to do this stuff efficiently back then! I’m pretty pleased with how they look.
Another cool thing to note about this image before I sign off here. This is an actual screenshot in the game engine, it’s not a mockup like all those previous images! We hope to show you more images from in-game soon!
Welcome to Awakening Wednesday, a new feature where we will dedicate the midweek to giving you behind the scenes info on Vacant Sky Awakening from the various members of Project BC!
This week, I’m up! I’m Kate, I’m primarily the art director, character designer and character artist among other things. I’m here to talk about the interesting and convoluted design process behind Sarian Monarim, a party member in our upcoming release.
From the get-go, I knew I wanted Sarian to look very distinctive because she’s such an interesting person. She’s got a lot of conflicting sides to her character; she’s one of your hardest hitting partymembers, but she’s physically frail and must walk with a cane, she’s highly intelligent but has an underlying emotional naivete, she’s both the most serious partymember and yet also one of the wittiest, she’s wise and educated but she’s still a teenager, she’s a young maiden and a noblewoman but she loves to mess with the system. The nice thing about working in a small team is being able to really get to know the character you’re designing before you put pencil to paper.
For me, a pencil and paper is generally where I go when I’m brainstorming, and I usually do it sat on the floor because hey, that’s how I learned to draw as a baby, why not!?
Sarian’s first design. Wow this feels a long time ago now. She was the only party member in the first part who didn’t have any old design ideas from Bishop lying around. Believe it or not, originally Korelli had that hairstyle. I was confident that giving this short, hard cut to Sarian would be a good idea. Korelli was instead given a cute, soft ponytail. Many of the design elements were in place for what would be her design for a long time and even up until the present even at this early stage; the snake cane, the mantle and hood, the choker, long gloves and, of course, an ankle length dress; I knew I wanted an ankle-length dress because I have always imagined Sarian’s legs, as well as being weak, may be a little warped or maybe just very bony and she doesn’t like people seeing them.
I also noted down things I didn’t like; those clumpy boots, the belt that ruins the flow, and the stupid idea of a character who isn’t very mobile wielding a knife of all things.
Sarian’s “final” design as it stood for a very long time. I think it’s a nice one! I’d like to reuse elements of this sometime down the line. Sarian’s colour scheme uses green and purple; typically villainous colours. A nice thing with Vacant Sky Awakening is that a major theme is “you play the villain”, so the party have some villainous looking elements to them. Except Korelli of course, who is just dangerously adorable. The Orkan clothing is largely influenced by Regency and Victorian period British fashion with some Fantasy elements thrown in. I’m a huge dork when it comes to clothing from different time periods, cultures and subcultures, and tend to do a lot of research and collecting of references from all over the place.
Sarian’s image from the Kickstarter campaign. The only major change here is that she’s lost her sleeves. The more I drew Sarian, the more skinny and angular she got. I really wanted to subvert that whole idea of the “ill heroine” in games, they usually don’t look ill and their illness inconveniences them in no way at all physically, they just randomly cough up blood or faint at plot points. Sarian is pale, gaunt, bony, physically weak… and she will incinerate anything that gets in her way. She’s a character whose disability is not a superpower; it makes life hard for her, but she’s not helpless. She lives with her disability and has become strong in her own way.
Ahh the character render we used for the promo video! This was our first time making a fully finished model. I did the texturing on this.
It was at this stage that we discovered that rigging is a nightmare. Having such a small team, we can’t afford a dedicated rigger and don’t really have time, and Sarian’s big hood and mantle were causing serious problems. After deliberation for months, we realised we really had no choice but to redesign Sarian to be more 3D friendly. So it was back to me to redesign a character I had felt was one of my strongest designs to still have the same sort of feeling and still be striking and distinctive, but to also be rig-friendly with no clutter on the shoulders or armpit region. Another request that was made was to at some kind of extra interest to the long drop of the dress. I spent several hours trawling through as much info as I could find about Regency period fashion looking for interesting ideas and doodling things I immediately deleted because they were awful. Naturally after struggling for a while, I went back to paper. I sat in my garden and started sketching:
As soon as I drew the collar to replace the hood, I realised I’d have to slant the hair to make it work. You can even see in the top left where I rubbed it out! I realised that it actually looked better that way; the sharper angle works well with Sarian’s sharp personality as well as her subversive nature. Sarian became more edgy as these gothic and grunge elements worked their way in and yet, at the same time, she became more period-accurate too, with the Spencer Jacket and chemise and the very high waist. The “Dysiaboo” thing will make sense when you play the game, but Sarian has an intense fascination with the culture of Orka’s rival nation, the Dysian Empire, and kind of nerds out over their more “Enlightened” culture to the point that we started to call her a “Dysiaboo” in conversations. I tried a design with some of the classical and imperial elements of the Dysian Empire in, but it was a little plain and also would have made the Dysian characters you come across feel less distinctive, so I toned them down. Amazingly that batwing shaped chemise was based on an actual Regency period design. Why we don’t have Pride and Prejudice and Batman yet, I don’t even know! I had this weird thought about a wing pattern that kind of encloses her chest and it just worked. It felt so perfect for her subversive nature to have these symbols of chemistry and medicine enshrined with dark wings. Sarian loves science and magic; her life was saved by them as a child. The snakeskin-like chemise also gives a sense of “rebirth” to Sarian.
Sarian’s new design! The symbol of Mercury; a life source in alchemy but also a poison, sits in pride of place above the star of the Orkan church. Sarian sure likes to play close to the edge! The little brass studs make her look kind of punk, which I love. I’m actually really happy with this design; it kind of fits her even better than her old one did. And so we get to making game graphics and…
It’s coming along nicely!
Kate posted a brilliant behind-the-scenes look at the design and creation of the new Auria. Check it out on her blog.
There, And Back Again: The Long, Arduous and Mostly Uninteresting Tale of the Ill-fated Metis Engine
It’s been a while, huh?
There’s been a lot of nothing from us lately, which some of you have correctly noticed as being pretty weird, as I’m normally all about showing progress as it comes out. There are quite a few reasons for that, and I can’t touch on the big ones just yet, but in the interim, I’d like to dam the silence with an update on one of the main reasons that Awakening is taking so long.
Early days: The wild west
In the beginning, we didn’t really know what we were going to use to develop the game. What we did know was what platforms we wanted to support: at the very least, PC, Android, Ouya, Windows Phone, Windows RT, and Playstation Vita. I played around with every development tool under the sun: XNA, Unity, Flixel, and even Haxe for a brief stint (I got halfway through porting Encarmine before the buggy Haxe workflow finally made me throw up my arms in defeat).
Unity was the fastest to develop with, thanks to my past experience with it, but it lacked support for three of our key platforms: Windows Phone, Windows RT, and Vita. So that got dropped. It was around that time that I heard about Monogame, which had just announced support for Vita by way of its Playstation Mobile branch. Since Monogame and XNA are mostly compatible, getting the game onto Windows Phone wouldn’t be difficult, either.
I must have started on coding the game in at least a dozen different tools and languages before settling on building a new engine based on Monogame. This must sound odd coming from me, as when I mentor others in programming and gamedev, I always advocate starting on making your game ASAP, and once you get started, never question the basic design choices you settled on, otherwise you’re liable to keep stopping and restarting forever.
Vacant Sky Awakening is kind of a weird game, though, and the problem space it occupies has continually defied all my nuggets of conventional wisdom.
The biggest problem I’ve been contending with throughout development of the game, aside from its broad spectrum of platforms, is future-proofing. The game is going to be released in 8, or maybe 9, episodes over the course of the next couple of years. Whatever design choices I make now have to stand two years from now as still a good move at the time: still easy to develop for and still marketable as a product.
I learned from Contention about the dangers of starting a long-term project on a crappy foundation. The legacy code I still deal with has made the task of updating Act III a nightmare of frustration and wasted time. I don’t want to run into that problem ever again.
As a result, making the correct choice of development tools now is extremely important, so much so that I’ve been willing to prototype the game on a dozen or more different tools and throw it all away each time to try a different approach.
Post-Kickstarter: VSA Alpha and Metis Engine
After the success of the Vacant Sky Awakening Kickstarter, we got to work on building Metis2D, the Monogame/XNA-powered game engine that would carry the game to its many platforms. Because we coded the engine ourselves, we had full control over it and would be able to adapt to new platforms and requirements as they came into being.
The high level vision was to eventually create something that brought the flexibility and ease of use of Unity into the 2D space, which we could then sell after the game was finished and use it to finance further games.
It was a colossal undertaking.
We ended up releasing our first Metis-powered game, the Ouya port of The Vestibule, in time to be one of the Ouya’s launch titles. It went… well, I wouldn’t say smoothly, but it went acceptably. There were bugs and crashes and race conditions and altogether it was kind of a nightmare, but it was still better than dealing with VS1CE, and that’s something.
With those issues ironed out, we continued hammering away at Awakening EP1, and developed several alpha builds, including the most recent one, Alpha 5, which has the entire game (sans battles) playable from start to finish. The game was playtested by several people, we got helpful feedback, and most importantly, it was adored by everyone who played it! All that was left was to polish up some graphics and add in the battles and the game was ready to release, right?
Yes, actually. We didn’t run into any serious problems, we had a basic version of the battle system working, and everything about the game seemed like it was coming together. This is the part where you’re expecting I’m going to say “that’s when we discovered some horrific bug that changed everything” but the truth is, Vacant Sky Awakening Episode 1 was pretty much done and ready to go into beta.
Beta 1’s Shocking Twist…!
There wasn’t a problem with the game or the engine.
Actually, there wasn’t a problem at all.
But a couple of developments happened in quick succession that had a significant impact on our future plans for the game. I can’t talk about all of them just yet (sorry!), but there were four in particular that caused us to seriously reevaluate what we were doing: 1) We got the thumbs up to release VSA on the PSN as opposed to the much more limited PSM; 2) Microsoft pulled the plug on supporting XNA going forward 3) Unity added support for Vita, Windows RT, and Windows Phone; and 4) Unity announced version 4.3 with native 2D support.
We agonized about what to do for a long while. We had a nearly-complete game with no significant issues, but the rate of Unity’s evolution was making it clear that an eventual switch was going to be inevitable. Unity’s workflow is much cleaner, easier, and faster than Metis’s, especially where UI and shaders are concerned. It can add platforms much faster than we can, with the added assurance that they’ll be fully debugged and well-documented. We would be able to spend our development effort entirely on the game as opposed to developing the game and maintaining the engine.
We could’ve released EP1 as is, but at what point would we make the switch? We needed savegames to be portable between all episodes. What if we ran into a last-minute showstopper bug in some platform for Monogame (as we did on Android, which required a huge rewrite of the rendering code) that knocked us on our feet?
On top of that, there were already fractures starting to open up in our plans because you can’t use Monogame on Vita outside of PSM, which meant we would need to recode the Vita version from scratch and we were now looking at maintaining two engines at that point.
I know it’s bound to be an unpopular move, but for all the above reasons, we decided that the best move would be immediately shifting gears to developing Vacant Sky Awakening with Unity.
That’s not to say that everything has to be thrown away and recoded from scratch. In fact, one of the main reasons we chose to go with Monogame was because it used C# (like Unity) and that we’d be able to reuse most of our code if we ever needed to switch over. On account of good planning, we had anticipated exactly this scenario and took measures to ensure it would be as easy as possible to make the move. One aspect of this was writing the story content in a Lua dialect, which is easily portable to just about everything with no code changes needed.
We’re currently working on the Unity version of the game, as well as polishing up the art assets and producing some new ones. There’s another big surprise yet for the game that I can’t talk about just yet, too. I’m sure the question you’re all asking is when you’ll be able to play the game, and the answer is… probably soon! Surprisingly enough, the move hasn’t delayed the game very much at all. Unity is just so much faster to develop with that rebuilding the game is only taking slightly more time than implementing the rest of the missing features in Metis would have been.
The highly visual nature of Unity gives us greater control over how the game will look and lets us rapidly iterate off ideas and track down bugs, which is an enormous godsend when it comes to the battle system (more on that soon…).
So what will become of Metis? It will still exist, albeit in a stripped down form. Most likely, it’s going to evolve into an RPG/VN-centric Unity plugin that we may or may not sell depending on how well it works out for us.
The end result to you all is a slightly longer wait, but in a much more polished game and smaller wait times between individual episodes in the future.
Sorry again for all the delays, but I hope I’ve outlined the rationale behind the changes well enough that you understand why we’ve made the choices that we did.
Post-script: Another announcement
It’s not exactly true that we’re developing the game entirely in Unity. Because of the prohibitive console licensing for Unity, we’re actually not going to be using it for the Vita version of the game. The Vita version of Vacant Sky Awakening is being developed with Sony’s PhyreEngine (which is why it’s most likely going to be released at some point after the Unity-based version). Unfortunately, due to the proprietary nature of PhyreEngine, I can’t talk about it much, so please understand that I won’t be able to discuss the technical details behind the Vita version going forward. I do plan to do a tech post in the future about our workflow involving designing for two engines in tandem, though, so look forward to that!
Time for another behind the scenes look at the technical aspect of Vacant Sky Awakening. This one is a little more high-level and touches on game design, so the non-technically-savvy readers don’t have to worry about their eyes glazing over.
Lately, I’ve been putting the finishing touches on the skill editor. One of the challenges of making a skill editor before all the content is set in stone is that it can be hard to predict exactly what tools to lend the user.
Let me give an example. In more typical RPGs, a skill could have the following attributes:
There tends to be a linear progression in skill power in these games, in which the skills you learn are just more powerful versions of ones you’ve learned previously, dealing higher damage and costing more MP. Though certainly easier to design and program, that’s also kind of boring.
In Vacant Sky Awakening, a much greater emphasis is placed on support skills, most of which produce unique effects that can’t simply be qualified as status effects (such as granting an extra turn). On top of that, skills can have lots of conditions, such as burning an amount of TP, or requiring you to have at least a certain amount of HP.
Although I could certainly put a checkbox for every single possible quality a skill could have, I decided to disassemble skills into constituent pieces called components. Skill components are the building blocks of skills – any skill can be expressed as a set of components.
Examples of components include:
* Inflict damage
* Can’t miss
* Apply status effect
* Costs TP
* Requires TP
* One use per battle
When I want to create a new attribute for a skill, all I need to do is create a new component for it. To ease this workflow, I’ve created a C# attribute I can stick on a class declaration that causes the editor to read it and create a button for it. Similarly, each field in that class is marked with an attribute that specifies its name and what kind of input widget to create for it.
This approach is very flexible and resilient to change, an absolute must when working on an episodic title where new mechanics can be added in the future that I have no way of predicting right now. It’s also very generalizable; I could apply the same concept to items (in fact, I probably will) just as well.
Thanks for reading this through to the end. I hope it was interesting!
One of the downsides to being a programmer is that I don’t often have anything visual to show off like my comrades of the artistic persuasion. There’s not really anything groundbreaking happening behind the scenes with the programming, either, so writing about the programming process isn’t particularly interesting. But this is one of those rare occasions when I do have something to show.
One of the major challenges of moving away from RPG Maker is that I no longer had a visual editor to define things like party members, items, and enemies. Until now, I’ve been hardcoding them directly in the game, but I’m finally reaching the point where it’s just too much of a hassle to do as a result of the increasing complexity of the codebase.
To that end, I’ve begun building Worldweaver.
It’s still pretty bare-bones and an early work in progress, but it’s an application I’m building to aid in the entity creation process. So far, I’ve finished the first three tabs (save for some minor bugs).
Worldweaver was built using Windows Forms and links directly into Metis and VSA, from where it’s able to draw entity definitions (say, the list of skill effects) and update the editor dynamically to reflect changes in the code.
I’ve spent about three days working on it so far and it has already paid for itself in terms of time spent versus time saved. There’s still a lot of work to be done, but so far it’s shaping up to be pretty helpful.