New account registration is temporarily disabled.
0 reviews
  • Add Review
  • Subscribe
  • Nominate
  • Submit Media
  • RSS

Progress Report

Gearing up for 2013

Hi everyone! It's been a while. Lots of things are new around here, and I thought I'd keep you posted on what our plans are going forward into the new year.

Evaluation and evolution

We learned a lot from the first Kickstarter attempt and got a huge amount of feedback (as well as many new fans to the series!). We've spent the past few months looking at that feedback and seeing how we could incorporate it to improve the game. We've made some pretty big changes to the format, but I'll touch on exactly what they are in a minute, after I've explained the rationale behind the changes.

The biggest thing we learned from the first attempt is how much money we can expect to receive in funding. Chalk it up to bad marketing, or a bad project page, but we only managed to raise around $9,000. Unfortunately, even if we needed no music, or programming, or software licenses, that still wouldn't cover the cost of all the sprites, animations, and tiles that we need (or, at least, not at a level of quality that would be worth showing to the public). Taking this into account, there are two changes we've made to the format of the game:

1) Episodic release schedule
Considering our history, this probably shouldn't come as a surprise to anyone. The first thing we decided to do was to break up the game from one huge, monolithic adventure into eight episodes. Each episode is planned to have about as much content as Act III of the original Vacant Sky, along with plenty more optional quests (which comes naturally considering how much more exploration-focused Awakening is).

This change makes sense for a number of reasons. From the perspective of the players, it means they get to experience the game sooner, so that's always a plus! From our perspective, it means we're able to get feedback as we go along and constantly improve the game based on feedback from the released episodes. It also breaks up the burden of art assets, as the cast and size of the explorable world increases throughout the story.

But the biggest reason why this change makes sense is that it means we only need to raise enough funding in the beginning to build episode 1. Theoretically, the revenue we get from episode 1 should fund the development of episode 2, and so on. Therefore, our second try at Kickstarter will be to raise the funds needed to build episode 1. If we breach our goal, any extra money we receive will be used to develop the subsequent episodes. Of course, anyone who pledges to receive the game will receive the whole game as it is available.

2) New exploration format
All right, so what about the game itself? The fact of the matter is, unless we end up with a lot more money than I expect, we just can't afford the huge amount of tiles and sprites we need to make the game. If we do it episodically, we might just barely scrape by, but it's still a big risk.

One of the things we brainstormed about to exhaustion was ways to get around this problem. In designing the gameplay of Awakening, we looked at all of the aspects of RPGs which are taken as givens, whether they benefit the genre or not, and ripped out what we could in order to get closer to the heart of what an RPG is.

Traditionally, the way you navigate an RPG is by walking around fields and dungeons, touching enemies to engage them in combat, and pressing buttons to activate switches or open chests. For the solution to this problem, we looked at other games, specifically tabletop RPGs such as Dungeons & Dragons, which have the player performing the same actions, but in a wildly different format.

That brings me to the results of our brainstorming:

The game board


This is the game board, and it is now the principle form of navigation in Vacant Sky: Awakening. Towns, buildings, fields, dungeons, etc are all handled in the same format. It's a mixture of board games and tabletop RPGs, wherein each space represents some kind of event - a discussion, a battle, a found item, a boss, a story event, and so on. It might not be the most glamorous to look at, but in testing, we've found that players have found it really fun once they get over the initial shock of the unconventional format.

Although the move was at first a cost-saving decision, I've come to prefer this new format over the conventional map exploration format for a number of reasons. Primarily, it gives us greater integration between narrative and gameplay. There's not really any such thing as a "cutscene" anymore because the events they would encompass have been integrated into the game board as event spaces. That might sound like it's just a difference of semantics, but you'll see what I mean when you play the prototype (more on that in a minute).

Behind-the-scenes changes

As a result of the new format, we've made some changes to the team lineup. Kate Holden, who previously was responsible for character design and map sprites, has taken over as illustrator, a job which plays a much greater role in the new format. I would also like you to welcome Anna Fitzpatrick to the team. She will be working as environment illustrator.

Here's a look at their work together in the new format:



Rather than with sprites, events are now illustrated with expressive character portraits, which 1) lets us show off Kate's awesome designs and 2) lets us bring the characters to life by showing their body language and facial expressions.

New format, new engine

One of the other big changes is that rather than releasing on PC alone, we're now committed to making the game cross-platform, supporting not only desktop, but also mobile. In fact, I should be receiving my Ouya dev console in the next couple of weeks, so I'll be hard at work making sure the new engine (which runs on Monogame) will run smoothly on it.

Onward

As of now, the plan is to launch the second Kickstarter on or around January 6. Our target goal for episode 1 will be $8,000. I'm confident that we'll be able to easily make our new goal, but it'll take a lot of hard work and dedication. We're only asking for the bare minimum we need to complete episode 1, and every little bit we get over that will be used to build episode 2.

That about takes us up to speed. Thanks for reading!

Game Design

The Construction of Metis Part 2: Virtual Playwriting

And now for the much more exciting part 2 on my blog series about the development of Metis, the game engine behind Vacant Sky: Awakening. You can read the first part here.

The topic this time is on cutscenes, what goes into writing them, and why supporting them is a nightmare.

Case study: Ren’py

When developing a piece of software, a good way to start is by imagining you’re an end user of the software (in this case, the person making a game using your game engine) and writing out how you would like to interface with it. In this case, I’m going to imagine I’m writing a cutscene with this engine and come up with a convenient format.

To begin with, I’m going to indicate one engine which, in my opinion, makes the authoring of cutscenes as easy as conceivably possible. That engine is Ren’py, a particularly well-designed domain-specific engine for making visual novels. Since most of visual novel authoring is writing dialog, it was made to be the simplest possible task.

Taken from the Ren’py tutorial: 

label start:

    scene bg uni

    show sylvie smile



    s "Oh, hi, do we walk home together?"

    m "Yes..."

    "I said and my voice was already shaking."



    scene bg meadow

    with fade

    

    "We reached the meadows just outside our hometown."

    "Autumn was so beautiful here."

    "When we were children, we often played here."

    m "Hey... ummm..."



    show sylvie smile

    with dissolve

    

    "She turned to me and smiled."

    "I'll ask her..."

    m "Ummm... will you..."

    m "Will you be my artist for a visual novel?"

A line of dialog is represented by a line of code consisting of two strings: the name of the speaker and what they said. It’s easy to read and easy to write. Virtually no overhead (except for the quotes). I think that, in a perfect world, it could be simplified to something like Me: Yes… but we’ll cross that bridge when we come to it.

What makes this so good is that Ren’py was designed for a highly specific genre and its developer identified what the most common tasks would be, then made them as easy as possible. Since Awakening is such a story-based game, much of the content creation will be in writing dialog, so I want something as easy to use (if not easier) as this.

The waiting paradox

Let’s break down exactly what’s happening here:

1) Show a background image
2) Show Sylvie’s smiling portrait
3) Have Sylvie say a line of dialog
4) Wait for the user to advance to the next line of dialog)
5) Have the protagonist say a line of dialog
6) (Wait for input)
7) Fade out the current background image
8) (Wait for fade out to complete)
9) Fade in new background image
10) (Wait for fade in to complete)
11) Show a line of narration

Seems fairly straightforward and easy to implement. What’s so tough about this? If you’re a programmer, you probably saw the problem right off the bat.

What exactly do we mean by “waiting?”

Let’s say we’re on step 4. A line of dialog has just been displayed and we’re waiting on the user to push a key to advance. How exactly do you implement that?

A first attempt might look something like this: 

while(ActionButton.NotPressed)

{

    DoNothing();

}

AdvanceToNextLineOfDialog();


This while loop will keep on spinning, doing nothing, until it detects that the action button has been pressed, after which point the loop will break and it’ll go on.

The problem with this approach is that while you’re waiting, your entire game is blocked, waiting on the loop to finish. You can’t do anything else. Background processes such as music aren’t updating. The UI isn’t updating properly. Depending on your graphics framework, it might stop drawing properly. This is called busy waiting.

So, let’s try another approach. Instead, let’s go into the game’s main update loop and put the wait there: 

function Update()

{

    if(WaitingForDialogToAdvance and ActionButton.Pressed)

    {

        AdvanceToNextLineOfDialog();

    }

UpdateRestOfGame();

}


This approach requires you to keep track of when you’re waiting for the dialog to advance (probably with a true/false flag) and to put a check against it at the start of your update loop.

Good news: It works!

For a lot of games, this approach works fine. The problem arises when there turn out there are multiple things you’re waiting on. Let’s say, in addition to waiting for the action button to be pressed to advance dialog, you also wanted to play a different song when the current one ends: 

function Update()

{

    if(WaitingForDialogToAdvance and ActionButton.Pressed)

    {

        AdvanceToNextLineOfDialog();

    }

    if(CurrentSong.IsFinished)

    {

    PlayNextSong();

    }

    UpdateRestOfGame();

}


Now let’s say you wanted to have animations, or some other gradual visual effect. For each one of these, you need a variable and a new condition in your update loop. This is annoying but manageable. The real problem is that, while you weren’t looking, your code has become a monster: 

function ShowDialog()

{

    ShowDialogContents();

    WaitingForDialogToAdvance = true;

}


This is pretty much what your function to show dialog looks like now. What’s the problem here? It makes sense, right?

The problem is that you’ve broken your function up into two functions (pre-waiting and post-waiting) and it’s not clear from reading one of them how they’re supposed to behave together. You’ve entered callback hell, a dark place where all your functions are split into two, threaded together by a nightmarish web of conditional checks and function forwarding. Here, nothing is as it seems and following the logic of your game is nigh impossible.

If you can’t wait inside your functions and you can’t wait outside of them, what are you supposed to do? How do you avoid busy waiting without falling into callback hell?

The answer: It depends.

Asynchrony angst

The solution to this problem depends on what programming language you’re using. “But wait!” you say. “You haven’t said what programming language you’re using yet!” And indeed I haven’t. At this point, we’re still in the design phase of the engine. This is all part of the exploration of the design requirements. Now, we’re finally at the stage where our design requirements are going to start making some decisions for us.

Let’s look at some possible solutions to the waiting paradox.

Ruby: Fibers

Fibers are a form of lightweight threads which are useful for asynchronous tasks. In this case, it would look like: 

def show_dialog

    show_dialog_contents

    wait_fiber = Fiber.new do

        wait_for_input

    end

    wait_fiber.resume

    show_next_dialog

end



def wait_for_input

    until action_button.pressed

        do_nothing

    end

    Fiber.yield

end


It’s a bit of a simplified example, but the idea is sound. There’s a little bit of a learning curve, but this solves the problem neatly. The whole of the show dialog functionality is contained within the show dialog function, which keeps the code easy to follow and maintain.

Lua: Coroutines

Very similar to Ruby’s fibers in terms of usage, just in Lua instead of Ruby.

C#: Async & Await

A relatively recent development, the async/await feature of C# 5.0 takes the cake for one of my favorite new language features. 

async void ShowDialog()

{

    ShowDialogContents();

    await WaitForInput();

    ShowNextDialog();

}


Simple and elegant. All you do is mark a function as async and then await it (aside: The actual implementation of WaitForInput() here is a little hairy, but I won’t sweat the details for now).

Design requirements revisited

So, we’ve got three possible ways to handle the problem of how to implement asynchronous commands in cutscenes. The choice depends on what language we’re using. So, now we have to choose what programming language we’re going to use. To narrow it down further, let’s revisit our list of design requirements.

The other bottleneck requirement is cross-platform deployment. Let’s look at how Ruby, Lua, and C# shape up in these regards:

-Ruby: Limited or no support for games on mobile
-Lua: Available on most platforms but none (yet) support Windows 8 apps
-C#: Available on everything

Lua has always been an agile language and quick to appear on other platforms. The lack of current Windows 8 app support doesn’t concern me as much as the fact that most of the cross-platform game frameworks using it are either too new or just flat-out suck. I tried out Moai several times, but the documentation is abysmal.

Although by default only available on Microsoft platforms, C# is also available on Android and iOS via Mono and has a very powerful framework for it called Monogame. And this is purely subjective, but I would much prefer to build a game engine in a statically typed language for the ease of debugging and architecting.

For that reason, C# was chosen as the language of choice for Metis, which will sit atop the Monogame framework.

The next part will dive deeper into the logistics of cutscene implementation with regards to scripting, and how I both had my cake and ate it, too.

Game Design

The Construction of Metis Part 1: Design Requirements

Time for my first technical blog post in a long time. This is the first in what’s intended to be a series about the design and construction of Metis, the 2D game engine I’m developing to make Vacant Sky: Awakening. I hope it’ll be interesting to fans of the series as a behind the scenes look at the game as well as educational to people who want to know the process of developing a game engine.

Keeping these two audiences in mind, this blog series is going to feature both high level explanations for the non-technically-minded as well as some in-depth stuff (maybe even code!) for the programmers out there.

Getting started

By far the most common first question people ask when building their first game engine is “where do I start?” A good starting point is to look at what exactly a game engine is. Wikipedia says:

author=Wikipedia
A game engine is a system designed for the creation and development of video games. The leading game engines provide a software framework that developers use to create games for video game consoles and personal computers. The core functionality typically provided by a game engine includes a rendering engine (“renderer”) for 2D or 3D graphics, a physics engine or collision detection (and collision response), sound, scripting, animation, artificial intelligence, networking, streaming, memory management, threading, localization support, and a scene graph. The process of game development is often economized, in large part, by reusing/adapting the same game engine to create different games, or to make it easier to “port” games to multiple platforms.


That’s actually a better definition than I was expecting and it touches on just how complex game engines are. If you look through the list of game engines on Wikipedia, you’ll see that they fall into two types: general purpose and domain-specific.

General purpose game engines are generic in the sense that they’re designed to make any type of game. Unity3D, Flixel, and Game Maker are good examples of general purpose engines. They provide lots of common functionality but aren’t geared toward any one specific type of game.

Domain-specific game engines are specialized toward developing certain kinds of games. The most well-known example is probably RPG Maker, which is pretty self-explanatory. There’s also Adventure Game Studio, Unreal, and Ren’py. Each of them have an intended genre in mind and provide highly specific feature sets to facilitate the development of that genre. Typically, working outside the intended genre in a domain-specific engine is very difficult (anyone who has tried making an action game in RM knows what I mean).

The first question to ask is what kind of engine do I want to make. Intuitively, you might think that a general purpose game engine is always better because it’s more flexible, and you might be right if my goal was to make a game engine. However, it’s very important in developing software not to lose sight of what your actual goal is. My end goal is to develop a specific game, not to develop an engine. The game engine is a means to an end. Never lose sight of that. A lot of beginning game programmers want to make a game but lose sight of what they were originally trying to accomplish as soon as they start programming it. Always keep in mind whether you’re trying to make a game or an engine.

In my case, the reason I’m developing an engine at all is because I tend to make games within a specific genre (visual novels and RPGs) and I can see myself needing certain functionality in future games. With that in mind, the goal is to make developing these games as easy and pain-free as possible. That’s why I’m choosing to make a domain-specific engine.

Now that I’ve decided that I want to make a domain-specific game engine, the next question to ask is what features do I want it to provide.

Design requirements

What do I need this engine to be able to do? Well, let’s look at common tasks that I’ll need to complete in making an RPG:

-Saving and loading game state
-Displaying dialog
-Writing and reading map data
-Writing and reading battle data
-Authoring and running enemy AI
-Showing various menus
-Writing cutscenes

Most of those are pretty straightforward, except for the last one, which I’ll come back to in a moment. Since these are the most common tasks I’ll be performing in the development of Awakening, I want to make these as easy as possible.

In addition, let’s look at what other requirements I have for my game:

-Cross-platform (PC and mobile)
-Updating and downloading additional content

Now that we know the requirements that this engine must fulfill, it’s time to look at them and see what they tell us about what direction the engine should take. Fortunately, most of these requirements are fairly straightforward and can be accomplished in almost any engine. The two most restricting requirements are cross-platform portability and cutscene authoring. In fact, the need to fulfill both of these requirements is one of the biggest challenges in developing this engine.

Since the next topic is quite complex, I think I’m going to end this post here. I know it wasn’t particularly exciting, but the next post will touch on a topic that will hopefully be of more interest: authoring cutscenes.

Miscellaneous

Back on RMN!

After a brief disappearance, Awakening is back on RMN due to the rule change. I'm in the process of updating the profile and images to reflect the new direction of the game. Look forward to some cool blog posts in the near future.

Miscellaneous

HEROBREAK

Although completely unrelated to Vacant Sky, you guys should check out Herobreak, a new suggestion-based webcomic done by Kate Holden, the character designer for Vacant Sky: Awakening.



Check it out here: http://www.herobreak.com/?p=41

Announcement

Here we go!

I've been itching to announce Awakening for a while, but we decided it would be more fun to get everything polished up and ready to present before going public.

What Awakening is not:
* About Auria
* Volume 2
* Divided into episodes

What Awakening is:
* About the founder of the Virad
* A prequel
* Dapper

Look forward to more updates in the future!
Pages: first prev 1234 last