Growing a system – How I do code

This is the second attempt at writing a post on this subject. The first was largely focused around an 8-bit CPU emulator I had written, or am writing, depending on my mood at the time. I decided to start again in a more general way, but still using it for examples.

Writing  software is hard. When you begin, you have this idea, you might even have an idea how things might fit together. Generally those ideas are wrong. Don’t get me wrong, as I’m getting more experience, more and more of my up-front ideas are proving correct, but for all but the most trivial projects, you cannot realistically imagine all possible modules and interactions until you start coding. Continue reading Growing a system – How I do code

Mooltipass, libusb and paracetamol

As I’ve already said, I love my Mooltipass. It is a great device, but it is missing one major thing. Integration. So far it only works in the way it was designed, with Chrome. I have a bunch of usages that don’t have any web interface, so this is a little frustrating to me.

Towards the end of April, I dusted off my “Tiny Little” library template and started writing a native lib to communicate with the mooltipass. Today, I finally have it talking.

Continue reading Mooltipass, libusb and paracetamol


My mooltipass arrived today. I have been excitedly waiting for it for months and it’s finally here!

So, first of all, a physical review. I have the ABS version, although I’m waiting on an aluminium one which will be my pocket mooltipass soon. It’s a very nice size and weight, it is light enough to carry around easily but still has a solid enough construction that I’m not worried about it getting destroyed easily. I have two very minor concerns, the first is that the corners are much more angular than I was expecting. Maybe I’m just used to devices made by a certain fruit vendor, but I guess I’m more used to more rounded corners. The second worry is the front panel, it is glued to the device and at the moment appears to be quite solidly so. I’m just a little worried that if I do start carrying one of these devices around, it might get loose. I have no idea if these worries are founded at all, I’m just a little conscious, but I knew about the glued cover before I pledged to the IndieGoGo campaign, so I cannot really complain about it at all.

The screen is bright, legible and very fit for purpose. You can easily see the pixels on it, but I don’t think this is a problem at all. There are little sliding animated menus which show what each of the buttons do in that mode. The text is large and clear so I think I’d need particularly bad eyesight to have an issue with that. The device was shipped with a standard clear plastic protective film on the front, while satisfying to actually take pff, it was particularly well stuck down so a pain in the neck to get started

The buttons themselves are touch sensitive. I don’t know the precise reason for this, but I assume it’s to reduce the amount of moving parts to being only the micro USB cable, rather than physical buttons. Personally, I’m a fan of buttons, the more clicky the better, but the touchpad serves the purpose for this, and if it increases the usable lifetime of the device without increasing the production costs, I have no problems at all with the choice.

Having said that, I do appear to be having a hard time with the touch panel itself. It’s arranged in a circle, there seem to be six touch zones, four of them are arranged on the diagonals which are mainly used for traversing menus. Then there are touch pads on the left, and right of the circle which are used for yes/no messages. For text or pin input you use the circular section as a “wheel” to cycle through values. I don’t know whether it’s just my fingers, but the device isn’t as responsive as I’d like. It often takes a full time around the circle to progress one entry in whatever I’m selecting, and then it skips 3 entries in the next quarter turn. I believe it just loses my touch input because sometimes it also picks up my fingers as touching the side buttons. What this means in practice is, while I’m trying to input my pin, it’s quite frustrating, but also I’m sure I will at some point enter it incorrectly because of mistaken inputs. As I’ve said, I’m still unsure whether this is my fingers, or the device, but I will investigate further. On further investigation, it appears that the touch areas are smaller than I expected and I have to move my fingers around inside the little circle. As I have quite large fingers, this is a little frustrating, but I can definitely work with it.

The smart cards are nicely designed and there’s not much I can say about them, apart from it looks like they’ve been printed backwards. I believe I saw this mentioned somewhere. A slither sticks out of the side of the device and there appears to be a matching mooltipass logo, but it’s printed on the side of the card that gets pushed into the device, so all I see is a corner of the larger logo. Other than that, they’re credit card sized and just work. Nothing much to say otherwise.

At this point, I’ve only used the device on a Windows 7 PC, but I will shortly be also testing on Mac OSX and maybe some random Linux distros to see how it fares on them. Plugging it in initially started the setup sequence. It asked me to insert a card and enter a pin to create a new user. I failed the first two times because of the touch issues mentioned above. Windows picked up the device straight away and was happy with it. At the time I didn’t try the HID emulation mode because I didn’t have any accounts set up but I’ve since tested it and it just works with one caveat. You select login from the main menu, then choose the account you want to log into, followed by confirming to type the data. The issue is that the HID emulation is set to, I believe, US layout, whereas I’m using a UK keyboard, so the @ symbol becomes “, which for email logins could obviously be a little frustrating.

I quickly installed the chrome app and extension and had a little play around. My first thoughts were “How do I add an account to this?”. I haven’t looked up documentation online for a while, and I wanted to see how easy it was to just use. After poking around the settings and app a little bit, I gave up and tried to log into google, then I got a little popup saying “Do you want to save this on the mooltipass” (or something to that effect) and… it just worked. It saved, I logged out, I used the mooltipass to log back in. I was happy.

My goal for the mooltipass is to have two devices, with shared credentials on both of them. Then I want a pair of accounts on them, one which contains my personal passwords, and one with the passwords I use for work. At this point I only have two cards, and I want to have one backup card for when I inevitably lock one out, so I’ve not yet tried using two sets of credentials on one device.

Maratis features

I’ve been playing around with Maratis for the best part of a year
now. It’s been a great engine to work with, but I’m missing a couple
of features that I really want to have to use for She Wore White which
just weren’t possible with the engine in it’s current state. So for
the last few months, I’ve been attempting to extend what is there and
make a system that my team, and I, am happy to work with.
Continue reading Maratis features

On the subject of GUI

Finding the right way to do your user interface is always a sticky problem (I’m sorry, I couldn’t resist the pun)

But it’s true. I’ve now had the (dis?)pleasure of working with several GUI systems both through work and outside of it. There have been a great many people who have attempted to tackle “The GUI Problem” online. I believe I have the reason why there are so many different solutions, but they’re all awkward to use.

GUI is easy.

It’s just 2D. We work in 3D now, the 2D stuff is no problem.



Getting a nice GUI system is very difficult. The system itself should take just as much care, architecting and design as a physics solution. On top of that, usually, you don’t want programmers just tweaking values, so you have to spend a good deal more time on top of that making an artist/designer interface. These things seem to have been overlooked.

Let’s take a step back and look at the different types of GUI solution available at this point, in particular for games. I will attempt to not use names to protect the guilty (ha!)

Firstly we have the most basic of basic, an Immediate Mode system. This is very quick to develop, and pretty quick to prototype. It’s straight forward. It’s clean. You tell it to draw a button and it draws a button. So what’s the problem here? Well, unless you are one of the incredibly rare crossbread of programmer/designer/artist, you will find this incredibly cumbersome. Yes, you can throw together a layout pretty quickly, but you actually have to do the throwing together in code, and it usually ends up with the GUI code being spread throughout the project, as different things might need to display things at different times. If you plan this well, you can consolidate all the GUI code in one place, but even then it becomes unsightly and awkward.

I will skip the more standard code driven system as it has many of the same shortcomings as Immediate Mode, apart from, for the most part, you can init and forget, instead of manually drawing every image every frame. But that leads me nicely onto a data driven system. For the most part these work in a very similar init and forget way, but there can be little to no actual GUI code written. The GUI layout is loaded in as data files. The benefit here is that you can quickly change the GUI without recompiling. This is actually a very good system, as long as it doesn’t take 30,000,000 XML (yeuch!) files to be written before you can display anything.

Before I go on, I should say that at no point, yet, have we seen an editor. It’s even safe to say that for the code driven systems, it’s near impossible to make one (unless you want to make an editor which outputs code, which I guess is an option…) This displays one of the biggest issues with GUI systems. Editors are always an afterthought. GUI systems are written by programmers, so they have programmer interfaces first and foremost. Editors come after if/when there’s time and they seem even more of a tacked on addition to the tacked on feel of the GUI system itself.

Finally, the most favourable option right now, is to use an existing format for GUI. The “industry standard” is using Adobe Flash through Scaleform. I myself have used something similar. Artists love it. They can design the GUI in an environment that they are familiar with and they can have access almost straight away to a lot of shiny features and animations. Leaving any prejudice of Flash behind, the IDE is possibly the pinnacle of what could be considered GUI editor design.

Am I saying we should all be using several thousand dollar flash libraries for our GUI? Definitely not. This causes a lot of issues, if you take a moment to think about it, it becomes obvious. Flash is designed to be entirely standalone. True, you can send things across the net to have your flash application talk to other things, but in general, it doesn’t expect to be communicating with anything else.

Very usefully, flash actually is quite flexible. You can try to call a function in actionscript which doesn’t exist. Most languages, if you tried to do this, at best you get a message our assert saying it can’t find the function, after which behaviour may be a little unexpected. At worst the program crashes, that’s if it’s allowed to compile. Flash shrugs it’s shoulders and continues as if nothing happened.

This means that within your game, you can implement some new magic functions and when you do any testing add a standalone flash application, it will just ignore it. This works absolutely great for menus as they can be, for the most part, pretty self contained. When it comes to in game GUI, you usually require a much tighter link with game code to make it feasible.

Basically, what I’m getting at is that the best solution right now can only be a series of hacks.

I’m not denying that they are good hacks, but they are hacks. And hacks are almost always the weak point.

There is one more solution that’s come up more recently which is to use a 3D editor to lay out the GUI in 3D, then draw it using an orthographic camera. This is a great idea in principle, it makes the GUI part of the actual game world so it makes tying into game code almost trivial. It allows you to use whatever editor software you already have set up for game design. I still have issue with this. The best 2D artist/designers I know are just that, 2D designers. Sure, we can ask them to learn 3D tools, but it’s a workflow that they’re not necessarily most comfortable with.

There are a great many things to consider here. Am I just going to sit back and complain? Well, I’m tempted now. But I can make a couple of suggestions. Most of which I am attempting to address in the combination of Maratis and Löve2D. First of all, the system should be pretty easily integrated with any game code. This will come down to the API I expose on either side of the interface but as the interface can be entirely open (unlike the flash layer) then that shouldn’t be an issue at all. Secondly, the editor. I would absolutely love to be able to use an existing and proven editor, but that would probably end up as another series of hacks. The main thing is that, from the word go, the editor should be planned for. Finally. One incredibly important thing which I haven’t mentioned yet, and possibly should have, is flexibility. No GUI solution is ever complete. There are always bespoke things that the game you’re working on will need. Making the system flexible enough to extend is fairly easy, making the editor accept and respect the extended features is a little more complicated, but should be do-able.

Anyway, I think I’ve ranted enough about this topic. I would love to hear if someone has any experience with GUI systems, especially if they think they’ve found a good one. Also, with more user interfaces now moving into 3D, is this even relevant any more?

Diary of a Slacker