Space Dust Studios

Developer Blog

Page 5 of 6

Interview: “Veteran Developers Gone Rogue” – Team Space Dust

Xsolla Blog

Recently our friends at Xsolla interviewed us about our studio background, company vision, and where we’re headed for the future. Full interview with Michael below.


“Our generation grew up with couch multiplayer. Crash Team Racing, Mario Kart, Micro Machines and Mashed were some of our favourites,” – says Michael Davies, Lead Gameplay Developer of Space Dust Studios.

Conveying a very relatable message, Michael shows that inspiration can come from many different forms, even sprouting from a nostalgic aspect that was once part of our lives.

Lead Gameplay Developer, Michael Davies is 2nd from the left

Lead Gameplay Developer, Michael Davies is 2nd from the left

We at Xsolla had the chance to recently interview Space Dust Studios Lead Gameplay Developer, Michael Davies, and see what he and his team have been excitedly producing including coverage of their newest unreleased game, Space Dust Racing. Below we’ll move right into the interview question and answer session with Michael.

– What is your gaming background and how did you come to release a game?

We’re a team of five senior developers based in Melbourne Australia, who have worked together on and off over the last decade at a mix of AAA studios, most recently Visceral Games (Electronic Arts). The formation of Space Dust Studios was a mix of luck, timing and crisis management. Visceral Games Australia closed in late 2011, leaving many of us looking for work at other local studios or heading overseas.

After a year or two of hopping around at other studios, we realised a few things. For starters, there was a distinct lack of PC and console development happening in Melbourne, yet this was where we all wanted to work and live. Secondly, working with different teams made us realise that our experience and rapport with each other was an incredibly valuable asset. Finally, were all in a good financial position to take a risk, plus there were some amazing game engines for PC/console coming out that looked very promising. So we bit the bullet, and started our own studio.

– How did the idea of Space Dust Racing come about?

Our generation grew up with couch multiplayer. Crash Team Racing, Mario Kart, Micro Machines and Mashed were some of our favourites. Yet everywhere we looked, we saw games pushing online multiplayer, perhaps because it’s still a relatively new possibility in the grand timeline of gaming, and it’s certainly more convenient in many ways.

But Nathan found himself regularly digging out his PSX to play kart racing classics with his kids, and I was still hosting regular co-op Mashed nights with my friends, despite being well into my 30s. We did some research to see if any recent titles filled a similar gap, but most of them focused on split-screen or online multiplayer.

We decided to go all out and make a top-down party racer for a huge number of local players. We love science fiction, so we decided to go with a “brutal cute” art style that would appeal to both family gamers and core gamers.

sdr-with-characters

– Did you consider how you were going to monetize when you conceived the game?

We did, absolutely. Space Dust Racing is a couch party game which involves fast-paced rounds and (probably) lots of shouting. Because of this, we wanted to keep the transaction model simple for individual players, who are most likely going to be mashing buttons to make the game start as quickly as possible, so we decided to go with an upfront premium business model. The host simply pays for the game, and the controller application is free for other players.

We’re also planning to add some downloadable content based on community feedback to give gamers some extra bang for their buck, but this will follow the same host-only purchase model. Couch co-op is great for monetizing, as guests are essentially getting a free demo of the game, and if they like it they can buy it for themselves, then host their own gaming nights, and the process repeats with their friends.

– How do payments affect how you add content to your game?

If we were making a freemium game, we’d actually be in a better position for generating content. Microtransactions are great not only because they provide a more steady stream of income, but because they also tell you what players are interested in, and what’s not working in your game. We won’t have that luxury, which is why we’re pushing hard to grow a Space Dust Racing community early, for example through our developer blog at http://blog.spaceduststudios.com. We want to get feedback while we can still do something about it.

– What sorts of payment systems do you use and what really works best for you?

We’re currently building the vertical slice for PC but we haven’t locked down our final target platforms, so I can’t say for sure. What I do know is that as developers we’re looking for an all-in-one payment solution that handles everything from analytics, reporting, easy game integration, and acceptance of all major regional currencies through to 24/7 customer support.

SpaceDustStudios01_1920x1080

Beautiful in-game artwork developed by the Space Dust team. Get hyped!

– Do you have any other projects coming up?

We do indeed! Bubbling away in the background is a concept for a more hardcore-oriented sci-fi airborne arena shooter, and we have some free HD concept art available for this at our website http://www.spaceduststudios.com. I’d love to provide more details but we’re not quite ready to push this baby out of the nest yet.

– What have you learned from your Space Dust Racing?

Our first project has taught us a lot already. You need to be organised and highly efficient as a small independent game studio, because time is scarce when you’re the content creators and the business managers!

– What advice do you have for any other developers who are interested in putting out games?

We’re spoiled for choice when it comes to game engines these days, so just pick one – it doesn’t matter which one – and learn it inside out. Get involved in as many online game dev communities as you can find, and don’t be afraid to share your ideas and ask questions, as this is the best way to learn. Don’t fall into the trap of trying to make an MMORPG for your first title. Instead, start with very simple projects like Guess The Number, Tic Tac Toe or Hangman, then work your way up to more ambitious concepts like 2D shooters or puzzle games. Leave 3D and online till last, as they’re the hardest to get right.

Conceptual 3D Mesh images of various in-game weapons giving us a small taste of what’s to come

Conceptual 3D Mesh images of various in-game weapons giving us a small taste of what’s to come

The hardcore sci-fi airborne arena shooter in pre-production will have an official announcement soon with more details to come. Keep updated on their production and news updates at http://www.spaceduststudios.com/ and make sure to stick around on our blog to read more insightful articles into the mind of game developers in this generation!


To leave a comment, head on over to the Xsolla article:
http://blog.xsolla.com/2014/06/23/interview-veteran-developers-gone-rogue-team-space-dust/

Unity vs Unreal: Choosing an engine for Space Dust Racing – Part 1: Adventures in Unity

Unity_Pri

Ahh… finally, a break from the beautiful artwork our awesome art team has produced, it’s time to break out the programmer art. I promise this short series of posts will be nice and dry, as I cover our take on Unity vs Unreal Engine, including some of the reasons why we switched from Unity to Unreal for Space Dust Racing, and also some of our experiences with both engines so far. This post may get a little technical in places, so feel free to skim!

Back in the day…

Prior to starting Space Dust Studios, the majority of our experience was working with cross-platform in-house engines. Depending on who you ask, this was both a blessing and a curse. On one hand we often wished the technology was more mature, but on the other hand we were lucky to be close enough to the underlying technology to make changes or add functionality, and were always able to solve any issues we faced.

Moving to a startup environment meant we were faced with a very different situation. We weren’t ready to licence a million dollar engine, and building our own engine did not align with our resources or goals. UDK and the CryEngine FreeSDK – while great in parts – seemed to be severely limited in the kind of rendering technology you could implement on top of them. We needed something more flexible for the type of environments and effects we were looking to create.

44554020

Unity

I had started looking at Unity 3.5 and after not too long, Unity 4 was out sporting their new deferred DirectX 11 renderer which was architectured in a way not too dissimilar to what we were used to.

The Butterfly Effect video was released at the same time and looked great. It featured their DirectX 11 rendering, with additional features such as physically-based shading, HDR image based lighting, improvements for character animation, hair, skin, clothes and other rendering features (though unfortunately many of these haven’t been released in the 4.x development cycle).

Apart from an underlying inflexible rendering core (which as far as we could tell, doesn’t allow for techniques such as proper stencil-optimized deferred decals, reduced resolution lighting, custom shadow attenuation, TXAA? and you can’t really create your own custom light types or uber lighting shaders – to name a few), there is still a fair bit of leeway for customized rendering, as you do get access to additional render targets, the ability to write shaders, you can modify a few key internal shaders, generate procedural geometry, and it has support for a native plugin system with which you can start calling on the DirectX device directly.

Unfortunately parts of the feature set seemed only surface deep. Many of the DirectX 11 features were not fully exposed and difficult or error prone to get working via a native plugin. We quickly came across the lack of support for floating point textures, 3D texture importing, limited texture addressing & filtering support (UVW), there was support for Dispatch but not for DispatchIndirect, limited support for multiple render targets (we needed 6-8 MRT’s for certain effects but Unity artificially capped it at 4) as well as plenty of bugs, some of which would make it unshippable for us without support or source access to fix them.

“We license Unity source code on a per-case and per-title basis via special arrangements made by our business development team. As this can be quite expensive, we do not generally license source code to smaller operations, educational institutions, nor to companies in countries which do not have adequate legal intellectual property protection.”

– From Unity’s FAQ on licensing source

An example would be that alt-tabbing in a fullscreen DirectX 11 deferred game would crash when returning to the game. I lodged a report with a test case project via the in-editor crash tool back in Unity 4.0.1f, then checked the issue tracker and sure enough it had been a reported issue back in Feb 2013 but is still yet to be fixed. (I did however recently see an acknowledgement of the issue in the Unity 4.5 release notes so hopefully that one will be fixed in the next release.)

Another example would be a sporadic issue on certain PC’s that meant that before even getting as far as the input/graphics configuration dialog (which happens before we are given control), it would become unresponsive… but not always.

Community

“630 thousand monthly active developers and nearly 2.9 million registered developers”

– From Unity’s public relations page

Thankfully the Unity community is fairly active in the forums (and generally just awesome), so for many of the other bugs we came across, we were not the first and often someone else had posted a workaround for the issue where possible (crashing on exit, add force oddity). For other issues, we knew we would probably need to reimplement a feature in a plugin to avoid them (XInput, I’m looking at you).

There are tons of plugins available on the asset store which have been created by the community. Some are free, some are licensed per seat and others licensed per project. To get set up comfortably, you really need to set aside a good chunk of cash for a bunch of these.

DIY

There are plenty of basic features which you end up building yourself and then share between your projects. Better tools to work with prefab hierarchies, a suitable object pooling framework, in-game debug menus and helpers to name just a few. Hopefully the next big release will start filling in these gaps.

In editor footage from an early volumetric rendering prototype built in Unity with a custom rendering extension plugin.

Due to the rendering limitations, we started crossing off features but also wrote a renderer extension plugin DLL to get around what issues we could that way. In order to set up the sampler state as required and provide the support for higher MRT’s and desired formats, we had to jump through a ton of hoops including calling through to the plugin in a fairly delicate way. It was an ongoing concern of ours that future Unity versions could cause implementation issues and would require a redesign or stripping out of features. In practice, thankfully, it made it through with only minor modifications between upgrades and we were able to strip back the plugin a bit as engine bugs were fixed. Alas, with access to the source, it would have been trivial from the start.

Overall

There were plenty of positive experiences while using Unity. It was great having diff-able text formats for assets. It was easy to get almost anything started and overall our prototypes came together nicely. Before all the big GDC announcements, I had implemented physically-based shading with planar and captured reflections in Unity, all fairly painlessly and I was looking forward to working in screen space reflections when I got back from GDC.

Footage from our physically-based shading prototype built in Unity. Flicks between two preset times of day.

I’ll leave this post here for now but before I do, I quickly want to mention that as part of the GDC announcements, Unity has announced that they are busy working away on Unity 5 (with physically-based shading and a bunch of new features). We expect it to be a fantastic release when it’s done.

Next time I’ll touch on our adventures at GDC and Unreal Engine 4.

Development Update – June 2014

Space Dust Central has been super busy since our last blog post. The transition from Unity to UE4 is complete, models are being made, concepts scribbled, tech developed and gameplay implemented… and Beans has just continued being awesome.

Networking nirvana!

Just a few days ago, Michael stood up online multiplayer for Space Dust Racing. We’re able to create and join online matches, which all came together surprisingly painlessly thanks to the mature networking support in Unreal Engine. Despite our core gameplay focusing around couch co-op, we can already see the value in having an online multiplayer build so early in the development process. We can playtest remotely, and with Skype running in the background we’re finding this is great for brainstorming ideas while we race around the track.

My my… is that a shark missile!?

Yes indeed… mounted on a giant spring no less! Grigor and Pops have been building and animating our first batch of weapon models (there are more in the works). Obviously these are the raw mesh without texture, but it gives a good indication of where things are headed! Included is an orthographic projection of the Turret Gun in the top right, continuing on from the last blog post about art process.

Weapons

Our first batch of weapon models

“Clawtopia”

The setting for our first level is Herman’s home planet…

“Eons ago, Herman’s distant relatives (simple hermit crabs) were abducted from the “Hermit Hut” pet-store by aliens with a penchant for interstellar marine biology. On the return journey they crash landed on a tropical planet we now know as “Clawtopia”. The hermit crabs survived, and surrounded by the futuristic (and slightly oozy) wreckage, they quickly evolved into the highly advanced crustaceans that you see today. Herman is their champion.”

Below are some of the initial concept sketches – we wanted to get a cool contrast between tropical island and spacecraft wreckage, and also multiple terrain types within the one level. The actual track shape is different from what you see here – these images just show thematic direction.

Clawtopia concepts

Initial thematic concepts for Herman’s home planet

Sarge and Tank (a love story)

Continuing on from our last post, you can see the original tank concept sketch, and below it the final raw 3D model. A few things changed along the way – like the tracks have been fattened up considerably, and the side of the cockpit altered so you can really see Pops’ cool character animations.

On the right are concept paint-overs showing the skins we’ve decided to go with. Grigor is continuing work on the build of Sarge and his tank, so hopefully will have some images of the final product in the next post.

Sarges tank

Sarge and his tank – concept, model and paint-over

That’s it for this post! Thanks again for stopping by to check out the development of Space Dust Racing.

As always, if you’ve any comments or questions or thoughts, please post below! 🙂

Character Design: Space Dust Racing

So far you’ve been blessed by Michael’s sultry tones offering valuable process and workflow advice for new remote development teams.

This post however, you have me – Nathan (AKA napes) – I’m the Art Director at Space Dust Studios, and while less sultry, I hope you enjoy finding out more about the process I use for creating characters for Space Dust Racing, complete from scribbles through to a 3d model.

The Brief

“Create multiple unique characters with a combative cartoon sci-fi bent.”
I intentionally went about this without any preconceptions and instead let the process drive the initial ideas. If you’re naturally more of a hard-surface/mechanical concept artist (I am), this process will hopefully loosen you up a bit too 🙂

Scribbles to Thumbnails

This is a really fun part of the process. I literally scribble shapes that have roughly the right dimensions, but intentionally don’t think too much about them. Some loose sketching and a couple of spots for eyes trigger possible ideas for forms, shapes and poses. The great thing about this process is that 1 scribble silhouette can yield multiple ideas depending on how it is interpreted. I sometimes play this game with my kids where we share a silhouette, and see what each of us makes!

The image below shows a breakdown for Piccolo Diablo, our mean moustachioed intergalactic taxi driver.

SDS-ScribblesToThumbnails

This scribble silhouette could have become any number of thumbnail characters

 

I end up doing loads of these thumbnails, most of which get discarded.

As nice or interesting forms emerge, so do possible stories for this character – good or evil, their role or where they’re from – and as the story evolves, so does the sketch which in turn adds more detail to the story – it’s a cool little circle.

Review Sheets

After I have a sheet of 10 to 15 thumbnails which have something interesting going on, I send them out to the team for a ‘gut-feeling’ review. This is without any story information – it is purely about identifying which thumbnails visually resonate well within the group – they have to feel good first!

SDS-ThumbnailRoughs

Some of the thumbnails sent out to the team – some survived… most did not!

Working up a colour concept

From a chosen thumbnail (in this case I’m going to continue using Picollo Diablo) I start working up the colour concept sketch.
In Space Dust Racing, colour is super important as our characters must have unique palettes and silhouettes, so I gather thematic and colour reference to sample from (bottom left of image).
This is also the stage where I start to flesh out detail, and sometimes things go wrong as you can see from the progression below. I started losing my way, and Picollo Diablo began to look like a cross between John Goodman and one of the Village People! I was still happy with his back-story, so I bounced the WIP out to the team for feedback, and ended up reverting back to an earlier sketch and continuing again from there.

SDS-ThumbnailToColourConcept

From a Thumbnail to Concept – sometimes things don’t always go to plan!

This process resulted in these initial character concepts below, though it’s important to note that not all of these will make it into the final game!

SDS Dust Racing Line Up

Some of these characters will miss the cut!

Prep for 3D’ifying

Generally the more detail you can provide the 3D artist, the better – ideally orthographic drawings (front/back/side), a colour concept and/or material reference.

However…we’re lucky as our senior 3D artists Grigor ‘Grigs’ Pedrioli and Stephen ‘Pops’ Honegger are really experienced (and frankly awesome not to mention good looking). They can do wonders with the bare minimum of reference. So for this next section I’m going to use a different character – Sarge!

As the colour concept for Sarge is close to front on, I provide Grigs with a rough side projection showing basic detail for his torso, posture, odd leg/hip shape and arm.

SDS-SketchFor3DArtist

The rough sketch for 3D Artist ‘Grigs’ showing the important details for Sarge.

 

A few chats here and there, and a few days later back comes this great 3D model. Sarge’s character has really transferred across from the sketches, which is awesome!

SDS-UntexturedMesh

The final un-textured mesh. Even without materials and colour, Sarge has plenty of character!

So that’s it for this post – hope you enjoyed it and please post comments below. In a future post we hope to show some modeling/texturing walk-throughs  and  best practice.

Finally – there are many ways of generating non-realistic character ideas and none are ‘wrong’. However, providing 3D Artists with the right details and clear information will always result in better looking in-game characters!

Cheers, (n)

Tools and processes for remote game development – Part 3: Security and backups

Our AutoBackup Python script.

Ahh, the corporate video game lifestyle. quad 24″ monitors, $1000 office chairs, free snacks, and beer o’clock. But when you and four colleagues throw that lifestyle away to pursue your indie game dev dreams, more often than not you can’t (and shouldn’t) rent a fancy office, because in case you weren’t paying attention, you’re now peasants and every cent counts. But with the right tools and processes, you can work together remotely on a tight budget.

In this three-part article, I’ll run through the tools and processes we use for remote game development at Space Dust Studios. Part 1 focuses on communication, Part 2 focuses on collaboration, and Part 3 focuses on security and backups. We’ve evolved this setup over the last 12 months and it’s working well for us, though we’re a team of five living in the same city, so your mileage may vary. If you’re working with a bigger team or are spread across different time zones, you may need to make some changes.

We’re always on the lookout for improvements, so please leave a comment if you’ve got suggestions!


Part 3. Security and Backups

By working remotely you’re pushing a lot of sensitive information into the cloud. It’s worth thinking carefully about security for every service you’re using, particularly if your company is going to be entering the public eye, which will also attract the attention of hackers (even if they are just 15 year olds).

Private vs public

Make sure with any private service you’re using that the information isn’t publicly available. It’s good practice to try and hack into your stuff from a fresh browser with nothing logged in, and by trying to follow internal email links on outbound emails. If you’re posting internal videos on YouTube, make sure they’re unlisted or privately shared, or better yet, upload your videos to Google Drive instead. You’ll get the same YouTube-style player without the risk of accidentally making it public on your YouTube channel.

2-step verification

Make sure everyone on the team is using 2-step verification where possible. This includes all Google and Apple services, as well as Dropbox. It adds an extra layer of security to your accounts, requiring a password and a code sent to your phone over SMS. You really don’t want someone getting into your company email archive in the cloud!

One potential gotcha with 2-step verification is travelling. If you’re attending an overseas conference or trade show, double-check with your phone company that international roaming is turned on before you head over there.

Virtual private networks (VPN) and SSH tunnels

If you’re too cheap for dedicated hosting (which we are), never expose a service on your local network (such as Perforce or VNC) directly to the web. Instead you can use a VPN to let team members log in securely to your home network, although personally I prefer using SSH as I can directly control which ports and services team members can access.

There are many free SSH servers and clients out there to choose from, although be careful of the licensing terms which may stipulate they’re for personal-use only.

Use an unusual (and high) port number for your SSH connection, instead of the usual 22 or 443, and opt for public key authentication over passwords, to prevent man-in-the-middle attacks.

Password salting

You’re going to be creating a lot of company logins for various online services, so be sure to use different passwords for each one. Prefer long passwords over short ones where possible. A simple solution for an easy-to-recall yet hard-to-hack password is to “salt” a master password: take the original password and add something different for each service, based on an easy-to-remember rule like “the last letter of the service name”. (Make up your own rule though.) Talking about password salting in detail is beyond the scope of this post, but you can read more about it here if you’re a big cryptography nerd: Secure Salted Password Hashing.

Automated backups

Maybe one day you’ll get hacked. Maybe a hard drive will fail. Maybe Google will go belly up and take all your email with them. Maybe an employee will accidentally delete the entire contents of your master server. Whatever the cause, you really need your own on-site company backup solution for disaster recovery.

The easiest backups are the ones that happen automatically. We wrote a cheap-and-nasty Python script (why am I so disparaging towards my Python scripts?) that backs up the contents of our Dropbox, Google Drive, Perforce, Trello, mailboxes, and our websites plus their MySQL databases into DVD-sized password-protected RAR files. Make sure you add a RAR data recovery record so the archive can handle some data corruption, and copy the files onto multiple physical media (ideally of different types) as part of the automated backup process.

They’re not cheap, but you can get external RAID hard drive enclosures to protect against hard drive failure. We use my personal WD MyBook Studio II, which has 2TB storage mirrored in RAID-1 across two x 2TB drives.

Off-site backups

We also create manual off-site backups to protect against fire and theft by copying the RAR files onto a USB key, then stashing that in a waterproof bag in my garden shed. It all sounds very cloak and dagger, and it is, so just roll with it and pretend to be James Bond while your partner watches on, shaking her head pitifully. Another option would be auto-uploading the RAR files to an FTP server, but our total backup size is already at 20GB, and my broadband upload speeds aren’t that great, so that’s out for us.

Restoring

It’s great to have backups, but have you actually tried restoring your data from them? It’s worth taking the extra time to do this, even if you just restore to a different location for testing purposes. Otherwise the backups are useless, and you may as well have done nothing. Iron out the glitches at the very beginning, not when you’re up the proverbial creek with the next milestone due in 24 hours.


Everything outlined above is working well for us now, but as we ramp up our team and projects we’ll most certainly need to get office space. But for that awkward period between starting your company and bringing home the bacon, hopefully the tools and processes I’ve covered here will help get your team and project moving along for very little financial investment.

 

Have we missed something? Please let us know in the comments and we’ll add it to the post!

« Older posts Newer posts »

© 2024 Space Dust Studios

Theme by Anders NorenUp ↑