Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Housemarque's Outland
View All     RSS
October 19, 2019
arrowPress Releases
October 19, 2019
Games Press
View All     RSS







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Postmortem: Housemarque's Outland


April 27, 2012 Article Start Previous Page 3 of 4 Next
 

What Went Wrong

1. Maintaining the Game's Vision

After realizing we didn't have all of the technology to create our original vision, the project lost a bit of focus and started drifting back and forth between different ideas. This drifting wasn't helped by the fact we had too many people in our meetings and they often took too long; we rarely accomplished what we were after and at times just wasted time.

We could also have done more research on old classics like Super Metroid or the Castlevania series. Avoiding them was partially intentional: not to copy directly from those games, and also not to repeat the 8-bit and 16-bit design pitfalls.

In any case, it would have been helpful to analyze the classics to see what they did right and how we could've improved or built on that. Failing to do that meant we ended up driving in circles more than we would have liked.

Both these reasons (technology and game research) ultimately meant we spent too much time on relatively simple things. We over-thought many of the enemies, and the final versions ended up being compromises.

Game structure and progression also suffered from not establishing clear enough targets from the get-go; we started building a more open, exploration-type world, but kept on adjusting it towards the linear based on player feedback, ending up somewhere in the middle.

2. Project Management

Having the lead designer also act as the project lead/producer didn't work well. A relative lack of experience in project management cross-fed to game design, and both areas suffered as a result. We talked about hiring a producer around eight to 10 months before completion, but thought it was already too late to bring someone new in. In hindsight, a producer, even at that point, would have helped.

We also tried managing design and art tasks using Hansoft, but it never caught up. Task lists were assembled several times throughout the project, but art and design team members didn't pay much attention to them. It might have been that the software required too much user input for fluid use, or it might have also been the benefits of using it weren't communicated clearly enough to the team. However, Hansoft was used with success among the programmers.

Poor communication during the first of half development and the lack of vision did considerably lower team morale for months. That partially caused certain people needing to crunch -- for three or four months. Luckily, once we got all the key gameplay pieces together the project started moving forward in much tighter pace. The last six months were what the whole project should have been, apart from the crunch.

3. Big Change in Direction During Production

Fixing a project that was adrift required a strong steering maneuver; bringing in the Ikaruga concept was just that. While it didn't deviate far from our original idea of using a special spirit mode, it changed the concept by making the skill non-consumable and removed the option to turn it off.

When the idea came up in a meeting, some 16 months before completion, it was love at first sight. We of course ended up rewriting our engine due to this, and made other smaller changes in the concept, which added to the programmer workload and introduced some delays to the schedule.

We also had to throw away most of the content done at that point and basically start afresh. Player animations were no longer valid for the new gameplay, nor were player physics and movement rules. The change also introduced new requirements from the level tools, further slowing us down.

But as gameplay and project uniqueness increased as a result, the change was for the better. It is possible the game would have never been finished had we continued on the original path.

4. Level Creation

When we changed direction that also meant we had to redesign some of the level building tools. We also had to create new rules for the levels and ended up bouncing back and forth between level requirements and level tools, creating a chicken-and-egg situation.

We used Autodesk Maya for creating our level art and design. All the tools inside Maya were done using either MEL script or Python. This enabled us to do all level-related items inside one program, but it also posed some problems.

We had no real way of dividing the work between level designer and artist, which resulted in one party having to wait for the other to finish their task, before gaining access to level files. In addition, we rewrote our level dressing tool several times, due to lack of proper design before starting the actual creation process -- those with keen eyes may notice this in two different types of texturing throughout the levels.


Article Start Previous Page 3 of 4 Next

Related Jobs

Insomniac Games
Insomniac Games — Burbank, California, United States
[10.18.19]

Sr. Project Manager
Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan
[10.17.19]

Experienced Game Developer
GreenPark Sports
GreenPark Sports — Calabasas, California, United States
[10.17.19]

Outsource Manager
GreenPark Sports
GreenPark Sports — Calabasas, California, United States
[10.17.19]

Art Director





Loading Comments

loader image