Nathan recently whipped up this promotional image using a series of in-game screenshots layered together in Photoshop. Sarge sure looks annoyed at that shark missile!
Space Dust Studios
Developer Blog
Author: Michael (page 4 of 5)
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
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.
– 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.
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
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/
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!
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 2. Collaboration
Office software
You can probably get away with a cloud-based office suite like Google Docs for most of the work you’ll be doing, but occasionally you’ll need something a bit richer in features, particularly with spreadsheets and presentations. The main thing here is to be consistent – pick a standard office suite (Libre Office is a good free suite, or alternatively see if you’re eligible for Microsoft’s Bizspark program for the Office suite – thanks to reader Doolwind!) and make sure everyone is using that version. Document it as part of the team setup instructions on the wiki.
Task tracking
There are many all-in-one cloud-based project management solutions around, such as Asana, Basecamp, JIRA, Producteev.and Proofhub. But we like keeping things simple, so unsurprisingly we’re huge fans of Trello (shameless referral link) for its bare bones functionality and transparency across the team… plus it’s free!
We use Trello for agile task tracking, bug and issue tracking, items for our meeting agenda, temporary notes and instructions (when the wiki just feels too permanent), and for keeping a running task backlog (ie. stuff that’s not relevant right now, but we don’t want to forget about). In total we’ve got eight lists: Meeting agenda, Task Backlog, Temporary Notes, Michael, Nathan, Glen, Grigor, Stephen.
When we’re holding a meeting, one of us keeps Trello open and runs through the meeting agenda items. Items stay put if they’re to be discussed further in the next meeting, or move onto individual task lists as actions, or move into the backlog if we’re postponing them. At the end of the meeting, we quickly review our own task lists and the task backlog to see if anything needs adjusting, then we’re done. It’s a pretty simple system that anyone can drive, refer back to later, and it updates easily from a laptop or smartphone.
File sharing
It used to be Dropbox (shameless referral link) or bust, but now we’re spoiled for choice: Box, Google Drive and SkyDrive are viable alternatives, and there are many other open-source options around if you want to run your own service.
For internal file sharing we prefer Google Drive, because its integration with Google Docs allows us to keep our web-based wiki documents and files in the same hierarchy.
For external file sharing with partners and clients we’ve gone with Dropbox, partly because it’s a well-known (and thus perceived as trustworthy) service, but mostly because it’s dead simple to share folder links, and it also provides a rich web interface to quickly preview and download files, which is quite important when you’re sharing large videos, PDFs and images for your game.
We use file sharing for any assets that don’t need to be version controlled. If something is a source asset for a build (such as a website or a game), it lives under version control, otherwise it goes into file sharing. For more information on why this is a good idea, see section 5 (Builds) of Perforce’s white paper High-Level Software Version Management Best Practices.
We also place the binaries for important milestone builds in file sharing, so everyone has quick access to working builds for unexpected demos.
Version control
You absolutely need proper version control to develop games. Here’s why. There are many free options out there for version control, but video games are a very specific subset of software development. They often require non-technical people to commit changes, and the assets extend far beyond code, including binary file formats such as 3D models, audio, video and music. The repositories can get big, fast! So I’m going to strongly recommend the one version control that’s never ever failed me in 12 years of video game development:
Perforce. It’s the industry standard, and is free for up to 20 users and workspaces. It integrates with many game engines out of the box, and is a centralized version control system, meaning it’s simpler for artists and designers to learn how to use as there are less steps involved, plus the user interface tends to be a lot simpler than open-source alternatives. (Sorry Git.)
One great feature of Perforce is shelving. You can quickly stash unfinished local changes into a safe place on the server then revert them from your local build, allowing you to quickly task-switch and keep changes grouped together logically. Others can also review your shelved changes on the server, which is really useful for doing remote code reviews. They can also unshelve the changes as their own to continue where you left off. Other version control solutions offer similar features, but none make it quite as easy as Perforce does (in my humble opinion).
Another great feature is the ability to see other users’ pending changelists. If someone hasn’t checked their email and they’re not on IM, you’re still able to identify what they’re working on, and avoid stepping on their toes.
You can run a Perforce server on just about any platform, locally or in the cloud. I’ve got ours running on a small Windows 7 HTPC in my lounge room, mostly because we’re not ready to pay a monthly fee for dedicated hosting. It’s not the fastest connection in the world (and this is where dedicated hosting shines), but if team members do most of their big syncs overnight with a build script, you can avoid major headaches during the day.
Continuous integration
We actually don’t do this step yet (it’s on our to do list), but it’s good practice to have a dedicated build machine somewhere that’s constantly pulling down tip from version control, making all combinations of the build, and notifying everyone if there are any problems. Bonus points if it pinpoints a changelist range that broke the build and emails those who broke it. Extra bonus points if you alert users about to grab tip from version control when there are problems.
A busted build in version control, or a build littered with debug asserts, is a huge time waster for everyone. It happens from time to time, and on smaller teams it’s less of an issue, but you’ll really want continuous integration as you scale up, otherwise your team productivity is going to take a big hit. You can author a build monitor script in just about any language, but the fine details will depend heavily on the engine and tech you’re using.
Code reviews
As a general policy, we don’t allow any code changes into version control unless they’ve been reviewed by someone else. This is great for catching bugs before they make it into the build. It forces you to think twice about what you’re submitting, and to self-review before you ask someone else to take a look. It’s strongly encouraged to run through your changes line-by-line before asking anyone else to take a look, if only to save you the embarrassment of accidentally code reviewing (or worse, checking in) debug code.
Check-in descriptions
It’s tempting to skip writing up proper changes for version control, but the bigger a project gets, the more likely you are to start digging through file histories. Nothing is more infuriating than coming across changelists that touch 34 separate files with the changelist description “LOL refactored!! #yolo”. Create a check-in description template, with a checklist attached, and enforce the template for all code checkins. Future you will say thank you. Here’s ours for reference:
[Project Identifier] One-sentence summary More detailed summary of the changes. A short paragraph is ideal. <Optional: Bug/task ID and URL to project management software> Built: <which profile did you build? debug/release etc.> Tested: <which level did you test?> Code review buddy: <who did the code review?> Check-in checklist - delete this section when done: - Reconcile offline work (ensure no files are missing from the changelist). - Add a one-sentence summary to the top of any new source files with author and date. - Ensure all new functions have sensible asserts for parameters. - Ensure any non-obvious code is commented appropriately. - Are there any code smells? Refactor and re-test before checking in, while it's still fresh! - Is there more than one logical change in this changelist? If so, split it into two changelists before checking in.
Desktop build helper
Beans, the Space Dust Studios desktop build helper.
Meet Beans, the Space Dust Studios desktop build helper! He’s an abomination of this Python script, which we’ve re-appropriated to handle all of our repetitive tasks and actions.
A system-tray build helper like this comes in really handy as you move through production, mostly for the time and stress it saves on performing repetitive actions, particularly for content creators who may not have the programmer know-how to automate their own tasks.
For each project, Beans can clean the project folder out, re-sync from Perforce, nuke it from orbit (it’s the only way to be sure!), and rebuild code solutions. He can also batch operations together, so you can set and forget him, then make yourself a cup of tea or retire for the evening. Beans also contains shortcuts to commonly used programs and web bookmarks, and hooks into the Windows Remote Assistance tool, which means we can easily remote desktop into each others’ machines when we’re experiencing technical troubles and need someone to hold our hand.
Obviously there’s lots of potential with a build helper to make everyone’s day-to-day lives easier, so it’s good practice to regularly ask team members what’s making them want to die in terms of the pipeline, and seeing if there’s easy ways to automate repetitive actions within the desktop build helper.
Beans has a lot of room for improvement. He’s lacking a command-line interface for scripting, and he doesn’t notify us about broken builds. But these can come later… to start, aim to make the lives of content creators easier.
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!
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 1. Communication
Phone numbers, personal email addresses, social pages
Let’s start with the basics. Make sure all team members have each other’s phone numbers, personal email addresses, and that you’re all friends on Facebook/Twitter/Google+/whatever. The goal here is redundancy in case your company communication channels go down. It sounds obvious, but you’d be surprised how easy this step is to overlook when you’ve been working in the same office for years.
Work email addresses
Once you’ve chosen your company name, buy the domain and arrange web hosting. This is the most expensive part of the whole operation, coming in at around USD10 per month. Set up a work email address for each team member. I’d recommend going with a fully hosted mailbox over an alias, as this will allow you to send and receive email directly from the work address without your personal email showing up anywhere in the message header. It’s not a great idea to email Sony about bringing your game to PS4 from steve@yourawesomecompany.com via hotpantsfan_1988@gmail.com. With a fully hosted mailbox and some fiddling, it’s possible to configure your personal webmail account to send and receive through the work account transparently, so you can check your mail in one place without this happening. Remember to test it out!
Public email addresses
While you’re here, now’s a good time to set up some public email addresses for your company. You’ll want a general public contact (eg. contact, info, pr) and a business development contact (eg. business, bizdev, bd). These can just be aliases for work email addresses, but it’s good having them separate to control spam, and to give you the flexibility to change which team member they forward to down the line.
Team mailing lists
The next step is setting up an internal team mailing list, so your team can easily have discussions and share progress with each other. Your hosting provider should have a mailing list manager such as GNU Mailman that can do this for you. Pay careful attention to web security here, as many mailing lists create publicly accessible archives on your web server, or append administrative links to the bottom of every email. Also make sure only approved email addresses can use the list.
To start out you’ll probably just want one list for the whole company, but you may find it useful later on to allow different projects and departments (art, code, design, QA etc.) to have their own mailing lists.
Team wiki
You’ll want somewhere to store permanent information accessible to the whole team. We started out using MediaWiki, but eventually we migrated to Google Docs as it supports concurrent editing during meetings, and since we also use Google Drive for file sharing, this allowed us to integrate our wiki structure directly with our file sharing structure, which became very important once we started dealing with file attachments and assets from accountants, lawyers, publishers and so on. MediaWiki allows you to upload files, but it’s pretty clumsy in comparison to something like Google Drive.
Once your wiki is up, you’ll want a section for the business, and sections for individual projects. Store a company address book for all internal and external contacts. Store information for new hires, such as project setup instructions and an overview of your team tools and processes. A company password list is also essential for keeping things like Facebook and Twitter login details, and should itself be protected with a master password. The wiki is also a great place to keep track of expenses until you go with a more robust (and expensive, eep!) accounting solution like Xero. At Space Dust Studios we also have a time tracker spreadsheet to see how long each person is spending on individual projects, which we can use to figure out revenue sharing, and who decide who needs a holiday the most.
Update (1st May 2014): Jojo asked for clarification on how we use Google Drive/Docs as a wiki. First create a Wiki folder in Google Drive, then right-click and share it with your team members, giving them full access. Now everyone has access to all new documents created within this folder. You can treat each document as a wiki page by using headings and inserting a Table of Contents at the start of each document. If you click a heading in the Table of Contents, it provides a link popup. You can right-click this link and paste it in other documents, and everyone with access to those documents can use those links to easily jump between them. You can share files in the same way. Now you’ve got all the benefits of a wiki, with all the goodness of group editing and automatic synchronization with your Google Drive desktop folder.
Team calendar
For anything time-related, you’ll want a cloud-based team calendar that’s easily accessible from laptops and smartphones. We use Google Calendar for marking important milestones, meetings, and blocking out holidays and time off. If you’re using Trello (shameless referral link) with the Calendar power-up, you can merge Trello’s iCalendar feed into your Google Calendar feed to show tasks with due dates.
Instant messaging
IM is an essential communication channel for quick informal chats. Fortunately almost every web service has chat built in, but we prefer Google Hangouts because it keeps a searchable record in your Gmail history, and you can still message people that are offline. Formerly two products (video chatting and Gmail Chat/Google Talk), Google Hangouts now has a desktop client available for Mac/PC, as well as native clients for iOS/Android. Really though, your IM choice doesn’t matter too much as long as everyone agrees to use it.
Update (1st May 2014): @tenpn raised an excellent point that not all IM clients are equal. Important features to look for include automatic startup with your OS, status indicators (online/away/do not disturb), the ability to create group chats and chat rooms, history, and the ability to mention someone to get their attention. A great candidate for this is Slack – a cloud-based group chat solution similar to XMPP/IRC, but with more bells and whistles.
Daily “stand-up” emails
If you’re not familiar with a stand-up meeting, the basic idea is that every morning, the whole team has a standing meeting (to help keep it brief) in which everyone runs through their tasks for the day. This is a useful routine for keeping everyone in sync and it helps catch potential conflicts early.
In practice, there’s many problems with daily stand-ups. They often run too long despite the best intentions. They eat into the most productive part of the day for many developers. They’re synchronous: everyone needs to be there for them… how pre-internet! If you set the meeting too early then some people will be late. If you set the meeting too late then some people will be burning time avoiding real work until the meeting is done. Plus if you don’t have an office, where do you meet?
We started out doing daily stand-ups as video conferences, but found these took up far too much time, just like stand-ups in real life. So we came up with the idea of an automated daily stand-up email instead.
At 9AM every workday, an email gets sent out to our team mailing list. It contains the following information:
- a countdown to the next milestone and all upcoming milestone dates,
- a link to our business and project time tracker document,
- three questions to answer briefly:
- What have you done since the last email you sent out?
- What are you working on next?
- Is there anything blocking you or that could affect others?
Replies are encouraged to be short, so this usually only takes a minute or two of your time. But more importantly, you reply whenever it’s convenient to do so. This serves the same purpose as an actual stand-up meeting, but without the time wasting and mental derailing of a synchronous meeting. Plus as an added bonus, you’re free to continue discussing issues in excruciating detail over email.
This system works really well when there’s clear long-term direction for the team, such as during a production cycle. But we found it inadequate when we were dealing with unfamiliar tasks, such as preparing for our first GDC trip and arranging meetings with publishers. In these situations, we’d switch back to a daily video conference instead, as we needed the back-and-forthing of conversation to figure out the best plan of attack. Be aware that you’ll need to adapt your processes regularly to fit the needs of the team.
Video meetings
Whether you’re doing video meetings daily or weekly, make sure you’ve all got decent internet connections and reasonable webcams (or just use your smartphones and tablets). If you’re on a budget I’d go with Google Hangouts as your video chat client, as it allows group video chats and screen sharing for free, but if you can afford it I’d recommend a premium Skype account as we’ve found the audio and video quality to be superior, plus it appears to be more reliable in general, and most third parties seem to prefer it.
Video meetings are expensive in terms of time (just like real meetings), so use them sparingly. To avoid wasting too much time, appoint a meeting chair and let them drive the meeting agenda to produce clear actions at the end of the meeting. For all their downsides, video meetings are a great way to nut out tough problems, figure out longer-term objectives, and build more personal relationships without the need for pants.
Physical meetings
No matter how good your HD webcam is, there’s still nothing like a physical meeting; cabin fever builds quickly when working remotely! A physical meet-up allows you to step outside of your normal work environment, play-test your game together, brainstorm with coffee and alcohol, re-focus your team vision, and build morale in a way that simply can’t be done remotely. Time-wise these are the most expensive meetings as everyone needs to travel somewhere, so try and do these rarely. Once a week or once a month feels like a good frequency for us, depending on how badly we feel we “need” it. We knew each other well before we started, but you may need more physical meetings when bringing new people onto the team.
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!
© 2024 Space Dust Studios
Theme by Anders Noren — Up ↑