NGUI: Tabbing between input fields

NGUI: Tabbing between input fields

One of the most important features of a multiplayer game is the ability for a user to log in, especially if you want to be able to save their progress. Maybe not always, but for the game I’m currently working on it’s pretty important. Everything was going along quite swimmingly. The API endpoints were working perfectly. I’d created a basic login UI which took the data and passed it to the API. Basically, it was functional, and that’s pretty important.

For the current stage of development I was happy with how it looked. But there was one issue that was really bugging me. The user experience with the form was terrible.
To change fields you had to manually click into the next field. With my day job being a web developer, this really frustrated me. I should be able to tab into the next field, and shit+tab into the previous field.

My limited Googling of the issue took me to a NGUI forum post where the only solution was to script the tab functionality. Someone had provided a script, which collected the child inputs then did event dispatching and listening, which is nice and fancy, but didn’t really suit my use case.

So I wrote a simple script that does exactly what I needed.

The code itself is very simple. It first checks to make sure that the input the script is attached to has focus (or isSelected as NGUI calls it). The it checks the input. It also checks to see if the target input is null to avoid errors, because there are times when you may not have a next or previous input to tab to.

The script has two public UIInput variables:

So, all you need to do is drag the next and previous game objects into the nextInput or previousInput fields in the inspector.

Currently, this doesn’t take into account buttons or other field types. But for simple forms this should be more than enough.
You can download the entire script on Github(

Posted by Chris in Development, Game Development, Unity3D, UX, 0 comments
Time Travel: Games From 1999 – 2002

Time Travel: Games From 1999 – 2002

Recently, I stumbled upon an old CD-R while going through some boxes.  It was simply labeled “Backup”.  Curiosity set in, so I put the CD-R in the DVD drive of my laptop, and waited with bated breath to see what treasures this ancient technology held.  As it turns out, it was the keeper of a whole bunch of source code for old DOS games that I had started between 1999 and 2002.  I thought these games were lost for ever, but alas, they have once again reared their ugly head to say “Oi, stop locking us away you bastard!”

So, I browsed through the folders, and most of it was accessible. There were a few zip files that where corrupt and I couldn’t extract, but for the most part everything was intact.  So, let’s take a look at what I was working with at the time.

  • Watcom C/C++ – This was a brilliant compiler and allowed you to create DOS games using DOS/4GW.  DOS/4GW allowed the programs to use more than the 640KB memory limit imposed by DOS.
  • WGT 5 – The oddly named WordUp Graphics Toolkit created by Ergeter Software.  This was an amazing graphics library that included sprite editors, level creators, and heaps of awesome graphics routines.  This meant I no longer had to write assembler code to change the screen resolution.
  • Edit – The basic MS-DOS text editor.  No IDE for me…. which was not a good thing (I used to write HTML in Notepad as well before there were decent IDEs for web development).

Graphically, these games were pretty terrible.  I had no experience in UI/UX at the time, and, as you can see, my artistic skill is pretty much non-existent.


I used to have a copy of Xara 3D, which I used liberally for any heading text.  The result was not fantastic.

I haven’t even touched on the code.  For the most part, the code was terrible.  There are some good IO routines in there for saving and loading, but if any of that code was to hit a code review it would be swiftly rejected.  The format is all over the place, variable naming is horrendous, the amount of duplicate code is amazing.  But overall, I’m kind of proud of it, because I had taught myself C, and I was able to make these games with few errors or memory leaks.  No stray pointers.  And these were written before I had started professionally in IT, so I was a very naive coder.


Not all of it was too terrible (in fact most of it is better than a lot of the crap on Steam Greenlight).  For instance, I was quite impressed by some of the visuals I did on Zanath: The Attack.

Zanath: The Attack was intended to be a RPG similar to The Legend of Zelda and the early Final Fantasy games.  It incorporated an overview map which had random enemy encounters that would trigger a turn based battle system.  From the map you could visit different locations and interact with the people there.  There was a castle level which had a boss fight.  I did quite a bit of work to it.  However, with the way I had written it, there is no way I could have made it as robust as I wanted.  Too much was hardcoded, and very quickly it would have become a nightmare to work with.

So, how do these games perform on todays modern machinery?
Generally, they run way too fast.  I’ve had no problems running them in DosBox, but due to the way the games were coded they are unplayably fast.  With the exception of Ganthraw’s Revenge, Zanath: The Attack, and Midget Championship where I had implented VSync and framerate limiting.

Graphically all the games performed the same as I remember them, with the exception of Ganthraw’s Revenge where the sprites don’t show up, therefore making it unplayable.

It was fun going through the old projects and code, and it really made me appreciate how far I have come as a developer, and how much I’ve learned.  There’s a part of me that wants to go through the old code and fix it up, but I think it would be best to leave it in the past where it belongs.

Posted by Chris in Development, Game Development, Pixel Art, 0 comments