We at Rusto have just released Spareware on Xbox One on 18th of March 2016. The development of the title started back in 2014 by the three owners of the company. So how did we get here & what do we plan to do now?
You probably should check out the trailer for Spareware to get an idea what we are talking about:
Not interested in our history & want to see the Successes & Failures? Scroll down!
Rusto has been around as a game development company since 2011, but our forays into the mobile space didn’t really make us profit so we had to rethink our gameplan. We worked on subcontracting & University projects for a while full time to recoup our losses when we first started to build up what would later become Spareware.
The basic systems for Spareware were born one small piece at a time. The progression system, adventuring in procedural levels, dual wielding weapons, wacky co-op & modular characters were something we had tested on different prototypes. The parts didn’t really come together until we came up with the current concept for Spareware in 2014.
Due to financial limitations we couldn’t start working on the game full time until right away – so we poured our evenings & weekends into refining the prototype to see what kind of game it would really turn out to be.
Initial Kickoff, 3/2014 to 6/2014
To save on expenses, we rented a 100m2 apartment where I could live & the team could work in. For some reason, the renting prices of the rural Kajaani are relatively high - especially for office spaces in accessible locations.
Working for hire allowed us to save enough funds to get the necessary licenses & hardware for full on development. The odd jobs & the project we worked on at the University allowed us to try out some new techniques on procedural generation on somebody else’s payroll - which would end up saving time once we started our own full time development.
The local game development community in Kajaani (Finland) helped us get old computers basically for free (yes, they were crappy but better than nothing) to kick things off. Having a wide variety of artists available for hire locally helped us deliver quality looking products to our subcontracting clients. It’s a lot easier to work with someone you can actually get to the office physically instead of communicating over the internet - possibly even through different time zones.
Artists arrive, 7/2014 to 1/2015
After finishing our subcontracting gigs in the summer of 2014, we still held our jobs at the University to keep a steady flow of income coming whilst we worked on the core mechanics of the game. Most of our effort at this point was focused on trying to get the procedural level generation & dynamic AI integration work together well. Apparently just imitating the excellent AI system from Left 4 Dead & ‘making a few tweaks’ isn’t as easy as it sounds if you are smacking it into a procedurally generated world.
During the early summer we also hired some artists to work on the visual side of the game as our Core team at that time consisted of a design / business fellow (me!) & two technical guys. We could’ve done the art on our own - but not on the level even a console game labeled as ‘Indie’ could get a free pass on. It would’ve also meant that we had less time to implement all the systems we had planned on.
At this point we still made tests on Online Multiplayer, but we decided to ditch that due to the small size of the team & meager budget. This is something we would love to update to the game, but it would be a huge piece of work. We spent way too much time on this & should’ve realized the vanity of it earlier.
For the latter part of 2014, we worked on Spareware when our jobs at the university allowed and made real progress killing some concepts that turned out not working & implementing some that we had not thought of previously. At this point, the artists worked on our office part time when we were working at the University - a solution I wouldn’t recommend due to the difficulty of maintaining communication & art style. We also ran to some trouble keeping our artists, but more on that in the failures section.
Getting ready for the pitch, 1/2015 to 7/2015
In January of 2015 our contracts with the University were up once again – which was not a new thing as they usually hired us for a few months at a time for different projects. I think we had had four to six separate contracts during our 1,5 year stint at the university – talk about job safety!
We decided that now would be a good time to start focusing on finishing Spareware & establishing a timeline for release. The game was already in a pretty good state to pitch for [email protected]
That plan was delayed by a few weeks when our two programmers had to return with an extension to a previous project at the University - but it paid well so a little delay was deemed acceptable. During this time I personally held a course for the University’s students about Basics of Game Production. In addition of giving a nice boost to my bank account this allowed me to get to know the rising stars of the local industry (Hi guys!).
After these little misadventures, we set our eyes on delivering Spareware for [email protected]’s approval in early April - which we managed despite a few long nights. When waiting to get our loan application approved by the wonderful Finnish Finnvera, get paperwork sorted, devkits delivered etc. we worked on another small project for the local university. There seemed to be no end to small projects!
Yes, most of Spareware’s development was funded by money earned from working with the local University. A wonderful source of money. The latter part was funded by a loan.
Final Crunch, 8/2015 to 2/2016
After finishing the last University project we relocated to a new office where the three owners could live. This helped us keep the costs low & the final development grind for Spareware began in the earnest. There were no major hitches at this point, as we had solved most of our problems already - it was just testing, iterating & adding more art & features.
Our launch date was initially set for January – but after reaching the ship date we realized that the game needed some more flesh & polish on its bones. So we did a few quick sprints to sort that out & gold we were!
What went bad
- Using artists as a hired work force without extra incentives bit us in the butt, when our most senior artist responsible for the initial design direction left the company mid project (which was completely understandable for him). At this time we were still working at the university while our less experienced artists were alone at the office without leadership. We should not have started hiring people before we were capable of working on the game full time - even if this had pushed the release back.
- Not having a dedicated person responsible for art for the whole duration of the project also led us needing to redo much of the art & shaders multiple times. In upcoming patches we’ll improve on this by having a dedicated person responsible for maintaining the art style.
- The core teams bouncing between projects really broke the flow of the development. Having to constantly switch between an university project, subcontracting job & Spareware can be seen in the quality of all these projects. All of them shipped & are most of all functional, but they could’ve been a lot better if we’d focused on a single project at a time. This is most evident in Spareware as it was a long project whereas the others were only a few month long spurts.
- Having the Designer, Producer, Audio Guy & CEO be the same person really hurt us on the project management side. The lack of a dedicated game designer combined with the lack of artistic focus led to things being quite hectic with no producer to look after them. Reviews that should’ve been organized were not. This was additionally made harder when we had to juggle with the changing schedules of the part-time workforce, university jobs & my travellings to different events & conferences. We’ll definitely try to have a person that is continuously present & checks that the project proceeds on a steady pace & just deals with problems - or alternatively a dedicated game designer.
- Code reviews, oh by the dark gods we need code reviews. Also art reviews by the team on a weekly basis - especially if we do not have a dedicated Art Lead to handle this.
- Early on in the project we were considering doing online multiplayer for the project which ended up wasting a lot of time. The vanity of making online multiplayer with our budget should’ve been clear from the start.
- Buying packages from asset store instead of straight away doing our own to fit our own custom systems. The packages by themselves were good, but not really compatible with our procedurally generated systems. This ended up taking a lot of extra time as we first tried integrating the packages, gave up & implemented our own systems.
What went well
- Despite the insane hours put into the game, everybody managed to be quite civil & no dead bodies have been found as of yet.
- Good communication between the core team allowed us to test features fast & make quick decisions on things - living in the same apartment with your team does have some benefits. Now if we only had maintained that quickly iterated code properly afterwards…
- [email protected] was wonderful for us & the implementation of platform specific systems was a breeze.
- Most of all, we have shipped a game that is an exciting top-down shooter with a 4-player local co-op for Xbox One! Go check it out as we work on some patches for it!