Archives for category: Tako

Build Label: Gimel 7-August-2011 02:33

Random name generation!

Simple sort of thing.  There are four segments to each name, each of which is randomly selected from an associated data file, which is just a list of words.  Races can specify a ‘name group’ in the database, which will dictate which set of namefiles to use for name generation.

Build Label: Gimel 7-August-2011 02:14

All that’s left before getting dumped into the actual game is setting up a random name generator.

In the meantime, here’s a big wtf that has gone on today…

Sometimes (and I may have mentioned this in previous posts), the game ceases to render properly.  Everything freezes.  Everything continues to update properly in the background, but nothing renders.  I’ve been fighting with this all day today, trying to optimize my rendering, since I figured I was hitting some threshold of something that was causing things to lock.

…except if I proceeded to render just a little bit more, the problem went away.

Turns out that there’s a problem within nSwapBuffers(), a native method deep within LWJGL.  I don’t know what’s in there that might be stalling when there is a certain amount of data waiting to be flushed, but good lord the hack I’ve had to put in to keep things running smoothly is just gross.  What was happening was that things would be going fine, but then you’d trigger a tooltip, and suddenly everything would stop rendering.  Now, it will still stutter, but it corrects itself after a couple frames (each of which take ~1 second to render at that point).

In any event, it looks like I’ll soon be moving onto some actual gameplay, so things will hopefully end up getting much more interesting very soon!

Opinions may differ, but I consider Tako at the moment to be in a nicely playable state.  There is extremely little to it at the moment, but if all goes well, that will be changing fairly rapidly now that I have the foundation done.

With that in mind, if you find yourself itching to take a look at Tako in action, you can download the launcher and unzip it somewhere to your liking.  You can run launcher by double-clicking run.bat.  This will automatically update Tako to the latest published version and run it!

I generally have been publishing a new version when I make a blog post, but in the event that you’re interested in knowing more precisely when a build is published, I’ll be tweeting when I publish builds (@Apocriva).

If you run into any issues running anything at any time, don’t hesitate to drop me a line here, at my email, or via Twitter, Facebook or Google+.

Note to Mac/Linux users: you’re likely out of luck for the moment, sorry!  You’re on my todo list, though.  🙂

On a side note, I also got regions in labels hooked up such that I can turn them into hyperlinks, or show tooltips for them.

Mock:

Ingame:

Everything is data-driven!  I have to properly implement partial styles, though, or allow different stylesheets for different purposes, or something.  Text that’s grey on one color looks terrible on another!  In any event, it only took about three hours to add the functionality to allow popups and implement the Mantle Info popup.  That’s not too bad, I don’t think.  I didn’t end up blocked by anything too terrible.

I continue to be blown away by how like-the-mocks these screens are turning out.  We’ll see how things go with the Create Avatar screen, though, since that one technically doesn’t have a mock to work from.

Implemented the first pass of the View Codex screen.

Mock:

Ingame:

It’s not too bad!  Not data-driven yet, mind you.  That may or may not be the next step…  The milestone which I have slated to generate data doesn’t come for a while yet, but I suppose it would make sense to prepare screens like this for it, by having a small selection of races, classes, events, terrains, etc now.  Besides, according to my task sheet, it has been almost three months since I touched the mantle database, so it would be nice to do so again!

It is extremely rewarding seeing these screens come to life from the mocks.  Still shots don’t do them justice.

One of the big concessions to complexity I made was to allow aui to respond gracefully to different UI resolutions and scales.  It drives me nuts that a game like Terraria, for example, didn’t have a way to scale up the UI for the relatively large resolution of my monitor.

There is a member variable of the base TakoGame class which has a very interesting effect:

m_uiScale = 2

m_uiScale = 5

Fancy!

In other news, I added in some destroy-ish functionality, since I now transition between different screens.  I figure I might not be trying to be terribly nice to my garbage collector, but at the very least, I can unreference all the references I have when I would normally have deleted something.  Honestly, this is one of the reasons I favour Java for doing prototype/hobby game development.  I don’t worry about this kind of thing.

Next on my list: View Codex!  Lots of compound widgets to deal with, should be interesting.

Still having a bit of an issue with the scroll bar thumb slider not being initially anchored to the mouse correctly, but I made the call to say “it’s a bug!” and move on.  What I moved onto was the first real screen of Tako, the Main Menu!

Let’s compare it to the original mock:

Hmm.  Well, this is a good exercise, isn’t it?  The colors are wrong, and the text alignment on the buttons isn’t correct.  I reckon the left-aligned text on the buttons is better, but I’m not sure!

Another very short update.

Implemented tooltips!  (Imagine there’s a cursor in there — screen captures don’t capture the cursor.)

You may notice that the style tags from Label work just fine in tooltips.

A bit of technical detail on what I’m doing here…  The Widget class has a few static members and methods relating to tooltips.  Some members include:

  • A generic tooltip label-based widget.  This generic label is used for displaying tooltips such as the above, where all you want is some formatted text.  It’s up to the client to instantiate this widget, since there’s no way that aui will know things like what style to use, how wide to make it (to best suit the UI of the client) and stuff like that.  I could theoretically have that information passed in to some initialization method, but I like this for now.
  • A reference to the currently active tooltip widget.  This may or may not point at the generic label mentioned above.  A widget can provide its own custom widget as a tooltip, which will be handy for things like WoW-style equipment comparison tooltips, which are made up of a bunch of other widgets.
  • A reference to the control that called the tooltip.  During the tooltip updating process, this caller widget is polled to find out whether it still needs to be displaying a tooltip.  As long as this poll continues to return true, the tooltip will never be hidden.  (Note to future self: the fact that you have a memory leak due to controls sticking around forever is probably due to controls being deleted while they still have a tooltip active.)

It’s up to the client to call Widget.updateTooltip() and Widget.renderTooltip() in their main widget’s onUpdate() and onRender(), respectively.  This ensures that the tooltip exists within the input area — and renders in the same scale as — the main widget.

On a side note, I added a PanelLabel widget, which is effectively just a Label, but it will render a panel in the specified style behind the text.  Did this because it trivialized making the generic tooltip.  🙂

Next step: scrollbars!  After that, I should be able to dig into some Tako-specific screens.  Scrollbars are the first major compound widget I’ll be making, so here’s hoping that aui’s structure works out!

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!