Encounter Editor: UI Almost Ready

I had a pretty good run today, finishing working UI for nearly all data fields on encounters, and the arrows connecting them. Here's how the editor's looking now:

IMAGE(http://www.bluebottlegames.com/img/screenshots/screenshot-2012-11-14.png) Editable encounter data!

First of all, I switched the background color to black. No technical reason, really. Just easier on the eyes. (especially now that daylight is getting scarce!)

The majority of today's work is visible in the editable data fields of each encounter (gray box) and response (colored arrow). Yesterday's editable text fields and buttons are now hooked up to each node, and I can change values as needed.

However, getting them all hooked up started to strain framerate. As you can see, there are several dozen fields and labels in each encounter, and at least half a dozen per response arrow. With nearly 1000 encounter nodes in the game, and several thousand arrows, the editor started to slow down rendering all those fields. Even as a C++ native app.

So I guess Flash wasn't entirely to blame. Haxe NME is still faster (the Flash version wouldn't load nor render), but it still struggles under the weight of 5-digit text-field-counts. I guess that's a reasonable limitation :)

While I could've just left it as-is, with a slower framerate (~10fps), the sluggishness of the old editor was causing me to avoid it. So I decided to hack some optimizations in there, to get the framerate back up. Those optimizations are to basically hide any data fields I don't need, and just reveal them when I need them.

As a result, you can see that most encounters and responses have no data fields visible (except the encounter image, for visual reference). When I click on any of them, the fields appear, and let me edit them. I can click a button to hide them again, if desired.

With this in place, the editor is back up to a ~30fps framerate, which is much better for navigating the overall map of nodes.

Also, as part of the UI work, I cobbled together a checkbox-like button. They're the pinkish colored boxes in the detailed encounters. They turn greenish when "on," and red again when "off."

By the end of the day, I think I got the editor to a point where pretty much everything is loading from the data, and editable. Now, the only thing left is to make sure it's saving the data correctly. I'll be looking into that tomorrow.

And once that's done, I should be able to resume work on new encounters! Then, it'll be a case of switching on the creative part of my brain, and figuring out what to do next. Always a bit daunting, but still necessary!

Hope everyone has a good night, and see you tomorrow!

Comments

DodoCommando's picture
DodoCommando

Maybe you draw everything to one big bitmap, then when you edit a node, make the node become editable(op top). After you're done editing the node, redraw the bitmap. You probably also should redraw after each zoom action.
Or you can just use .cacheAsBitmap on your nodes/ overall container(don't know if this actually improves performance)?

30fps is probably fine though.

dcfedor's picture
dcfedor

The one big bitmap might work. However, the overall collection of nodes is very big, maybe 5000x5000 or 10000x10000 pixels right now. So generating a big bitmap for all nodes might become prohibitive as nodes are added and spread out. I could also generate bitmaps per-object, but I decided that the arrows would be very inefficient as bitmaps, since they are long and narrow, and often rotated.

So far, hiding data fields seems to work, and it was pretty easy to do. I'm usually only working on a narrow range of nodes at any time, and their physical layout is easy to remember (easier than reading them).

Thanks for the tips, though! If the fps starts to decrease again, I might have to start slinging bitmaps, as you say!

Dan Fedor - Founder, Blue Bottle Games

Valek's picture
Valek

I love hearing about this kind of backend stuff! I appreciate you taking the time to post details about it.

I don't quite understand what the encounter nodes are. Wouldn't you just have a location or an action that has the chance of an encounter, and then randomly check to see if an encounter occurs?

In the game, the mouse cursor used to be really slow and lagged badly. When you implemented the hardware cursor, it became MUCH better, but also the game felt a lot snappier. Have you tried implementing the hardware cursor with your editor, to see if you can squeeze out any more FPS?

You're doing a great job! Keep it up!

dcfedor's picture
dcfedor

Cool, glad to hear you're enjoying it! I like sharing my work with folks, since I remember what it was like to follow a game's progress when I was younger. I used to wish I had a peek behind the curtains, to see what devs struggled with each day.

Plus, writing these posts is a good way to keep track of what I'm doing. Like a journal.

To answer your question, the encounter nodes each represent one page of an encounter. So a single node includes:
picture (shown to the player. e.g. picture of the cryo facility)
title (pop-up text when the player rolls over an encounter choice. e.g. "prepare to fight")
description (the text for the current page of the encounter. e.g. "you fight the dogman...")
conditions (damage, sickness, plot variables, etc.)
treasure (both given to and removed from player)
spawned creatures
teleport player
etc.

So each gray box is a collection of info either shown to the player, or applied to the player's character when that page appears. The colored arrows just represent where you can go from each gray box.

The hardware cursor was actually something specific to Flash. It just speeds up the cursor, but the game still runs slow. It looks faster, because there's less cursor lag, but the game still has a lower fps.

This editor is done in Haxe NME, which creates a windows application. So the cursor is already hardware. It's actually pretty fast right now, as long as I'm only showing a few dozen editable encounters. It's just when I try to draw all of them at once that it gets slow. Since there's no reason I'll ever need to edit thousands of nodes in one sitting, I just hide all of them, and unhide as needed.

At least, that's the thought. We'll see how it works out in practice!

Dan Fedor - Founder, Blue Bottle Games

Valek's picture
Valek

Thanks for the reply, Dan.

It's funny that you say writing these posts is like a journal, because, as I was reading the last couple of posts, I was thinking that it seemed like the journal of some explorer, detailing his travels. :)

Your explanation makes sense, but my next question (and probably last question, for the time being, because I don't want to take up too much of your time) is, why not have the encounters generated dynamically, rather than create many, many encounters by hand? For instance, if the player scavenges, you look at the tile he is in, and see what the base chance of an encounter is. Then you add in modifiers to the percentage, like using a crowbar or not.

If the player does encounter an enemy, then you would call a fight function (which you could pass parameters to, like the player (which would have all his skills, conditions, etc.) and the enemy. The fight function would handle the fight, and would take care of all the descriptions ("You kick the dogman in the head.") and update conditions (such as "bleeding").

After the fight was over, a treasure function could be called, which would generate dropped items.

Doing it like that seems like it would be a lot better than creating 1,000 nodes by hand. Which is why I'm guessing that I'm missing something. :)

About Haxe NME, I believe you did mention that it compiled applications, and I just forgot. :)

If you're getting around 30FPS, it sounds like what you've got will work for a while. It's definitely worth putting the work in now, to make working with the nodes much less of a headache in the future.

dcfedor's picture
dcfedor

The system actually works pretty close to what you describe. Scavenging and combat only make up about 10-20 nodes in the overall map. They are templates that get dynamically altered based on the situation, with outcomes based on probability. So you're right, it's much better to let the computer write all those combinations as-needed. That would easily add 1000s more encounter nodes if I did it by hand.

The other 800 encounter nodes are actual, hand-crafted bits of story that Cameron and I wrote. When you start the game, the text about waking up on the floor of the cryo lab is one of these nodes. If you choose to use the "hiding" skill, it shows a new panel of text which talks about how you hid from the dogman. That's a separate node.

There are 800 of these in the game so far. Most of them (~500) are short encounters, where there's an intro node and 2-5 outcome nodes, based on player choice. They randomly appear on the map, but are rare. The other ~300 nodes are gigantic networks of nodes, like the cryo facility, Hatter, and the DMC intro. There are also some one-off nodes like the scavenging tutorial, first nightfall and "glow in the east," etc.

The big ones can have 20-50 nodes each, depending on the encounter's length and number of player choices/branches. And there's maybe 5-6 of those so far.

The screenshot above is actually a piece of the opening cryo encounter. It think it's actually the medic option, where you choose which cryo tube to dump (notice the node on the lower left, with the green and pink arrows branching from it?). The blue arrow coming into it is from the node where you start the game waking up.

So yeah, lots of nodes in the game :)

Dan Fedor - Founder, Blue Bottle Games

Valek's picture
Valek

Ahh, I see! That clears everything up! :)

I really appreciate you taking the time to explain this. I wish more developers explained what they're working on, like you do. Very interesting.

I'll let you get back to work, and I'll get back to playing the game! :)