Space Dust Studios

Developer Blog

Tag: unreal (page 1 of 2)

Space Dust Racers coming to GDC 2015 + latest video

As our friends at Unreal Engine recently announced, Space Dust Racers is coming to GDC March 4-6! Here’s our latest trailer showing what kind of mayhem you can expect in the GDC build.

We’ll be at the Unreal Engine booth, #1024 South, along with several other awesome developers using Unreal Engine. We’re looking forward to battling it out with you on Clawtopia!

Space Dust Racing – Gameplay Video – September 2014

The latest gameplay footage for Space Dust Racing is here! This video represents four months of total development time, and shows 6 players over 5 physical locations battling for supremacy in Clawtopia. Are we on the right track? (Ha!) Please help us spread the word by sharing with friends, and as always feel free to leave some feedback in the comments.

About Space Dust Racing

Space Dust Racing is a work-in-progress vehicular combat party game for up to 16 players, supporting local and online multiplayer. Cartoon competitors race on exotic planets, using weapon powerups to knock each other out and score points. Those that fall behind are eliminated until one survivor remains. Rounds repeat until a winner prevails!

Space Dust Racing (Unreal Engine 4) Arcade Vehicle Physics Tour

I’ve had a few people ask how we’re approaching our vehicle/car/kart/buggy physics (whatever you want to call them) for Space Dust Racing within Unreal Engine 4.

In this video I run through the general principles at a high level (no code, blueprints or formulas) to achieve our bouncy cartoon vehicle handling.

I start with a simple collision box, then add suspension, accelerating and braking, turning, traction, tweak the center of mass, add a visual mesh on top and finally show the end result.

The same principles can be used in any game engine with a physics component (Unity 3D, CryEngine etc). I hope you find it interesting!

Development Update – July 2014

Progress is continuing at a rapid rate with the gameplay, environment and vfx improving every day. Also – if you missed our last post showing early game-play footage, be sure to check it out here, but bear in mind the game looks a lot better now!


We took our Space Dust Racing milestone build to the IGDA Melbourne pitching night and got some great feedback. About 30 people wandered over and joined in the 4-player mayhem, and offered some great suggestions on things we could improve and their favourite elements.


Playing Space Dust Racing @ IGDA Melbourne meet, complete with scrappy piece of paper showing controls affixed to side of laptop

New features we’ve added include the ability to ram other vehicles off the track, auto-aiming laser sights for the turret gun, slow but sneaky homing on the smart missile, a passive shock shield which protects you from attacks and also acts as a melee weapon, and a more forgiving revision of the vehicle physics to ensure players remain in the game for longer. And thanks to Unreal Engine 4.3’s splines, we’ve added spline data for the race track, which has finally allowed us to create a silky smooth camera behaviour and easily give the AI racers some rudimentary knowledge of the track.



Latest Clawtopia shot

Clawtopia is feeling more and more like the alien tropical island we imagined in the early concept art. Pops has been heading up the creation of the terrain sculpting, plant creation/placement and it is really coming to life. As final gameplay adjustments are made to track and obstacles, the remaining white-box assets will be replaced with final art and textured mesh.

SDS Plant Concepts

Plant concepts for Clawtopia


The concepts above as fully realised assets

The vision for Clawtopia was that it should feel familiar but also alien, and that vibe is really starting to materialize. Obviously the enormous crashed flying saucer helps a bit!

SDS Saucer Ortho

Crashed Saucer production drawing


Clawtopia is Hermans’ home world, so unsurprisingly Herman will be the next Space Dust Racing character to be built. However… Grigs is first building out the geometry for his vehicle, which in keeping with his character is a fishy inspired hovering jet powered skiff (phew!). Several rounds of concepts were  created from which the final design was refined to fit similar proportions to Sarge’s tank – you can see the early progress below.

SDS Hermans Skiff

Concept / Ortho / Mesh creation process

Well… that’s it from us for this development update. Is there any part of the game you’d like us to talk about? Leave your thoughts below in the comments.

Unity vs Unreal: Choosing an engine for Space Dust Racing – Part 3: Source, Community and the Future


In case you missed them, you can check out the first two parts of Unity vs Unreal: Choosing an engine for Space Dust Racing at Part 1: Adventures in Unity and Part 2: The Unreal Deal.

Source release

Before I go any further, I have to talk about the release of the source code. In combination with all of the features Unreal Engine 4 offers, I believe having access to the source in such an accessible way is one of the most important, advantageous and exciting breakthroughs – it pretty much benefits everyone involved, even if you don’t use it directly.

Epic’s code gets reviewed and analysed for bugs and functionality. Desired core features are discussed and/or implemented by contributors. It becomes an even more exciting engine from an academic and teaching point of view, especially for game programming courses.

As for us, we massively reduce our dependency risk knowing that we can can streamline our workflow and fix time sinks, as well as much more efficiently debug and fix any issues, be it game, engine or editor side.

It also means we are in a position that we can implement any feature we require, which removes the “the engine can’t do this, so we can’t do that” factor.

And then there is the development community…

Development community

Even though Unity has a source code license, the community in general does not have access and those who do are bound by Non-Disclosure Agreements (NDA). Unfortunately while this is the case, I think they are missing out on the advantages of a more opened source release.

Epic has stated in their legal FAQ that the EULA does not include a NDA and that everyone is able to freely discuss the Unreal Engine. This in itself is huge! But for us it is great as it means we can talk and blog about it and its source code.

“You are permitted to post snippets of Engine Code, up to 30 lines of code in length, online in public forums for the limited purpose of discussing the content of the snippet and not for any other purpose.”
– From the Unreal Engine EULA

The source release means that the development community as a whole is empowered to discuss, find and fix issues amongst themselves and therefore find solutions to almost any problem. Not only that but they can create free or paid middleware with a comprehensive insight into exactly how the engine works and interacts with their software. There is huge potential here.

We expect to see plugins or even modifications to the engine source go up on the marketplace or at least a GitHub somewhere. We will hopefully see the latest advanced techniques from SIGGRAPH and the like,  as well as community improvements to key systems (networking, physics, audio, etc).

The blueprint system helps make it even easier for non-programmers to get involved and create even more advanced cool content. With the experimental Blutility allowing you to add functionality to the editor itself.


Since there is a low entry point to the editor ($19, assuming they don’t already have a copy), it might be feasible to use the editor to mod / build content for released games. A game could provide a plugin for the editor which would allow the other licensees to build new content for that particular game, using Unreal Engine. The modded content, once released, should then be useable by any end user. If the game EULA allows it, the content could be sold – paying the usual 5% royalty to Epic. I would guess that the Epic team will probably support the idea as they can sell more licences and broaden their development community.


From the Blackjack example. Half way there, just missing one thing..

Future proofing

Although in my opinion, many key UE4 systems are ahead of the competition, they are actively improving the engine as well as adding new and exciting features. Because of the access to the source via GitHub and the fact they are continuously integrating their internal Perforce changes almost directly into the developer GitHub, we all get a sneak peek into what is forthcoming for the engine. Thankfully, they also like to talk about most of them on their Twitch streamYouTube channels and forums. Again, this helps us keep track, so that we can better schedule work on our end to coincide with progress and releases on their side.

When UE4 was first released, Linux client support wasn’t there yet but you could see it was not far off (and later came out with 4.1, with SteamOS support). However, Linux editor support was another matter. Soon enough the community jumped on board and started standing up the editor for Linux.

Even better still, Epic has now released a roadmap in the form of a Trello board for the engine development and direction in general. You can go there and vote on the items most pressing to you and your team.


Super exciting screenshot of the Trello board.


One concern for Unreal Engine I have is the frequency we seem to need to jump in and modify engine code for situations we wouldn’t expect to need to do so. While it is sometimes tolerable for team changes, it becomes a lot less ideal when you want to distribute the changes. I imagine this will become more of an issue when the Marketplace really comes to life.

An example would be that if you have a third party library you need to include into your project or into a plugin, currently you need to manage and copy the DLLs around manually after packaging builds of your game. The engine avoids this (for Ogg, PhysX, etc) by hard-coding its requirements into .Automation.cs files such as WinPlatform.Automation.cs, which has a comment that I totally agree with:

//todo this should all be partially based on UBT manifests and not hard coded

Similarly, if you have additional non-asset files such as help or HTML project files, you need to manually copy them during the deployment stages.

I hope before their store/Marketplace really kicks off that some of these issues are addressed as integrating hundreds of engine hacks or changes during updates will get quite messy.

The good news is we can solve these issues!


Miscellaneous todo comments from the source code.

Knowledge base

Another plus for us using Unreal Engine that I should mention is the number of experienced developers out there. There are plenty of engine systems which haven’t changed a great deal and have been used by many people over the years in UDK/UE3 and prior iterations – systems such as the networking/replication, basic material nodes, Cascade, Matinee, etc. This all ends up meaning it will be easier to hire or consult with people that have knowledge and experience with Unreal technologies.

Here in Australia, I know the team up at 2K Australia are using Unreal Technology for Borderlands: The Pre-Sequel! and have done so with many of their other games over the years, with a group of former staff breaking off and starting Uppercut Games – also using Unreal. I’ve seen a bunch of great tutorials from Pub Games for both UDK and now UE4. Recently I came across a couple of studios with some roots in the AIE Incubator Program such as Dancing Dinosaur Games, Daybreak Interactive and Wild Grass Games. There are a lot more game studios here doing unreal work, such as Canvas Interactive, Commotion Games, Epiphany Games, Reach Game Studios, Mere Mortal Games, Organic Humans and I’m sure there is a ton I have missed.

In addition to all of those, there are also non-gaming groups using Unreal Engine 4, such as this group here in Melbourne working on sensory therapy for dementia patients (Opaque Multimedia).

That royalty

Assuming that a game does well, in most cases Epic’s 5% cut will mean that long term Unity with a bunch of plugins would still generally be the cheaper option. But really, under the same assumption you will be laughing either way.

When starting a project, it is worth doing the research and forecasting to work out where you expect to be for your project. From the start Epic has advertised and welcomed custom licensing terms to reduce or remove the royalty, if that better suits your project.

“If you require terms that reduce or eliminate royalty for an upfront fee, or if you need custom legal terms or dedicated Epic support to help your team reduce risk or achieve specific goals, we’re here to help.”
– From the Unreal Engine FAQ

In the end

Recently on Develop I read that Unreal Engine 4 made spot #2 and Unity 5 made spot #3 in the Top Tech list. This goes to show that in the end they are both great engines, each offering its own different advantages and trade-offs.

As for us, we found that for Space Dust Racing – Unreal Engine 4 aligned just that bit better for the direction we wanted to go and decided we will give it a run for its money.

I hope you enjoyed this short series into Unity and Unreal Engine! Are you using Unity or Unreal Engine? If so, how are you finding the tech so far for your needs?

Older posts

© 2024 Space Dust Studios

Theme by Anders NorenUp ↑