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: Llopis and Friginal's Casey's Contraptions
View All     RSS
September 21, 2019
arrowPress Releases
September 21, 2019
Games Press
View All     RSS







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


 

Postmortem: Llopis and Friginal's Casey's Contraptions


June 22, 2011 Article Start Previous Page 3 of 4 Next
 

5. Enough Development Time

From start until launch, Casey's Contraptions was in development for eight months. That seems like a long time by iOS standards, although more and more successful iOS games are starting to take that long.

Our initial plan was to ship the game by Christmas. It wasn't based on any rigorous estimating, just an off-the-cuff estimate. It just "felt" like we could be done by then. Obviously we were wrong.

Taking the amount of time that we did was a very positive thing. We didn't really waste much time, it's just that the game needed that amount of time to mature and get to where it is today. If we had chosen to ship it earlier, the final product would have suffered significantly.

One of the hardest things in a game like Casey's Contraptions is making interesting levels. Having this amount of development time, with a working game editor since the very beginning, allowed us to make a lot of levels along the way.

Looking back at a lot of the early levels we made, they were laughably hard and not that interesting. After several months, were able to develop a sense about what made good levels and what the appropriate difficulty was.

Having enough time allowed us to make fairly fundamental changes to the game design when something wasn't working. For instance, initially each level had three different goals you could achieve. Depending on the number of goals you accomplished, you earned a bronze, silver, or gold medal. It quickly became apparent that players were extremely confused by the three goals and weren't able to keep them straight.

We changed levels to have a single goal, but since we still wanted to have some replayability beyond "solving" a level, we added optional stars you could collect by touching them with any item in the game. The first star would be very easy to get, the second one a bit harder, and the third one would require some serious thinking.

That was a huge improvement, but then we discovered that most players expected to get all three stars in their first playthrough, and would stubbornly keep playing the same level until they got them all or quit in frustration. That prompted us to change the stars yet again. This time the difficulty of getting them was tied to the overall level difficulty, so players could easily get all three stars in the early levels. We're very happy with the final design, and we would not have gotten there if the project had been rushed.

We also gave ourselves sufficient time at the end for polish and style. Polish isn't going to make the game design any better, but it's going to contribute a huge amount to first impressions. Every animation, sound, and particle effect becomes really important in those crucial first few seconds with the game. On a mobile platform, polish becomes even more crucial. If your game doesn't immediately engage the player, there are lots of other things they can shift their attention to.

What Went Wrong

1. No Simultaneous iPhone Launch

The initial prototype of Casey's Contraptions was running on an iPhone. While it showed a lot of promise and it was fun to assemble contraptions even that early on, it was clearly begging for more screen space.

The iPad was the obvious platform of choice. Its large screen can display very nicely detailed graphics, and allows for very natural, direct manipulation of items. It was a perfect fit for Casey's Contraptions.

Even so, while there are a lot of iPads out there (14 million), the iPhone and iPod Touch are the undisputed kings of the App Store (about 185 million devices). Especially for a game that relies on the social component, getting a critical mass of users playing at the same time, sharing solutions, and sending levels is very important. We definitely stormed up the iPad charts, but that still left the majority of iOS users not being able to purchase our game.

Why didn't we wait until we had the iPhone version to launch? No particularly good reason other than we were itching to get the game out. We also had no idea what kind of impact a strong launch would have on our servers, so the idea of an iPad-first launch seemed like the way to go. In hindsight, we would have been better off waiting to launch both versions at the same time (or almost the same time, maybe a week or two apart at most).

To make up for this, we're planning on making the iPhone release a second launch of sorts: we'll make the iPhone version coincide with a new game update that includes a lot of new content (for free for people who already bought it), and we'll try to repeat the same strong launch we had on the iPad. The idea is to get everybody who's already bought the game playing again, along with all the new iPhone players, and create that critical mass.

2. Butting Heads Too Much

We make the perfect two person team: we have complementary specialties, but we also have a lot of overlapping skills. We also seem to always approach things from opposite ends: aesthetics vs. usability, performance vs. gameplay, simplicity vs. interest, uniqueness vs. familiarity, or tea vs. coffee. That is actually a really good thing and the success of Casey's Contraptions was in no small part due to our combination of personalities and skills.

There is, however, such a thing as too much of a good thing. We are both very stubborn and it will take a lot to convince us to see things in a different way. There were some times during development that we spent more time debating one point than actually implementing it.

The fact that we're working remotely didn't really affect most of our day-to-day development, but it definitely made hashing out these situations significantly harder, dragging them out for far longer than they should have. This was also the first time we were working together on a significant project, so it made resolving those situations more difficult. Now that we've gone through this first project, we'll hopefully be better equipped to handle similar situations in the future.

3. Unnecessary Rework

Rework is a necessary part of a creative process. You're unlikely to get everything right in the first draft of a text or a music composition. That's even more so the case for game development, because there are so many parts interacting with each other. Not only is it hard to predict the exact final outcome, but even if you could, you often don't know exactly what you want until you've seen one version of it.

Just about every screen and every item in the game went through several revisions of art, behavior, sounds, or layout. There's no doubt that every revision made them better. However, we had a few parts of the game that we had to revise a few too many times. This was mostly in some of the UI screens, like the now infamous "level completed" screen, or the look and positioning of the in-game menu, which we must have gone through at least six or seven complete redesigns.

We believe that design doesn't just flow one way. If you want the best final product, you can't just decide on the functionality of some user interface (or any part of the game for that matter), implement it, and then give it a pretty face with some graphics. Both the implementation and the graphic design will actually feed back into the functionality of the UI. Once you go around this cycle a few times, you can zero in on a very strong design, both from a functional and a design point of view.

The problem comes when you go around that loop too many times, or when the loop doesn't converge into a particular design, but keeps shifting around. That was often caused because we were fuzzy on some of the details, or when we were forgetting about some particular feature that had to be reworked into the design.

Some other times feedback from our testers made us realize that a screen wasn't clear enough as we had designed it and caused us to rework it. As tempting as it was to push through and call it good enough since it was already completely done, it was always the right decision to go back and re-work things as needed.

For example, at the beginning of each level Casey explains what goal you need to achieve. This screen seemed straightforward enough, except that the version we had early on was blocking the view of the level while it was up. Our testers complained it was hard to remember what you had to do without seeing the items it was referring to at the same time, so the final design shows Casey's dialog along the bottom of the screen, and the goal items are even circled with a marker.

We can alleviate this problem by iterating on particular pieces of UI or the game in smaller cycles, without taking each one to completion. Instead of starting by completely implementing a screen, or completely creating a perfect mock up with all the graphic elements, we need to start by laying out a screen with simple boxes and buttons and implement the basic functionality.

Then we can make a first pass at a real layout and some graphical element, implement some of the new functionality and animations suggested by that, and continue iterating until it's done. We got much better about this in the last third of development, and it's something we want to carry forward to future projects.


Article Start Previous Page 3 of 4 Next

Related Jobs

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

Lead Environment Artist
HB Studios
HB Studios — Lunenburg/Halifax, Nova Scotia, Canada
[09.20.19]

Experienced Software Engineer
University of Exeter
University of Exeter — Exeter, England, United Kingdom
[09.20.19]

Serious Games Developer
innogames
innogames — Hamburg, Germany
[09.20.19]

PHP Developer - Tribal Wars





Loading Comments

loader image