Space Dust Studios

Developer Blog

Tag: game development process (page 2 of 2)

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!

Tools and processes for remote game development – Part 2: Collaboration

Michael's new desk at Space Dust Studios.

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.

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!

Tools and processes for remote game development – Part 1: Communication

Michael's old 'AAA' desk at EA.

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!

Intro-DUST-ions? No, that’s definitely not working.

Hello and welcome to the Space Dust Studios game developer blog! I’m Michael Davies, Director & Lead Gameplay Developer, and perhaps the best place for me to start is by introducing who we are and the purpose of our dev blog.

Space Dust Studios team photo

Meet the Space Dust team. Left to right: Nathan, whats-his-face, Grigor, Glen, Stephen.

Space Dust Studios is made up of five senior game developers who have been working together over the last decade at a variety of ‘AAA’ game studios. We’re a mix of artists, musicians and programmers who were fortunate enough to work together on popular gaming franchises such as Battlefield, Need For Speed, Dead Space, Tomb Raider, Burnout and Silent Hill. We’ve developed for virtually every gaming platform since the original Xbox and PlayStation, and constantly refer to ourselves as veterans, despite being in our 30s.

In 2013 we made the decision to go independent as a game developer studio. The aussie gaming scene was having a rough time with many studios closing or making huge cutbacks, and we were directly caught up in the turmoil. A lot of great talent was heading overseas to greener pastures, but we didn’t want to uproot ourselves for our careers one more time. We saw there was an opportunity to take control over our situation by starting our own studio.

Our plan is to build ‘AAA indie’ original IP for the world stage, luring back top talent from overseas in the process. It sounded a lot less like marketing hyperbole when we were talking about it over coffee.

Space Dust Studios logo

Our fancy pants logo.

We’ve spent the last year getting our company and projects up and running, and have completed pre-production on two original IPs. We can’t talk about the second title yet as we’re still negotiating with potential investors, but the first title will be the focus of this development blog, from inception through to final release.

Space Dust Racing is (and here’s the elevator pitch!) top-down galactic party racing mayhem. It’s our love letter to couch co-op party racers such as Micro Machines, Mashed, Circuit Breakers, Crash Team Racing and Mario Kart. But we’re not just rehashing the same old experience, we’re making something… bigger. In fact it’s so big, we’re having to build custom tech that’s never been done before in a game (as far as we know). We’re looking forward to talking about that some more in future posts, unless we can’t get it working, in which case we’ll be deathly silent on the matter.

Film Victoria logo

We’re getting started on the PC prototype and vertical slice now, thanks to the generous support of Film Victoria’s “Screen Development – Games” program. We’ve decided to make this a transparent process (hence this blog) for a few key reasons:

1) We want the community to get involved. We want to show you all the cool stuff we’re building, and get your feedback and suggestions while we can still act on them. Good ideas come from everywhere, and we’d be fools to ignore them! We encourage you to leave comments on these posts, and to email us your thoughts directly at info@spaceduststudios.com.

2) We want to share some of our hard-earned insight into making games. We’ve been part of some spectacular failures, and have learned the hard way how to do things “less wrong”. If you’re a game developer, hopefully some of that experience will transfer across and you can avoid some of the pitfalls we’ve fallen into on prior projects.

The five of us will be talking about various aspects of the development process in this game dev blog. We’ll try and cover everything that’s going on internally, from creative decisions through to gameplay, art style, technical notes, business stuff, workflow processes, and office gossip. Hopefully we’ll all learn something, and at the very least I will enjoy the catharsis. You don’t know me. None of you do!

What area of game development should we talk about first? Let us know in the comments!

Newer posts

© 2024 Space Dust Studios

Theme by Anders NorenUp ↑