Building New Worlds

The Shields in Void Eclipse allow small fragile units like the Spy to survive a bunch of attacks. Once they go down though.....they’re pretty much done for.

Revealing our next Tier 1 Varegon unit, the Acolyte!

Today we are revealing our first playable Varegon unit, the Initiate!

"Initiates are Varegon multi-purpose terrestrial infantry. They wear exo-suits suitable for terrestrial environments particularly well suited to interior structure navigation or boarding of enemy ships."

As part of semi-weekly series and EpicFriday, we'll be revealing our units of the Varegon race for the upcoming game Void Eclipse: Empires at War! The cards for the game are textured with substance painter and running in @UnrealEngine

While I’ve kept up posting on social media for #screenshotsaturday, I’ve been a bit behind on posting on the blog here. Though it might not appear that way, we’ve actually been pretty busy working on things behind the scenes. Things that don’t always lend themselves to photo-friendly blog posts like user interface design, game mechanics, testing and...

Multiplayer Server Hosting! Yeah! We started out looking at Microsoft Azure but ended up settling on AWS Gamelift for our dedicated server hosting solution. The Gamelift server-side integration was relatively easy to get going so we can now playtest our Alpha builds in the cloud. This is super-helpful getting feedback internally and will give us some time to get familiar with it before we do our Beta-testing. 

It just works! Well, kinda...

The plugin listed on the Unreal marketplace above looks and sounds ready-to-go. I definitely felt a bit like the guy they showcased on the plugin page wearing the funny hat all sure of himself thinking he’s going to integrate and deploy his server in hours (days) about to be sucker-punched by the realities of misleading marketing ploys.

Okay, so integrating with Unreal wasn’t the easiest but it wasn’t exactly hard either. This blog was helpful, though how they managed to get a build with 0 Warnings is beyond me. There were a couple of hiccups with n00b stuff like maximum path length (I had to put the SDK at our root location to keep the PATH short or you end up with indecipherable errors) but overall things were easy. BTW - the support staff on the AWS gamedev forums respond with lighting-fast times (3 min!) during the week. I don’t think I’ve ever experienced customer service behind a set of SW libraries that expedient before. Big-ups to them! The example integration of the server plugin with Unreal left a bit to be desired though. Obviously everyone’s implementation will be a bit different but an example would’ve been nice for the some of the things in this sequence diagram. Luckily I happened upon this guy’s implementation which provided a lot of helpful examples to start from. Player validation via PSID is key here, otherwise the server is just going to let any-old troll with an IP & PORT # connect by default.

For my game I think its important for the star systems you explore to be compelling and visually interesting. A big part of the presentation is the controls - how do you navigate the star systems in your empire?

As you can see, I’ve been working on creating the space setting for game. Before all the UI elements and everything gets in the way though, my maps in space should look interesting. That’s where Spacescape & some raw Hubble data comes in...

Its not perfect so I’ll keep playing around with the placement and size of the galaxies but I thought I’d share my current process.

I’ve taken some data from the Hubble legacy archive and created a color image from the Red, Blue, and Green bands. Here’s the thumbnails:

Then I use Photoshop to project each color band and create the color image. Then I use some curves and other adjustments to the image until I get what I want:

Then before we mix this with our Spacescape I turn the contrast way up to get rid of the partial black so only the brighter portions of the image stand out. 

Last week we posted our concept hatchery for our Varegon species, showing their anatomy from birth. This week we reveal how these aliens escape their frozen world and swim among the stars!

Looks like a large ship with an envoy of smaller vessels. Giving off an eel vibe, no?

I liked this one so much I made it our banner, so I guess you might’ve seen it yesterday if you were paying attention ;)

2017 is here, and we’d like to share our first key art piece! Below is a BioMech Hatchery full of bright new beginnings. 

As we become more connected with our technology we introduce it to our children at a younger and younger age. Where will that lead us in the far future?

For our fictional species it’s led them to enhance their young before they hatch.

Its already #screenshotsaturday again? Time flies...Here’s my latest visual experiment for my #sci-fi #indiegame

Today we’ve got our creatures under fire, and a little peek at what might be under that helmet...

The game we’re working on is a digital strategy game, set in a science fiction universe. Creating unique, exciting new IP for the playable races is key for us and is something we’re excited to share with everyone. This past month has been focused on developing our playable races’ lore, look, and unique gameplay strategies. Though there isn’t anything finalized on the story/gameplay I thought I’d share some sketches from our concept artist as we explore early rough concepts for our first race of playable aliens. 

The first is a set of ground troops on an away mission (scouting or engaging hostile forces) and the other is ships leaving the alien’s home planet.

I'm ready to play my game internally to get some feedback on the core mechanics. Problem is, packaging your game in UE4 creates a directory of, well, stuff. There's engine stuff, extras, your exe, etc.  Here's what a bare bones packaged game looks like:

That's right - 756 files, 64 Folders. There's no way I'm going to list those by hand.

Additionally, there are some prerequisites that might need to be installed for a computer that UE4 bundles with the output but has to be run separately.

This is OK for me but if I'm asking someone else to try out my game they're going to expect a single file that just Installs everything. Like how you installed games before Steam existed. Anyway, I decided I needed to create an exe that was going to install the prerequisite's needed for Unreal, then install my game. Creation of the installer also needed to be automated so I can just run the thing every time I package my game for release.

I searched the UE4 forums and found there's a great set of open-source tools now to do this called WiX (Windows Installer XML) toolset (http://wixtoolset.org/). Unfortunately the documentation is pretty damn sparse - and that’s coming from someone who used to deploy Linux for embedded devices for a living. Once I read a few tutorials and skimmed the documentation I came up with a basic architecture for how to accomplish this feat.

The Solution

So the basic idea for my little side quest was to use what's called a WiX bootstrapper that chains together the prerequisite executable from Unreal, and the msi that's created for all the files generated for the packaged game.

Now there were youtube tutorials and blogs on how to do parts of this, but none of them automated the process into a single solution file (also many of them were people who didn't seem to understand the WiX file syntax and ended up manually copy & pasting file contents about just to get their stuff to work).

At the end of the day I used a few different tools in the WiX toolset.

A WiX Setup Project; This project template in Visual Studio is used to create the MSI for your packaged game.

Heat.exe; This guy is the HARVESTER (I thought of this guy the entire time). The basics is it takes your packaged UE4 directory as input and spits out an XML file (.wxs) that describes your files and directories to the WiX project.

A WiX Bootstrapper Project; This template in Visual Studio is used to create the final exe.

WiX Setup Project

First create the setup project by opening Visual Studio then File->New Project.

Give the solution a name and name your project. In my case I called my project Stellar. Next, in the Product.wxs file that is in this new project. Replace the Name, Version, Manufacturer, Title with whatever you want for your project. Then for the ComponentGroupRef Id change it to GENERATED_UE4_GAME_PACKAGE. This is going to be the ID you feed into HEAT when it harvests your packaged game directory.

Finally, add the following:

<Property Id="WIXUI_INSTALLDIR" Value="INSTALLFOLDER"></Property>    <UIRef Id="WixUI_InstallDir"/>

To support the WiX UI you'll need to add references to the extension dll's. Right-click References -> Add Reference and under the Browse tab select WixUIExtension and WixUtilExtension. Then click Add, then click OK.

You can choose which type of UI you like best but I stuck with the simple WixUI_InstallDir type.

Here's my final Product.wxs file  (UpgradeCode is not shown as that is auto-generated):

Now, create that system environment variable that points to your packaged UE4 game location. In my case its this:

Go back to Visual Studio and open the properties for your project. Under Build Events you'll want to include parameters to run HEAT. Heat is run in the pre-build event so that your XML files are generated before WiX goes to put the MSI together. Paste this line into there:

"$(WIX)bin\heat.exe" dir "$(UE4_GAME_PACKAGE_DIR)" -cg GENERATED_UE4_GAME_PACKAGE -gg -scom -sreg -sfrag -srd -dr INSTALLFOLDER -var env.UE4_GAME_PACKAGE_DIR -out "$(ProjectDir)GeneratedFilesList.wxs"

To explain some of these:

Now if you were to build the project at this point it'll generate the file list but the Product.wxs won't be able to refer to that file. That’s because that generated .wxs needs to be compiled and linked along with the rest of the project. To do that open up the Project Properties and go to Tool Settings. Add the wxs file to the compiler, and the compiled object to the linker. Make sure you have All Configurations selected so this works in Debug & Release builds:

Great! If you've made it this far you've got a solution that automatically takes your packaged UE4 and creates a single MSI to install your game! If that’s all you wanted then you can stop here. Otherwise, soldier on to the...

Bootstrapper

The final step is to create a bootstrapper to chain this & the prerequisites together into a single exe.

In the same solution go ahead and right-click the Solution and select Add->New Project. Then select the WiX Bootstrapper Project from the list and give it a nice name. This project is what creates your top-level exe file.

In this new Bootstrapper project first right-click the project -> Add Reference and add a reference to the extensions dll's you'll need (WixBalExtension, WixUIExtension):

Then right-click->Add Reference and add a reference to the previous MSI project you made in the solution (the one we made to create the Game's MSI). It should be the only one listed in the Projects tab of the Add Reference box:

Okay, now open up the Bundle.wxs file and replace your Name, Version, Manufacturer. Under the Bundle tag add IconSourceFile="myicon.ico". You can generate an icon .ico file using http://icoconvert.com/ then put it in your bootstrapper project folder.

Also since this is a RTF license bootstrapper template we can include our license file and logo png. Here's what mine looks like:

The logo png should be placed in the directory where this bootstrapper project is located. Also put your license rtf file there to describe whatever it is you need to for your licensing.

Finally we come to the guts of the bootstrapper, the CHAIN. The Chain describes the order of exe's, msi's you are chaining together, in order. For us that’s just the UE4 Prerequisite exe and our MSI we created in our other project. I went ahead and uses environment variables here to avoid any issues if I ever move things around:

One thing to note here is I'm referring to the x64 version of the prerequisites because my game is 64-bit.

That’s it! Go ahead and build the Solution and you'll get a nice little EXE under your bootstrapper project \bin\Debug\. (Or \bin\Release if your building a release configuration).

Here's what the results look like for me:

And then when that completes, the game is installed.

You can see my game is now under Program Files and is listed under Programs in the Control Panel.

Whoever came up with that saying sounds sadistic. Or they had a really tough job.

Well, PAX was fun I got a chance to talk to a few developers and see great indie titles like Solitairica. Now its my turn to get to work. For my first chore I sat down to update the menu's in my game. I had a need to setup a resolutions option menu and thought "hey this'll take me a few minutes". I was of course, very, very wrong.

I had a button template already and wanted to reuse it so I gave it it's own widget class and included it in my other Menu's. So far, so good. Now I just needed to ask the engine for the list of supported fullscreen resolutions and create some buttons the player could click to select that resolution. Getting the list was easy enough, but setting up a generic callback to pass to the button template was not.

UE4's Blueprints are great but every once and a while it is neglected and something like passing delegate references in Blueprints isn't there (it's there in C++ of course: see this answer). I decided to create my own approach because this seems like something that will come up again, even outside UMG,  so I looked at my options. Event dispatchers seem to be the recommendation from others, but it just seems clunky for this particular job.

I ended up using an Interface with once function. I called my interface, you guessed it, ISimpleButtonCallback.

The callback has an index so you can have the same button templates accepting different functionality in your calling blueprint or menu. You can set the button callback via a function SetButtonClickedCB so that when the button is clicked the interface type of the reference object is checked and an Interface message is sent with the button's text & index parameters.

To use all of this in my resolution menu I dynamically create the buttons I need, add them to a vertical box, set their text, and pass in my callback. In this case the callback in a reference to self because my ResolutionOptions Blueprint implements ISimpleButtonCallback.

Since my Blueprint implements ISimpleButtonCallback (look at your Class Settings) it means I need to give it an implementation so it does something when the callback Interface message is sent from the button. In my case I have 2 uses: one gets the button text and sends a console cmd to set the Resolution which is my default behavior; the other is a Back button that takes the player back to the Options menu.

Though it required a little bit of work I think this design pattern will be useful for other cases where I essentially want to set a Delegate / Function Pointer on the fly. For UMG this was helpful in creating a system closer to the Android / iOS API's I've used for UI's in the past.