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
Building an iOS Hit: Phase 1
View All     RSS
March 1, 2021
arrowPress Releases
March 1, 2021
Games Press
View All     RSS







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


 

Building an iOS Hit: Phase 1


February 1, 2012 Article Start Previous Page 2 of 3 Next
 

The Prototype

The first prototype was made for the iPad, and it featured two castles and two slingshots, one of each of the left and again on the right. Players progressed in a series of turns including build, fire, and repair phases, as they attempted to knock down each other's castles.

Overall, the concept definitely had merit. However, the building component of the prototype needed work. The pieces were all dynamic, which was great in terms of the creative freedom one had when building, but as a consequence users were more likely to accidentally knock their own fortress down.

We deemed the "free building" feature as fun for another game (friendly.physics). Realizing this was a problem, we went back to the whiteboard and redesigned the game's flow. This time, we created a more rigid turn based structure in which only one castle would appear at a time. We also replaced the free build feature with a grid and tile system for the build phase.

There was talk of actually excluding physics altogether from the game but I wouldn't have it. As a physics junkie, I was determined to keep the physics engine running during the fire phase, even though I knew the build phase was better off without it. The only question that remained in my mind was whether the game would still be fun and feel dynamic if all the parts were just blocks on a grid.

The first thing I tackled from that point was the grid and tile system. Since I am such a physics junkie. I hate programming discreet snapped systems with no motion, so I wanted to get that part over with -- and I also wanted to see if it would work. In the end, of course, it did work, but the way in which I programmed it the game would have to translate between 2D and 3D space upon transitioning from the build phase to the fire phase, and it would have to look seamless.

The little library I knocked up included a lot of functionality for getting a pixel within the center of a rectangle from a point in space, or getting a point in space from a pixel. This wasn't too terribly difficult with Unity at my side, but it took me a few days to get something I felt was flexible enough for the future.

Once the grid and tile system was reasonable, I began creating various block types. I knew that with the game now on a grid that it would be far less dynamic. The cure, of course, would be cool block types. If the blocks themselves had very dynamic properties, the game could still be interesting, and allow players to feel creative.

The first block types were typical wood crates, and stone and steel varieties. Things didn't really get interesting until I introduced the rubber block, which actually worked more like "flubber", greatly accelerating any projectiles that made contact with it. Instantly, the game began to have some real strategy, because even the sturdiest-looking fortress composed of steel blocks could be cut in half by a rubber ricochet.

At this point, the basic gameplay flow was working pretty well, but it was only working in "Pass 'N Play" mode on a single device, where two friends could pass an iPhone or iPad back and forth. The game consisted only of build and fire modes.

One issue identified really early on was that whoever built a fort really wanted to see how the shooter attempted to take it down. Instant replay became a necessary feature, but we were worried that our quick firing system would be a problem. For example, in Angry Birds, there's a delay between firing as the birds jump into the slingshot to reload. This delay is even furthered by the fact that unless you're completely zoomed out, the camera slowly scrolls back to the slingshot after firing.

With friendly.fire the first thing on the chopping block from the Angry Birds formula was the camera scrolling. To me, this was always an unnecessary impediment, which slowed the game down too much. Furthermore, our first grid-based prototype played out like a war of attrition, in which each player had 100 shots. The player who used all 100 first lost. To go along with this, and test the player's willpower, we included a rapid-fire slingshot. Players can fire as fast as they want in friendly.fire.

In the end, our instant replay system ended up being very simple. Shots are stored on the server as an initial position, a launch vector, and a timestamp (the actual frame in the simulation in which the shot was fired). Due to the fact that Nvidia PhysX is deterministic within a single platform, this system worked.

To be honest, we are still encountering slight differences between fire, test, and instant replay modes, but the instant replays themselves are deterministic and most of the time our instant replays play out in a plausible manner. This is one area of the game that I really want to get perfect (for side-by-side pixel-perfect comparisons) but I feel that overall it does what we wanted in terms of gameplay satisfaction.

The final necessary component for our prototype before moving into our server-enabled version was a test mode. With a game such as Words with Friends, the solution a player presents on the board has a very static value associated with it. If I lay down the word "zee" starting on the triple letter score, I'm getting 32 points and I know it even before I lay the word down. The game builds upon the basic skill sets of language and mathematics, and it's dynamic to be sure, but it is much more predictable than a physics simulation.

Just like a Words with Friends player uses basic language and mathematics to play, a friendly.fire player uses basic physics principles (established by any child with a set of building blocks) to play. The difference is that the outcome of a word placed upon a board is fairly easy to spot. The outcome of someone shooting a fully physics-enabled block castle has many more outcomes (essentially infinite). The test mode thus allows the builder to try their own fortress on for size to see how it reacts to a barrage of slingshot pellets.


Article Start Previous Page 2 of 3 Next

Related Jobs

Gameforge AG
Gameforge AG — Karlsruhe, Germany
[02.26.21]

Senior Game Designer
Gameforge AG
Gameforge AG — Karlsruhe, Germany
[02.26.21]

Lead* Game Design
Insomniac Games
Insomniac Games — Burbank, California, United States
[02.25.21]

Narrative System Designer
Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States
[02.25.21]

Combat Designer





Loading Comments

loader image