Interfacing with UI #4 – Coherent UI

This is part of a series of posts revolving around user interface design and development, the introduction and links to the other posts can be found here.

Last I wrote about user interfaces I discussed the new Unity UI system and I wrote about our process of porting from Daikon Forge to it. That was a year and a half ago and a lot has changed since then. To keep things interesting we decided to move from Unity UI (yet another move?!) to Coherent UI and I’ll explain why we did it.

Why Move… Again?!

Changing UI library is no small task and it’s definitely not something to be undertaken lightly, especially twice in the same project. So… why did we move? Ultimately it came down to two main points.

We found Unity’s UI was not up to standard at the time

When Unity UI came out I started porting our mod tools over to it. Whilst doing this I encountered a lack of functionality and lots of bugs. The framework was far from mature and lacked a lot of features and functionality you would come to expect from a UI middleware. Unity open sourced it, which was a great move, but even today there is functionality and features missing and the workflow just didn’t fit what we wanted.

We needed a mod friendly UI system

This is an especially important point. As you may know by now flexible mod support is one of our core design pillars for Solitude and Unity UI just isn’t mod friendly one bit. It’s heavily Unity Editor based and, while you can set up the UI at runtime, it takes a lot of code to achieve simple, reliable results. We needed something that modders could easily edit, play around with and get into the game. The only way we could manage that would be for us to write a layout tool as part of the game mod tools and a converter for changing this custom layout format into Unity UI. To be blunt – that wasn’t going to happen. We’re too busy with critical features as it is so having to write a UI converter would be too much work for us.

So I decided to expand our search which lead to me find Coherent UI.

Coherent Labs

Coherent UI

Coherent UI is a user interface middleware developed by Coherent Labs. It integrates a wrapped chromium renderer (think: Chrome web browser) to provide HTML, CSS and Javascript support for user interfaces. I took to my research and after a few example projects I quickly realised how perfect for Solitude this would be. This was in January 2015.

Coherent provided loading of UI in the form of HTML, CSS, Javascript, the bindings and hooks for linking the renderer into Unity but it didn’t provide any kind of complex framework for controlling all these. To keep inline with our mod support design pillar we needed a flexible system for modders to define user interface components that can be loaded and removed from the game. It took us a few weeks of solid development effort but after we had finished we had a framework that allowed us to create user interface components and bind them to the game. Not just that! We were able to separate the UI logic from the components so the UI logic stayed in the Lua mod scripting layer and the pure view stayed in the JavaScript code.

This framework proved to be very flexible and allows modders to inject their UI mods into the core Solitude game, or provide UI functionality for more extensive mods they create all in a well known format. It even allows for real web browsing! (We’re limiting that for the core game but modders are welcome to unlock it with a simple change).

The downside to Coherent UI was that it is closed source and is expensive for a small company of our size. For a larger company it’s very reasonable in cost. At the time we took the subscription approach with the intention of upgrading to a full game license when we had the funds for it.

So, what else could we do with Coherent? Well… it allowed us to truly get the most out of Solitude’s terminal system. Solitude Tech Demo 1 had terminals but they were more faked as they weren’t sync’ed up for multiplayer support and they were definitely not moddable. So with Coherent it allowed us to get to our Terminals 2.0!

Terminals

As we were pushing Coherent hard we started to feel some performance issues in two mains areas. We plan to have a lot of these terminals in one area at any one time and we intended to show in-game video feeds (view screens) on them too. Both of these areas were causing us performance issues and were a cause for concern. Coupled with that, Coherent informed us that the subscription tier was to be end-of-life’ed and, after the time extension they offered us, we would have to upgrade. Since a time extension of a year wouldn’t cover us for the release of Solitude we decided to upgrade with the subscriber discount they provided.

Coherent GT

During this time Coherent suggested we try their new version of Coherent called Coherent GT. This apparently brought with it a lot of performance improvements so I spent some time investigating it. I was very happy with what I found as it solved both performance issues that were a concern for me only a few weeks earlier! With that, we fully upgraded to Coherent GT! This allowed us to fully implement viewscreens in Solitude.

The terminal viewscreen feed is fully embedded in the terminal HTML (DOM) structure, so you can easily manipulate it with JavaScript and overlay any user interface on top of it like you usually would on the terminals. Here is a very basic example of an in-game camera module on the wall (it’s to the right of the large viewscreen) with the view being shared between two terminals with the viewscreen feed on it and a basic overlay.

View Screens

So there we have it. We’re not changing UI system again and Coherent is, without a doubt, the best fit for us. We get to use a technology that mastered scaling and aspect ratios long ago (web development), access to all the Javascript libraries that exist, a fast and multi-core UI renderer and a system that is fully moddable. Sounds like a win to me.

I’ll make another post to go into the terminal system in more detail as there’s a lot of things going on there. Hopefully you found this interesting and, like usual, comment, email or grab me on Twitter at @CWolf.

Thanks for reading!

Solitude Tech Demo 2 @ WGDS2015

Over the last few weeks we’ve been working very hard on Solitude tech demo 2. Last year we took tech demo 1 to the Wales Games Development Show (WGDS) and it received an amazing response by all those who played it. You can watch two community members play the demo below.

Since tech demo 1 was so well received we’ve decided to attempt another ambitious tech demo. The main role of these tech demos is to pull together all the game systems we’ve put in place to ensure we’re on the right track and they work well together. These systems include things like a flexible, user friendly structure / ship creator, moddable runtime 3D model importer and editor, fully moddable game logic, an upgrade to Unity 5 with their new physically based rendering (PBR) systems and much more! The demos are created in such a way that show stylised scenarios similar to those that might be found in the future releases of Solitude. We’re very happy with our progress, especially the flexibility of the game, and we’re very excited to share it with you all.

We’ll be keeping the actual scenario of tech demo 2 under wraps so to be a nice surprise for the actual show, but after we’ll make sure we release a video of what it’s like.

The show is on the 19th of June 2015 in Cardiff City Hall. You can buy tickets on their website. If you’re going, make sure you come say hi to us!

Interfacing with UI #3 – uGUI – Beta First Impressions

This is part of a series of posts revolving around user interface design and development, the introduction and links to the other posts can be found here.

With this post I want to talk about my first impressions when using Unity 4.6 Beta 18, specifically relating to uGUI. Everyone should realise that uGUI is still in beta and is improving with every beta release. I’m sure a lot of issues will be fixed but my post will be a snapshot of how things are now and my thoughts. As a side note to tie up my previous posts, with the death of Daikon Forge and no longer any hope of DF-GUI v2 we’re moving full steam ahead with uGUI. With that, let’s get to it.

I’ve been using uGUI, Unity’s long awaited new user interface framework, for the past week. I’ve been developing Techyard’s (Solitude’s mod / dev tool) new user interface with it. Generally it’s not been a too painful experience but I’m making slower progress than I had hoped. Part of this is the usual learning curve of a new middleware but also due to the current state of uGUI.

uGUI is excellent in that it’s free and integrated into Unity. What I am most happy with is that Unity has decided to open source uGUI on the official release of Unity 4.6. This is amazing news as there is already an active community forming around uGUI and, with community involvement, I fully expect some excellent extensions and modifications to appear. Even during the past week people have been sharing some excellent scripts to supplement the framework.

The system is relatively easy to use from the Editor and makes use of a visual anchor system that seems to work pretty well. Exact position can be a bit of a pain though as dragging the anchors never gives exact positions – it’s all very ‘close enough’, which isn’t nice. Corrections are always needed in the components if you want exact numbers. Since Solitude will create most of its UI programmatically I think the anchor system might be more of a foe than a friend, but I haven’t done enough 100% programmatically to say for sure yet. Scaling seems to work fine, even if it’s basic support right now, but aspect ratio support could do with some extra work. Luckily, Unity have mentioned scaling is a focus soon and, hopefully, this will include better aspect ratio support. While images can be selected to maintain their aspect ratio I think this functionality would be very useful at a higher level.

Currently uGUI provides a few basic UI components but little to none of the more complex ones. Most of my time has been recreating the more complex UI components in a reusable way and converting the previous Daikon Forge UI to uGUI. I’m been making decent progress on this so the Techard UI work should speed up as times goes on.

Like most Unity-based UI frameworks, small things exist that annoy. The main thing I get tired of is that you can’t increase the size of a UI panel without scaling the content inside it too. Imagine when you create a panel then realise you want to add more content into it. Resizing the panel scales the content inside, even when the anchors are not set to scale. This use-case can be a pain. There may be a trick to unhooking the anchors before you do this but I’ve seen this exact behaviour with all UI frameworks and it’s a pain. The only ‘fix’ is to remove the content from the panel, resize the panel and then add the content back in. Hopefully Unity, or the community, come up with a better solution (or I find my mistake). I’ll probably look into this issue in more depth soon. Things aren’t bad, just fiddly.

Performance seems good for now. uGUI has better CPU performance than Daikon Forge but the draw calls can be a bit higher depending on how things have been set up previously. Sometimes a single draw call on NGUI / Daikon Forge can come in at four draw calls. I have a feeling things get better for uGUI with more complex UIs though so I’m not worried about this at all. Render order is taken from Unity hierarchy order so this change will be new for a lot of people. I’m pretty sure I’ve seen what is a rendering order bug but need to submit that to be sure of it.

All in all, it’s great to see the shift in Unity’s closed communication attitude of the past few years. The past six months have seen Unity allowing their team to talk much more openly about what is going on. This is very evident in the Unity 4.6 Beta forum where Unity are taking a lot of time to help developers having issues with uGUI. This is a good sign for the future.

I’ve had my fair number of problems with uGUI but it’s only the second week of the beta. If I’m completely honest I would have hoped that uGUI would be in a better state considering how long it has taken them to make. I guess recoding it three times over does tend to reduce a feature set. I do have to keep reminding myself it’s still a beta and not to be too harsh though. A lot of these problems will be sorted out so we’ll be sticking with uGUI for the immediate future. It’s probably worth using uGUI if you’re starting a new project but I wouldn’t recommend ripping out UI in an existing project just yet. It’s great to see Unity take positive steps on the UI and I look forward to the source being released.

Tech Demo Aftermath

It’s been a month since our last post and we’ve been pretty busy so we haven’t had time to put together another one of our blog series’ posts. However, we will update you on what we’ve been up to recently.

As mentioned in the previous blog post, the Wales Games Development Show went really well for us, leaving us on a bit of a high and raring to jump straight back into game dev. Still, we decided to take a step back and analyse why the tech demo went down so well. We know what we have planned for Solitude, but the tech demo was a very small slice and a very specific scenario that could possibly arise within the game, and because it was so successful we wanted to make sure what it had was not lost as we progressed.

After we examined the tech demo and determined the core gameplay mechanics that made it so much fun to play, we proceeded to refactor and clean up the entire codebase. The entire tech demo was developed in just over 2 months from beginning to end, with the last 5 weeks being some pretty intense crunch. The result, there was a lot of messy code, quick fixes and hard-coded systems to get the tech demo ready in time. So, naturally we had go back through and sort it all out. At the time of the tech demo, the server-side mod scripting system was already in and the scenario was written in it. However, the client-side mod scripting was not, so all the client-side tech demo scenario stuff had to be hard-coded. Over the past month Rich has implemented the client-side mod scripting layer and rewritten the entire tech demo to use it as a test. As of now, none of the tech demo game logic is hard-coded and it completely resides as scripts that get loaded at runtime. However, Unity does not natively support runtime model loading, so in order for our modding system to be complete, Rich is having to implement his own runtime model loader (I’m sure Rich will write up a whole post on his as it nears completion).

We also brought in an intern (Steve Cox) to work with us for a couple months and got him doing some of our outstanding tasks and has generally been a massive help. He’s already ported the dedicated C++ written server from Windows to Linux and replaced our build process with an ant build script. This allowed us to hook it up to Jenkins to automate the build process. He’s also created some targets in the ant build script for cross-compiling so we can automate Windows builds from our Linux dev server. All stuff that was on the to-do list and incredibly important. Kind of nice having an extra pair of hands around. We’ve currently got him working on some of the procedural generation code that will eventually feature in Solitude and that’s looking good so far, but there’s still lots more to do on it. We put together a short video to show where we are on that front (height deformation works but currently turned off).

James has been busy working on Solitude’s mod synchronisation system between the server and the client. The idea is that when a server is launched, it scans over its own installed mods (which includes the client-side assets as well) and stores that information in a registry. When players join a game’s lobby (before the game has started), the host is able to select which mods they want enabled for that particular play-through. Once decided, they hit launch and the server checks if the clients have those mods installed and that the files match. If not then the server begins transferring the mod files to the clients that need them while they are still in the lobby (so they are still able to chat). Once all mod files are transferred, the clients load them and then receives the state of the environment from the server before launching into the game. This means that any player will be able to join any server regardless of whether they have the mod files installed or not as they’ll be install on-demand.

That pretty much summarises what we’ve been up to lately. Hopefully, we’ll be able to get out a blog series’ post in a couple weeks.

Thanks for reading!

Solitude at the Wales Games Development Show 2014

It’s been a week since we exhibited our Solitude tech demo, which has given us a bit of time to unwind after 5 weeks of solid crunch. In that time we went from pretty much nothing, to a 2 player cooperative scenario that not only played well, but was also quite polished. Still, we had no idea what to expect until we got there.

Solitude Booth at Wales Games Development Show 2014

We managed to get the our booth set up in pretty good time but then ran into a few networking issues. Since our tech demo is multiplayer and we know from previous experience that the provided wifi and Internet at these venues cannot be trusted, we opted to bring our own networking gear. After testing pretty much everything at home before we arrived, one of the network cables still resulted in being faulty, which meant one of the connections had to rely on own mini wifi network. This worked fine for the most part, but we suffered from minor latencies in the afternoon for some reason. That was the first issue we ran into, the second was that after we got the network up and running, the Commander’s machine (left) was refusing to connect to the server. After assuming that firewalls were to blame and disabling them everywhere, it wasn’t until a fresh pair of eyes looked over the client config and spotted an issue with the second octet of the IP address, which had been entered incorrectly and completely blind-sighted from then on. Whoops! After this was corrected, we had both machines connected to the server and ready to play one minute after the doors opened.

From here on out, things just got better and better. We could not believe how much fun people were having. One of the key gameplay requirements is communication, so we had a voice chat system running with headsets for people to communicate in-game. Players were getting really into it and being very vocal about it, and this was drawing in an even bigger crowd. Apologies should go out to the talkers on stage. When the room was quiet for talkers, occasionally there’d be a “GO LEFT! NO, YOUR OTHER LEFT!” emanating from our booth. Whoops. For the entire day we pretty much had people playing the tech demo with a crowd spectating behind, we even got the Wales Interactive directors into the driving seats.

Wales Interactive plays Solitude

Even though the booth was really busy most of the day, we managed to get out and about a couple times to check out what the rest of the show had to offer. This would not have been possible if we didn’t have our additional helpers, thank you Chris, Andy & Ben! A few of our personal favourites were Infinity Runner by Wales Interactive, really polished game with good use of the Oculus Rift and, surprisingly enough, does not come with the nauseating side-effect that most VR games seem to induce! Friendship Club by Force of Habit, a great little top down battle arena game that supports up to 4 players via local multiplayer. And Sim Raiders by the single developer (the entire game, down to the music and art), Matt Stockham, a fully procedurally generated RPG dungeon crawler that’s different every time you play.

All in all, the show was absolutely brilliant for us. Solitude got way more attention and positive feedback than we could have ever hoped for. We were definitely one of the more active booths at the show so it’s incredibly encouraging. A big thank you to everyone who came to the show and made the day awesome, both exhibitors and visitors alike. An even bigger thanks to everyone who came over and tried out the Solitude tech demo, we had a lot of fun and a lot of laughs throughout the day. If you didn’t get a chance to come over to our booth or didn’t attend WGDS2014 but are still interested in the tech demo, we’ll be releasing a video based on the tech demo gameplay soon to both this site and the Solitude site.

Announcing Solitude, A Coop Space Survival Game

After months of blog posts alluding to our current game in development, we’re ready to let everyone know what we’re up to. Announcing…

Emergency Repairs Wallpaper

Solitude is a cooperative multiplayer action survival game set in space. We’re a big fan of space games and feel there aren’t enough cooperative games out there, however players may play on their own if they choose to do so with computer controlled crew mates. The game is played from a first person perspective as a crew member of the Solitude.

In Solitude, you and your crew find yourself stranded on the other side of the galaxy after humanity’s first experimental warp drive malfunction. Now alone in unknown space, it is the job of the crew to repair the ship and begin the long journey home.

Solitude is one of the games we’ve been wanting to make for a long time now and we’re finally in a position where we’re able take it on as our main game development project. We’ll be releasing information and blog posts about it over the coming months but for more detailed information visit the Solitude website. You’ll also be able to follow our progress in more detail with the Solitude Facebook page and Twitter account too!

As you may know we’re heading to the Wales Games Development Show this year and we’ll be bringing a Solitude tech demo with us. If you’re going to be there come say hi and check it out!

Interfacing with UI #4 – Coherent UI

February 5th, 2016

This is part of a series of posts revolving around user interface design and development, the introduction and links to the other posts can be found here. Last I wrote about user interfaces I discussed the new Unity UI system and I wrote about our process of porting from Daikon Forge to it. That was a year and a half ago and a lot has changed since then. To keep things interesting we decided to move from Unity UI (yet another move?!) to Coherent UI and I’ll explain why we did it. Why Move… Again?!... (read more)

@SolitudeGame: Status update: Fuel reserves low. Asteroid mining facility detected on sensors. No response to our communications. On approach station appears to be abandoned and running on emergency power only. Away mission approved. Mission objective: Search and salvage - fuel is a priority.

23/03/2022 @ 11:00am UTC

@RogueVec: And so it begins! #RebootDevelop

19/04/2018 @ 8:05am UTC

@RogueVec: We'll be at @RebootDevelop this year. We can't wait! If you want to hang out just give us a shout! #RebootDevelop2018 #GameDev

16/04/2018 @ 12:06pm UTC

@SolitudeGame: Fullscreen terminals allow you to hook into your ship's guns for fine control! Moddable gun modules, terminals and UI! https://t.co/B5N01jrA70 #GameDev

8/12/2017 @ 4:58pm UTC

@CWolf: Woo! And, now we have a cross-compiled (nix --> win64) @SolitudeGame server in our build and deploy pipeline #RV #GameDev

28/11/2017 @ 3:39pm UTC