OceanWall Games

Windows Development by Paul Atkins

This summer, we installed our first version of the OceanWall Games interface at Hillside Centre!  We had the following goals for our custom OceanWall interface.


The interface should not look like Windows


The system can only be used to run predefined apps


Young children must be able to change the game they're playing


Create a platform that would allow multiple children's games to be displayed

We thought we could use Windows 10’s new “multi-app kiosk” feature to both lock down the system, and provide the interface to run the games. Because there would be no “Start” button, we expected the interface to look different enough from Windows so we focussed on building a custom mechanism to change the game without relying on a Windows taskbar.

The mechanism to change applications would be built using AutoHotkey.  The balance of speed of development, reasonable subset of programming language features, and reliability made it a great choice to build rapid prototypes of our vision for us to review with our client, while being able to be built out once we defined our first version.  We were originally thinking of building a close window “X” in the upper right corner of the game, but thought kids would have difficulty reaching/noticing it.  Instead, we decided to build a “Home” button to keep the experience similar to a tablet and position it in the mid-right of the screen.  As we know ‘kids will be kids’ and some kids might find it hard to resist pressing the home button while another child is playing a game.  If this does happen the child playing the game would lose the game.  The team opted to have the home button minimize the game so it could be restored by simply pressing on the game’s icon.  The child starts from where they left off!  After building the home button that stayed on top of other windows, we found some games always started full-screen, which didn’t allow for our home button to be displayed over top of the game.  We then developed a feature to detect if a game is full screen, and send commands to change it so the home button could be shown over top.

Once the home button with full-screen detection was built, we set onto the task of setting up the multi-app kiosk mode in Windows 10 that would lock down the system and build the home interface.  After setting up a sample interface, we found the rectangular appearance of the start menu tiles was not very appealing and snapped to a grid that offered little for custom positioning. We also found that the only way to get the tiles for the games to display on the desktop was to run in “Tablet mode” which applied a darkening overlay over our desktop background which made it look dull. Nothing about this interface was vibrant and interesting, so after discussing with our client, we decided to build out our AutoHotkey program to manage both the main “home” interface and the home button to return to the home interface. With the interface being completely in our control, we could now build anything we could imagine, and we imagined… BUBBLES.  AND MORE BUBBLES!

Bringing the interface into our AutoHotkey program meant we could make any image we wanted for the game shortcut, so we decided to create circles instead of rectangles, and we went absolutely hog-wild with a bubble overlay.  The home button, elements of the desktop, the game icons, everything, bubbles, and with some waves at the top of the desktop image, we were now “underwater” on our home screen with a consistent theme for the whole experience.  The kids really enjoy the new interface.  Our client, Hillside Centre, is excited to finally offer the kids more than one game plus the interface promotes the OceanWall and the Hillside Sea Ranger Kids Club.  We like that it not only works well, but allows us to have complete control over the interface and be able to realize our client’s evolving vision.