It’s been quiet lately. This is the long “labour day” weekend, a chance to dedicate more time to my game. Also a chance to write a post on what I’ve done since the last time I wrote on this blog.

I remember saying on Twitter I intended to have a fully-playable demo by early August. That has already come and gone… but I have finished something important: the GUI.

Well, it isn’t finished, necessarily. But it is implemented, pending some graphic design changes that may come one day. More importantly, the logic behind them is implemented. Sure, I could spend anywhere between minutes and months tweaking the look to make buttons and icons look just right, but making sure it actually works as intended will allow me to focus on other things for now.

I won’t talk too much about exactly how it is implemented. For the most part, I used Unity3D’s GUI system for sizing and placement of objects, but I override their “button” system with my own to have better control of the look and function when clicking something. I use finite-state-machines to control what parts of the UI are open at any given time. But that logic is written like duct-tape and crazy glue… it works well for now, but I wouldn’t reuse most of it without a major overhaul.

When I say I have a GUI system, I mean I’ve implemented the following:

1. • Menu Button

To pause the game and review settings and progress, or quit the game.

1. • Menu (Resume, Quit implemented)

Options to review settings and progress, or quit the game.

1. • On-Screen D-Pad

To optionally control player movement with mouse or touch-screen.

1. • Compass

To help provide direction (map to become available in pause menu).

1. • Interact Prompt

To let user know something can be talked to.

1. • Conversation Box

To hear conversation from NPC.

1. • Question Prompt

To answer question, potentially load new action or scene.

It looks as though the GUI is being designed for touch-screens. Don’t worry, the D-Pad won’t constantly be there if you are using a keyboard or game-controller. But from the start, I wanted to make the game playable by as many means as I could program. This includes game controller, keyboard, and mouse (and through testing, mouse == touch, so far). This contributed to the complexity I had to deal with: Can all actions be done with just a mouse? What if the user switches between different modes automatically… would one interfere with the other’s current state? With this type of game, where timing and precision isn’t necessary, it’s possible to make, but more complicated than I thought. Again, my code looks U-G-L-Y.

This doesn’t necessarily mean I am making the game to be playable on touchscreens, as I don’t think most phones could handle the “3D Cel Animation” (it’s been almost five years since I’ve tested, so maybe I’m behind). This also doesn’t mean that I’m making the game more accessible to non-traditional controllers, for while I do intend to write a proper “input” menu at the start screen, I don’t think most controllers beyond what I’ve mentioned here will function perfectly. Really, I just want to be able to play this on the go with my Surface Pro tablet.

And I can. With this, plus a rough looking Start Menu and Loading screen, I have a functional demo where I can load the game, walk around, talk to characters, and quit, all within the game exe. You know, the stuff I should have had about 3 years ago. Specifically, NPC talking gives me a template where I can start programming real scenarios.

And finally, I can work on the final important part before focusing on final details: the turn-based strategy map. I had been putting this off on purpose for too long, but now I really can’t work on anything else until that’s settled. The next few months won’t be easy…