Archives for category: Development

Short update!  Got buttons working.  What I ended up doing was creating a Button class, and instead of putting all the graphics stuff in there, I put only the behaviour, and put the graphics in a derived PanelButton class (so-called because it renders its frame using a panel).  This means I’ll be able to hook into Label regions and make them function exactly like buttons if I want to!  Very handy for things like hyperlinks!  🙂

I am likely going to rename what are currently called “listeners” into “parents”, because that’s functionally how I’m using them.  I’m even using them for determining absolute widget positioning.  Put that on the todo list!  Anywho, the way the parent knows that a button was clicked is because its onEvent(source, event) method gets called.  Source will be the widget that triggered the event (potentially overridden on its travel up the hierarchy), and event is more information.  If you click a region in a Label, you might get something like onEvent(Label@reference , “regionName”).

Heck, I suppose in this manner, you could construct a full menu system using only a single label…

“[:createCampaign|Create Campaign]\n[:quit|Quit Game]”

Hmm, most interesting.  🙂

To anyone interested, the basic algorithm I’ve used to format aui’s labels is visible here, under the July 29, 2011 section.

The results are that the string:

"This is an example of a [white|label] which makes use of a few things:\n\n-[special:newlineLink|Newlines]\n-[special:tagLink|Tags]\n-[special|Regions] (though you can't see them)\n-Generally a bunch of text!"

Renders like this:

The basic premise is that you add global ‘styles’, which are associated with tags (like “white” and “special” above).  You specify a ‘region’ when putting in one of these tags, which associates all the words in that region.  Later, this will be useful for adding things like hyperlinks and tooltips.  If you want to insert a region without using a style, you can do something “[:like|this]” (where “this” is in the “like” region, but uses the default style for the label).

Since the heights and widths of all the chunks of text are dynamically positioned, it should be pretty straightforward later to add things like embedded icons, if I were so inclined.  Neat!

This is extremely not how you’re supposed to make AngelCode fonts.

Step 1: Make font PNG.

Step 2: Hand-author ‘exported’ AngelCode .fnt file.

Step 3: Import into game using pre-existing Slick functionality.

EDIT: *an hour or two later*

Also ill-advised is getting preoccupied with getting through one’s task list.

…that said, both word wrap and horizontal/vertical alignment options work!

It may not look like much at a glance, but the hex-button-thinger that’s rendering on top of the hex grid is a NinePatch-style panel.  It’s non-interactive, but I’ve added a few styles that will essentially be used to implement all the panels and buttons in Tako’s current mocks.  The actual source graphics look like this:


I’m developing an extremely simple UI system, as I mentioned in my previous post, which I’m calling “aui”, for “Apocriva’s UI”.  I sometimes forget how much I enjoy writing UI systems.  I could likely share aui if there was any appetite for it later.

It’s not until just now, when I’ve been sitting here for a couple days wanting to work on Tako but not actually doing it, that I’ve realized that I’m having a ‘low’ with Tako.  Any project I’ve worked on at home has typically gone through cycles of highs and lows — times when I work diligently all day and night, and times when things are so daunting that I think about them all the time but don’t actually do any work.  My experience has been that if I push through the lows, I get quickly back into things.  It’s just pushing through the lows that I’m not terribly good at.

With that in mind, I’m going to switch tracks from doing mocks to doing something I typically totally dig: GUI!

User Interface Solution?

I’m sure there’s a custom library out there I can use as a UI solution.  I’m also sure that it would be a pain to implement, and it would be bloated with features that I don’t want.  Seeing as how I traditionally really like writing UI solutions, I figure the best bet for Tako is to do just that.  I should have enough mocks at the moment to at least start planning the UI solution.

Things I want for the Tako UI solution:

  • Normal/Disabled/Hover/Active states for PNG-sourced graphical buttons.
  • Simplicity of authoring the system, and UI elements within the system.
  • ‘NinePatch’-style non-interactive panels.
  • Tooltips.
  • Complex formatted text rendering.  Word wrap, color tags, tooltip/link embedding.  I plan on potentially using this UI system for other projects, so having robust text rendering would be great.
  • UI state stack.  Will need something of this sort, since you can theoretically click through a bunch of Mantle links.
  • Simple toolbox of widgets.
    • Image.
    • Button.
    • Scroll bar.
  • Resolution independence.  Not by scaling everything up, mind you…  Must be able to anchor panels to other panels or to the edges/center of the screen.

Things I do not want for the Tako UI solution:

  • Draggable/resizable windows.  The temptation is always to make really beefy windows as the base class for everything else, but I really don’t want that.  Simplicity.
  • Complex data file parsing.  I’m perfectly fine with all widgets being hardcoded, if it means that it’s faster to develop.  A proper data file loading system can always be added later.
  • Text entry fields.  I don’t think there’s anywhere in the design at the moment that calls for custom text entry.  Even avatar names are supposed to be randomly generated.
  • Complex widget interactions.  Only one widget is going to support dragging natively (the scrollbar).  There shouldn’t be lots of weird parent-child “yes I handled this event, no I didn’t handle that event” stuff, because there really shouldn’t be overlapping UI elements, thanks to there not being ‘windows’.

Well, that’s enough of a starting point, I guess.  Maybe I’ll take the time to do a more fully fleshed-out feature list on the UI system…  including a task breakdown, outside of the current breakdown for Tako-Gimel.  Jolly good!

I confess myself distracted over the past little while by a few things like Minecraft and World of Warcraft.  🙂  If/when I get my nuclear power plant and mining operation set up in Minecraft, maybe I’ll do a video tour of it.


First draft of the Mantle Information popup I was talking about in my last post.

This popup could conceivably be used for Agent displays as well.  I imagine having the Agent’s icon shown in the upper-left, with smaller icons to the right for their Mantles (race, class, artifact).  Oh, and I forgot to put in a close/back button, so imagine like there’s one there!

I’ll likely be able to mostly use the same screen layout as the Codex for the Create Avatar screen.  All I’ll really have to do is remove the buttons on the side, and change the title.

For boh screens, however, I’m thinking that I’ll need a details popup or panel of some sort.  Even something as simple as a modal dialog that pops up when you click one of the Mantles.  For Tako, simple is almost always going to be better anyway.  🙂  The dialog shows the Mantle details, like its associated Affinities, any other Mantle restrictions (the exclusivity of dragon-classes to dragon races, for example), as well as its flavor text.

It occurs to me that this same popup will be usable ingame to show Mantle details there, like if you were to click on the race/class of an Agent, or on an Artifact.  I think it would be beneficial to show the player as much information as possible — with the exception of some rare Mantles that have yet to be encountered ingame at all, I see no reason to hide any information about any Mantles.  By showing the information instead of hiding it, it gives the player something to get excited about and work towards.

Maybe, on that note, it makes sense to show the requirements for unlocking various Mantles within the Codex and ingame, in the Mantle info popup.  As soon as the player encounters a Mantle, they should see how that Mantle is unlocked.

In any event, it’s hot and I don’t have much of a head for development tonight.  Just wanted to get those thoughts down.  🙂

Trying to get some work done on some Tako mocks while I’ve got Caeli asleep in the Ergo!

Main Menu

I’m not sure about the little frill thing on the righthand side of the highlighted button.  I imagine it as animating across the button, but I’m not sold on it.  I will likely just not have that at all…  But I’ll have to wait and see, once things are ingame.

The button size here is 128×16.  The idea is to scale up the UI elements to 2x or 3x, and scale the gameplay window to fit the screen as needed.  It’s important to have the UI readable, and it was my experience with Unagi (another project I have on the backburner) that scaling up the UI such that the 240-pixel-tall viewport fit the screen rendered the 5-point font I was using really hard to read.

I’m also avoiding drop shadows for the time being for the same reason — they take away from the font’s legibility.

Anywho, I picture the background for the main menu being a randomly-generated world scrolling slowly.  With any luck, it’ll give the screen some flare without going too overboard.

Hmm…  Come to think of it, I’m doing these mocks at 240px.  I should be doing them bigger, if I’m doing the whole 200% scale thing rather than scale-to-fit.  I’ll size the mocks to a 1440×900 screen, which means they should be 720×450.  And actually, I think I’ll go for 300% instead of 200%, which makes the screens 480×300.  Also, to account for 4:3 monitors, all of the UI layouts should fit within 400px across.


Here’s the first-pass at the Codex screen, with both a light- and dark-colored panel.

I want some way of signifying rarity throughout the game for various things like Races, Classes and Artifacts.  I’m not totally sold on doing it like this…  I’m thinking perhaps something more like Spiral Knights’ star rating system, where everything gets a rarity rating from one to five stars.  Since the stuff that’s available in a campaign is randomized, but based on the ‘power level’ of the player’s avatar (ie: allow the player to unlock more exciting stuff by playing with more exciting stuff), I need a way to do so that’s clear, but not overly cumbersome in terms of UI.  Colored rarity is fine at a glance for someone who’s used to the system, but for those who aren’t it’s a pretty big mystery.  Star-ratings, on the other hand, are pretty straightforward no matter what.

Very very quick sketch…

I’m finding it extremely useful doing these mocks, though.  I reckon I’ll probably revisit my task sheet once I get these done, and make sure I’ve captured everything I need to capture.  Scroll bars, for example…  I don’t think they’re on there.  🙂

I work in the game industry for a living, and the graphic art tool we most often use is, probably not surprisingly, Photoshop.  So when I’m at work and I mention that I do my art using the GIMP, I get a range of looks from shock to disgust.  Well, I don’t know about you, but I don’t have a strong desire to drop $700 on a piece of software just to make a little bit of art here and there.  🙂

Using the Tools

Most of what I do is pixel art.  There are a couple settings and tools that make this pretty painless.

Drawing is done primarily using the Pencil Tool (hotkey being N).  This gives me a hard-edged brush, which prevents artifacts from appearing around the edges of transparent objects.  Knowing exactly what colors your pixels are is important less from a palette standpoint with modern hardware (though it still can be a consideration if you’re color-keying your transparency), and more from a stylistic standpoint.  The more distinct colors you have in a bitmap, the muddier it seems to get.  I like to try and at least pretend like I’m working within the context of a ~16 color palette, even if I’m not.  Again, more of a style thing.

Sometimes I’ll blend colors together by turning down the opacity of the brush and painting with it, but more often than not I use the color picker directly.  I normally lay a few colors out like a palette off to the side of where I’m working.

If I make large-scale changes to colors, I do it using the Select by Color Tool (hotkey Shift-O), and either paint over the canvas using a large Pencil brush, or using the Bucket Fill Tool (hotkey Shift-B).  With most of these tools, it’s vitally important to ensure that Antialiasing is unchecked, and Threshold is set to zero.

One of the other most important tools I use is the Rectangle Select Tool (hotkey R).  The rectangle selection area has handles on its outside to adjust its extents.  Really helpful when you’re selecting areas you want to be perfect sizes like 32×32 or 16×16 or what-have-you.  Though generally speaking for those cases, I use the fixed-size property available to make the selection box the size I want.

Suppose it’s worth mentioning that the Eraser Tool (hotkey Shift-E) is also vitally important, but only as long as Hard Edge is set.  When you’re zoomed in, you can tell that Hard Edge isn’t set because the outline won’t snap to the edges of pixels.

The eraser is so important because I work using a lot of layers.  I generally have a transparent layer, a backdrop layer (with a neutral color that’s along the lines of the color that my sprites/tiles would be showing up against), and then as many layers as I need while I’m working.

Making Art Into Assets

I save all of my working files as the GIMP’s native .xcf file format so that I don’t lose any information, but it’s not a format that’s useful to most practical purposes.  The ‘export pipeline’ I use from GIMP is as simple as:

  1. Hide ‘work’ layers.  (Backdrop, palette, etc)
  2. “Save As Copy…” to wherever my build pipeline looks for source data.

Easy peasy!

I went and picked up an Android tablet!  While it’s mostly for the ability to read eBooks in bed, I figure there’s also the very real possibility of actually doing some hobby development work on the platform!

So we’ll see, I suppose.  In any event, I’m really loving the device.  🙂

UI/Gameplay Considerations

While I’m here, what kinds of changes would be required in terms of UI in the porting of a concept like Tako to a tablet?  It wouldn’t hurt to think about it now, rather than wait until after the project is otherwise complete.

Requiring the use of a right-click is definitely out, as is the concept of hovering the mouse cursor.  Might do alright having a double-tap system of some sort for things — the first tap being like a hover (when appropriate), and the second being an actual selection…  In Tako gameplay terms, I dont’t think that makes sense at all.  Unit/location names can probably be shown most of the time…?  The tooltippy stuff like unit details, etc, all shows up in the sidebar anyway.

Oh, theres’s an interesting consideration — portrait/landscape.  Tako doesn’t really make sense atm if it’s played portrait, but there’s ultimately no reason I couldn’t come up with a satisfactory design that can rotate.

Anyway, enough babbling for now.  🙂