Tropes VS Hellenica

In the past couple of months, I've been repeatedly frustrated by the implications that gaming isn't ready for a mature conversation about sexism.

That’s not true in my circle of gaming friends, it wasn't true for Volition, and it's not true for Dragonloft. To demonstrate this, we thought it would be a good idea to do a post about all the thought our team is putting into how we portray females in Hellenica.

Let's get to the first issue we face—finding female characters for the game. At this point I'm half-expecting cries of "PC police" or "social justice warrior", but it's nothing so grandiose. Rather, girls have always been there in our personal adventures, whether it was solving intractable problems at math camp, developing video games, or downing a raid boss in the Secret World. To not have any females of note in a setting just rings false to us, and we don't think we're the only ones.

This quickly came into conflict with our desire to found the game solidly in the milieu of ancient Greece. Even after all my research, I can only name two historical Greek women who were famous for something other than being a wife/mistress to a man. The naval commander Artemisia (who I'm told is featured in the latest 300 movie) and the poet Sappho. Tragically, neither of these characters worked for us. The battle for which Artemisia is famous happened a generation before our game takes place and is a building block for Greek/Persian relations in our setting, so any appearance by her would be jarringly anachronistic. As for Sappho, there may be a genius out there that can work a lesbian love poet into a JRPG narrative, but it wasn't something we wanted to try to tackle in our first game.

Moving on to mythical Greek characters, there’s a much wider set to choose from. Even discounting the gods, there’s Circe, Atalanta, Pandora, Medea, Electra, Ariadne, Helen, Arachne, etc. However, a lot of these characters have troubling sexist undertones. Atalanta’s footrace in particular is basically about a guy distracting a warrior woman with shinies to trick her into marrying him.

Of the above, Circe was the one that best fit our setting—a powerful enchantress with her own agenda that can alternatively serve as an obstacle or guide. And yes, we’re aware that in the Odyssey she functions as a sort of sexist “temptress” trope. And though there are elements of that characterization in our story, her arc is greatly expanded in Hellenica, including an act 3 confrontation where she --[REDACTED]--.

After all this, we’re still only at one(!) female character. So we needed to do more. Next post, I’ll talk about how we went about creating new female characters and making them consistent with the male-dominated world of ancient Greece.

This changes everything

Every once in a while we implement a change in the project that makes me wonder how I ever enjoyed any of the previous versions. The last couple weeks I've been using some cycles to get our characters animating, and now that Diona is running and jumping around our little worlds, I just can't go back to our older builds. It's SO good to see our characters come to life on the screen!

Here's a quick video of some of her animations in place.

This is the animation graph I'm using to control her:

As far as animation graphs go, it's fairly simple. You can think of each rectangle as a single animation (idling in place, running, or shooting her bow), while the white arrows between the rectangles represent possible transitions between those animations.

So, for example, the arrows connecting diona_run to diona_hop allow Diona to immediately perform a hop while she is running. But, since there are no arrows between diona_run and diona_attack_bow, she has to stop moving and return to the diona_idle state before she can attack.

The nature of our turn-based combat means we can get away with a fairly simple set of transitions, as opposed to say, a real-time shooter game. Here's one part of an animation tree (a specialized kind of graph) from a recent Battlefield game:

It's not unusual for a large AAA studio to have a couple of programmers and a dedicated animation team spend all of their time refining the animation tree of the protagonist character. Maybe for our next game. ;)

I also put together some quick footage I took running around one of our test levels. Take a look!

Now that everything is in place, it's fairly simple to plug in the movement animations for our other characters, and that means our game is quickly coming to life!

Stay tuned for more!

When Two’s a Crowd...

I've recently managed to outpace my proofreaders, so I switched off writing to work on something we’ve wanted to get to for a while, character portrait presentation.

We wanted to experiment with multiple speakers on each side to give the impression of the player's party participating in a discussion (or argument) as a group. First pass implementation of this was easy, but had a few glaring problems...

Even though Scylax is the one speaking, Nephele appears bigger and louder. (We had looked at our character designs next to each other before, but never overlapping, so this is the first time we were really made aware of discrepancies of height and body proportions.) Additionally, Scylax's wide-spreading coat ended up intruding on the dialogue text, even though that position had worked for other (narrower) characters.

To fix this, we're giving each character portrait its own set of presentation variables that track its size and position for each slot. So when Nephele's not speaking, she shrinks a little and backs up. And when Scylax is speaking, he doesn't scoot forward quite as far as other characters do. We also decided to dim characters in the background.

Which looks a lot better.

Also, as of right now we haven't really solved when we should put characters on the same side in a conversation. We just always do it with the party (even if there are no NPCs talking), which is serviceable, but probably not as good as it could be. We'll keep mulling over it, but if you have any ideas for when groups of characters should be displayed, or any examples of games that solve this problem well, we'd like to hear about it in the comments.

Level construction and keeping focus in the Unity editor

Up until now, creating the geometry for a level in Hellenica was controlled entirely through keyboard input. Here's what it looked like:

It's a cinch once you pick up the hotkeys, and now that I've been using it for a few months, constructing the geometry for a level is one of the quickest parts of the process.

Recently, we've been thinking about how to layer on Valery's art to make our environments more appealing. I decided it was going to be cumbersome and complicated to paint specific faces of the level blocks using keyboard hotkeys. The time had come to add mouse picking to the editor interface.

I immediately ran into issues dealing with Unity's default mouse picking behavior, though. Whenever you click on a GameObject in the scene view, Unity changes its focus to that new object! Generally, this is exactly what the user wants. In our case, however, painting tiles becomes very difficult when every click changes the user's selection!

After some internet research and experimentation on my own, I ended up with a solution that works well for us. It comes down to overriding Unity's GUI focus for the duration of the painting operation. Here's a quick sketch of how this is done:

 ...
else if (Event.current.isMouse)
{
process_mouse_input(Event.current);

// if we detect a left click while the mesh editor is selected,
//   do not allow Unity to change our selection. assume we're editing
//   until we release the left mouse button.
if (Event.current.type == EventType.MouseDown && Event.current.button == 0)
{
    // hotControl is a static variable that Unity uses to track the
    //  active GUI control
GUIUtility.hotControl = m_editor_control_id;
}
else if (GUIUtility.hotControl == m_editor_control_id &&
Event.current.type == EventType.MouseUp && Event.current.button == 0)
{
GUIUtility.hotControl = 0;
}
}
 ...

I begin overriding GUIUtility.hotControl on the MouseDown event and hang on to control until a corresponding MouseUp event to guarantee that the editor captures clicks as well as sustained drags.

m_editor_control_id is generated as follows:

m_editor_control_id = GUIUtility.GetControlID(this.GetHashCode(), FocusType.Passive);

As you may be able to tell, this solution isn't perfect. Any gizmos that end up in front of the level mesh will be unresponsive to mouse clicks so long as the mesh remains behind them, as the mesh editor is now all-consuming. (Muahaha.) But, it works well enough for us to get started painting levels.

Here's a quick gif of a paint job I did with some test tiles:

I have no doubt that this system will keep evolving as we go. If anyone out there has any ideas for improvement, let me know!

Welcome to Level 6

**This post contains vaguish spoilers**

This past week I've begun work on the sixth (of 8) levels of social hubs in Hellenica. This is taking us to the final stretch of the story, and setting up all the good dramatic twists/betrayals and deaths that mark the act 2-3 transition.

Social hub six is also probably going to be the last social hub the player makes story-shifting choice in. One reason is because the cumulative weight of all the previous choices is making writing scenes at this level more difficult. My current social hub in particular feels like it's 80% devoted to either tying together the various plot threads that could have lead to this point or setting up the various choices the player will have going forward.

A lot of the difficulty is the NPCs, which will follow their own paths through Hellenica mostly regardless of the players’ actions. Maybe you've bumped into them before and have some catching up to do. Or maybe you have no idea who they are and what they stand for, but they might be important for the way the plot’s about to turn. My current social hub features an intersection of 3 such NPCs, so getting the player up to speed without grinding the story's momentum to a halt is a significant challenge.

The second reason we’re doing away with branching for the rest of the game is to really commit to each of six endings. We never liked games where you could just reload a few minutes from the end, make a different choice, and then get a completely different ending. It frequently felt unearned, and the plot would often have to twist itself to justify how this one final decision was more important than any other decision you made the whole game.

The Hellenica approach is completely different, with your last storyline-affecting choice happening at the end of act 2. The whole climax and conclusion are a reflection of all the previously made choices. This will hopefully lead to better narrative flow to the conclusion, as well as making each ending feature enough callbacks to previous choices to make it a unique experience.