Google Play Features Splice!

That’s right! Splice is now available in the Google Play store for Android, and we’ve already seen some great reviews!

James Gilmore at Pocket Gamer remarks, Splice is a minimalistic marvel, and its elegant presentation and testing challenges have helped it earn numerous accolades since its release – including our highest honour, the Pocket Gamer Platinum Award. Splice: Tree of Life is a real treat for puzzle fans, and one of the best mobile games of the year.”

With our new website, now you can also get Splice and both soundtrack albums—Flight of Angels and Algorithms & Angelology—through the new Cipher Prime Store! For more reviews of Splice, be sure to check out the Splice Announcements page.

Unity Networking for Fun and Profit

Getting Connected

Unity networking utilizes the Client-Server networking paradigm. This means that there needs to be a single server, which clients connect to. The server handles the routing of network messages to clients. A server can be a remote machine that only handles the messaging, but for a game like Duet, which is going to have a very small number of connected clients, it’s much more likely that one of the player’s devices will act as the server. Creating a server is a relatively simple affair, with the server instance calling Network.InitializeServer. Clients then just use Network.Connect to connect to that server. There is a bit of complexity regarding Network Address Translation (NAT), and accessing remote machines, but dealing with those issues is a bit beyond the scope of this document.

Connecting the server and client(s) initially does very little. In theory, connected servers and clients could be on completely different scenes, with totally different game states. This may seem strange initially, but allows for flexibility and performance that would be impossible if everything was kept in perfect sync across all peers (clients and server). For example, Project Gorgon (an in-development Unity-based MMORPG) uses several “headless” (without a graphical component) Unity applications to handle NPC interactions. Even though the client and the NPC driver are two completely different Unity applications, they are able to share information with each other. If we want to provide a completely synchronized experience with multiple identical clients, then we need to provide a structure that handles that. Fortunately, that isn’t terribly difficult.

Network Views

When peers are connected, only game objects that have Network Views attached to them can transmit information across the network. Network Views are built-in Unity components, and have a few different operation modes that allow for situation-specific performance tuning. There are three pieces of information that are crucial to utilizing Network Views: the owner GUID, the State Synchronization Mode, and the Observed Component.

The owner GUID is the least visible of the three properties discussed above, primarily because it is initialized by Unity, and cannot easily be changed. Whichever peer creates the Network View is set as the owner. This is important because only the owner can write changes to the state synchronization stream. Other peers can perform local changes, but Unity won’t send those changes to other connected peers.

For example, Client A owns their player object, and can send position changes to the other peers. Client B owns their player object which punches Client A, sending them backwards. The change in position seen on Client B’s instance won’t be seen by any of the other peers. For the force to actually take effect, Client B needs to communicate to Client A that its player was punched, and have Client A react to that change. This doesn’t sound ideal, but it actually allows a technique called Dead Reckoning, where Client B show’s Client A’s reaction to B’s action before A has actually sent a reaction message. For more information, the Valve wiki has an excellent article on interpolation, prediction, and compensation.

State Synchronization

Each Network View (there can be multiple Network Views attached to a single GameObject) has an Observed Component and a Synchronization Mode. The Observed Component is the component whose data will be automatically sent through the network by Unity’s networking. Transforms are commonly used, but any type component can be observed. Since only one component can be observed per Network View, if you want to observe multiple components of an object, you’ll need to utilize multiple Network Views. It may be possible to create a single Component that is an aggregate of all of the components you’d like to sync, but I haven’t investigated that possibility.

The Network View’s Synchronization Mode can be either “Off”, “ReliableDeltaCompressed”, or “Unreliable”. Turning the Synchronization Mode Off means that the Observed Component will not be sent over the network, and can be left null. This can seem like a wasted option, but it is the way of using the game object solely as an endpoint for Remote Procedure Calls (RPCs) without sending useless information over the network. Surprisingly, both ReliableDeltaCompressed and Unreliable Synchronization Modes utilize the UDP protocol, which is inherently unreliable. Unity Networking has it’s own network layer that utilizes ACKS and NACKS to make sure that anything marked as ReliableDeltaCompressed is, in fact, reliably streamed. ReliableDeltaCompressed is much slower than the Unreliable Synchronization, but it is guaranteed to have all updates seen by all peers, and that all of the updates are seen in the correct order.

The Unreliable setting, unsurprisingly, makes none of these promises. When using Unreliable Synchronization, messages can be lost or arrive out of order. This isn’t as useless as it sounds. When the component being synchronized is something that is constantly changing, such as a player’s position, there are going to be lots of updates being pushed through the network. If a small percentage of them are lost in the cold void of the internet, it isn’t a very big problem. Any lost messages are likely to be rapidly made outdated by newer ones that do make it through to the peers. Unreliable Synchronization is much faster than ReliableDeltaCompressed, which makes it ideal for data that will be constantly changing.

It’s worth noting again that with all types of Synchronization, only the changes made by the owner peer will be reflected across the network. Even if the server wishes to make changes, if it doesn’t own the object, it cannot. Therefore, if you want the server to be the authority on game state (which is a fairly standard requirement), the server needs to be the owner of all important objects, and have the players that “control” them send requests for state changes.

Observing a Script

Along with observing basic unity Components like Transforms and RigidBodies, a NetworkView can be given a custom MonoBehavior as its Observed Component. When a message comes in (or a request to send is made), the MonoBehavior’s OnSerializeNetworkView method is called. The BitStream parameter can have data pushed to or received by it using the stream’s Serialize function. Determining whether or not the Component is an owner is a simple matter of reading the stream’s isWriting property. When setting up the functions that read and write serialized data, it is important that the order data is serialized and deserialized is identical, otherwise the right data will end up in the wrong place. Only basic types (int, float, etc) can be serialized, along with Quaternions, Vector3s, and two types relating to NetworkPlayers. Custom objects, even if they are serializable, can’t be send through this function, nor can variable-size objects like arrays. In theory, this limitation could be circumvented by sending the length of the array, and then the contents.
Like the built-in synchronization for unity Components, the order and reliability of OnSerializeNetworkView calls depends on the Synchronization Mode of the Network View. In Unreliable mode, the data is sent/received approximately 15 times per second, though that can be changed by changing the Network.sendRate parameter. Rather than send a certain number of times per second, when Synchronization is in ReliableDataCompressed mode, changes are only sent/received when unity detects that a the component has changed in a way that warrants a data update. Since there is more overhead in this mode, it makes sense that the updates should strive to contain more data, but keep the number of transmissions lower.

Since the custom Component is still being Synchronized via the NetworkView, it holds to the restriction that only the owner can transmit data, and all non-owner peers can merely read the stream. Fortunately, there is a way for peers to send messages to each other

RPC Calls

Remote Procedure Calls, or RPCs, follow a convention that should feel very familiar to a Unity Developer. The if a GameObject has a NetworkView attached, it can call the RPC function, and provide a function name, a broadcast type, and a list of parameters. Then, all synchronized Network Views will receive a function call with that same name and list of parameters. The receiver’s function does need to be marked with an RPC attribute (“@RPC” for Javascript, “[RPC]” for C#), so the unity compiler knows that it is a network-exposed function. RPC function names must be unique throughout the scene’s scripts, so Unity knows which types of GameObjects can receive the RPC. In this way, it is very similar to using Messages, except instead of sending up or down the hierarchy, the messages are sent across the network. Similar to State Synchronization, RPCs can only take basic types, Quaternions, Vector3s, and NetworkedPlayer data. However, RPCs are at a disadvantage, since they can’t make use of the array workaround discussed above. The benefit to RPCs is that these functions are called on all peers that meet the qualifications of the broadcast type specified in the RPC call. Generally, and RPC will only be sent to a single other peer (such as a client messaging the server), or to all connected peers (broadcasting a change). Also, RPCs can be buffered, which means that they are stored at the server level. When a new client connects, all buffered RPCs are sent to that new client, which makes them useful for storing persistent state information.

Unfortunately, the Unity documentation is relatively light when it comes to discussing the performance of RPCs in real-time games. A note is made that the number of parameters of an RPC shouldn’t be overwhelming, which seems to imply that they are expected to be used for fast, frequent updates. However, RPC calls are guaranteed to be received in the same order that they are sent, which can introduce latency if a particular message is misplaced. Since they can, in theory, be called at any time by any component attached to a NetworkView, it would seem that they fill a space between the slower and reliable ReliableDataCompressed and Unreliable modes of State Synchronization. Their ability to affect other peer’s game objects, though, makes them invaluable. This doesn’t expose any additional risk of hijacked peers, though, since the owners of those objects receive the RPC, and can decide if it is, in fact, a message worth listening to.

My Final Argument for Games as Art

So I’ve been having an alarming number of nightmares recently. My nightmares don’t tend to be of the obvious pain-of-death variety; more of the slow, horrifying realization type. Last night’s was particularly crushing, and I would like to share it with you:

A different place, a different time. I lived in a house, with my wife, in a world overrun with vicious predators, who sought nothing more than to rend us limb from limb. For reasons not known to me, our house was not safe at night. So every night was spent running through the wilderness, not staying in one place for very long, leaving our scent with small groups of prey so the predators would consume them and not us. Every day was spent resting in the house; each day one of us would say to the other, “When we rest, we rest together,” and she would make a bottle for the baby. Every night, we’d run.

After a few nights, I realized there were no other humans.

And one day, weeks later, she was making the bottle, quietly sobbing, saying to me, “When we rest, we rest together,” and I realized there was no baby either.

 

Not exactly how I wanted to wake up, and it certainly kept me from sleeping for about the rest of the night. So I lay in bed, thinking about the dream, thinking about how I could communicate to someone just how crushing that realization was. There are obviously many ways that story could be communicated; I could write it, as I just did. I could turn it into a proper short story, with characters; I could illustrate it as a comic; I could do a short film. But all of these are viewing forms — even with a first person perspective, if you came to the realization, it wouldn’t be yours — you would be watching someone else come to the realization. You may feel for them, you may empathize, but it still isn’t your realization.

I realized the only way to fully communicate my experience to someone else would be to turn it into a game.

The reason, of course, is that there is a very specific set of criteria and stimuli you need to experience in order to grasp the full weight of the situation:

  • You need to be you, but as someone else. This strange dissociation isn’t a particularly difficult concept; we do it all the time in dreams, and we do it all the time in games.
  • You need to not know everything about yourself, but know enough to function in your new world. This strange not-amnesia isn’t really that weird; again, we do it all the time in dreams, and we do it all the time in games.
  • You need to be able to take in information at your own pace, information needs to be available to you at only the moments you look for them, and gaps need to be present to allow you draw your own conclusions. Movies try to do this, but they can only show you information; as clever as a director may be, he can’t truly allow you to discover information. But we do it all the time in dreams, and we certainly do it in games.

The realization that there was no baby, and hadn’t been for some time, only came at the moment I saw her crying, because every instance before that, after she made the bottle, we would sleep, and when we ran, she ran behind me. This allowed the assumption that she carried and cared for the baby. But when I had that realization, the rest of the dream came into the focus — I had never seen the baby, I had never heard the baby. The only evidence that the baby had ever existed was in my wife’s actions.

These sort of cognitions, realizations, and epiphanies are only possible in a medium where you are given a certain amount of author-provided information and a certain amount of autonomy of discovery. And so I discovered this truth about games:

Games can cause the participant to have author-guided realizations.

and even more importantly…

Games can cause the participant to have author-guided realizations that the participant owns.

I humbly submit that no other art form could as effectively communicate my dream, as I experienced it. And before you tell me it wouldn’t be a game because there are no goals, the goals are obvious: avoid getting killed by predators, for as many days as possible.

A game can be the strongest medium with which to express a dream. If that doesn’t qualify it as art, then you clearly don’t know how to dream.

Point and Click, Perfected

I play a ton of games. I’m also really fickle. In fact, one of the main reasons why I make games is my frustration with finding games that satiate my specific moods. I’m your worst game design nightmare. I get easily irritated, therefore, I HATE making games for me.

For a few years now, I’ve been hearing about this point-and-click adventure game called Trauma. I believe we’ve even had the immense honor of being nominated for awards next to this title. In my head, I’m not a huge point-and-click fan, despite playing every damn Cyan game from Myst onwards. Somewhere, I think I might be lying to myself. But, the truth is… a genre doesn’t have to define a game. Sometimes, a game can be so completely amazing, it just busts “awesome” at the seams.

I can’t really explain why I’ve put off playing Trauma for so long. At the end of the day, I was just being a jerk. I judged the book by its cover (which honestly looks fantastic). It wasn’t for me. It was for some other artsy, geeky, game-design nerd. Yep. I was wrong.

Trauma is INCREDIBLE. The story draws you in even when you hate story games (I DO, maybe). The aesthetics are phenomenal. A REAL designer was on this project. Almost every game I play these days lacks a good designer; that was not the case here. Someone took the time to really pay attention to the experience they were creating. There are no handholding tutorials. In fact, the basic tutorials are built into every stage of the game and even hidden as a part of the experience itself. The whole damn thing is just bathed in style. The music sets a perfect tone. The photographic imagery is impressive. The animations are smooth without being corny.

One of my favorite parts of the game is its control interface. By nature it is point and click. However, other actions can be performed by drawing lights in the air. Those actions are scattered around this playground-style-world for Gestures through Point and Clickyou to find. The only complaint I have about the game is that the 3 ‘execute’ actions are the same for each ‘dream’. I would have loved to explore a bit more and interact in a more conductive (think music) way.

The play time is rather short. We’re talking 3 hours to completely find everything and all the alternate endings. While some people may find this terrible, I cannot help but LOVE the game for this. The whole experience was fleeting. I have been treated to this amazing experience. I’ll never be in that state of mind again at that moment and pick that game to play. You’ve given me a lasting memory. Thank you Krystian Majewski.

Games like this make me self-reflect. I love being touched by an experience. For me, it’s rare and when it happens I cannot help but be thankful. Thankful that there are people out there making such great experiences and thankful that I’ve just got to get out there and discover them.

Splice: IndieCade Nominee

Awards!

It seems Splice was kissed by Lady Luck! In June, Intel announced Splice as Puzzle Genre winner of the Intel Level Up competition. In July, Penny Arcade announced Splice as one of this year’s 10 best indie games in the PAX 10 selection. We were also nominated for the Philly Geek Awards as Indie Game Dev of the Year. And just this week, Splice was nominated for the IndieCade Awards!

IndieCade is the International Festival of Independent Games, held annually during the first weekend of October in Culver City, CA. This year, 36 games have been selected, including the KickStarted FTL: Faster Than Light, Amanita Designs’ Botanicula, and Shawn McGrath’s DYAD, just to name a few of our favorites.

Kickstarter Update!

Also, yesterday we posted a Kickstarter update. The post should bring everyone up to speed on where we’re at, and where we’re going in the near future. Backers also get a 66% discount on Splice!

Dev Night!

And last night’s Dev Night was awesome! Big shout out to everyone that was able to make it. Projects are coming along wonderfully, and it was great seeing a few new faces show up as well!

Although we’re heading to PAX next week, Dev Night is still on for Thursday as usual. Aaron will be sticking around to man the fort and host. If you are going to PAX, be sure to look us up! We’ll be exhibiting Splice for Mac, PC, and iPad at the PAX 10 booth. You can also tweet at and follow us on Twitter @CipherPrime.

See you next week at PAX Prime and Dev Night!

Project Lineup

Quick Shout-Out: Dev Night is tonight from 5pm to 1am. Bring a laptop with Unity installed. Have Sculptris installed too if you’re participating in the artist initiative.

So what’s next at Cipher Prime? We have a few projects on hand actually. While Dain and Andrei are in the process of wrapping up the iPad version of Splice, Will and myself have been working on two other side projects as we gear up for Auditorium 2: Duet.

The project I’m working on right now is really a way to help familiarize myself with the Unity developer environment, as well as the studio’s production pipeline. It’s a game called Feedback.

We have another project planned that will actually lead into development on Auditorium 2 : Duet. It’s a multi-player, arcade-style shooter that we’re currently calling Intake. The project will last exactly four weeks, and will help us establish development roles for each team member while building out the framework for Duet. Intake should serve as a pretty good test run of our new production pipeline as well as the framework. What we learn with Intake will go a long way in helping us with production on Duet.

Among the features we’re testing include multi-player mode and matchmaking, leaderboards, achievements, cross platform support, and cloud saving. Splice supports some of these features, but much of it was implemented late in the dev cycle, leading to a number of setbacks. Having the architecture for it from square one with Duet will give us more time for creative development.

If we are able to pull together a polished game in just four weeks time, Intake will be released through the Cipher Prime Store. If not, well, it’ll get placed on the back burner for a while, but we will have learned some valuable lessons from the effort. Our focus from there will be to get the level editor built for Duet.

This road to Duet is an eventful and exciting one for sure!

Chapin Chiming In

Hey, Everyone! Aaron Chapin, here. I’m the new Lead Developer at Cipher Prime!

With the addition of myself, the studio is now up to five developers. My role is to help organize and plan the development process, and keep us on track for reaching development goals and deadlines. For the past three years, I worked as a Gameplay Programmer at another Philadelphia game studio called Burst Online, where we made web-based MMO Flash games. Much like Will and Dain, I started out working in Flash and am now making the jump to Unity!

My goal, now that I’m here, is to help build up our team’s skills, and to get us working faster and more efficiently. Unlike the others, I’m the only one who went to school for programming. I have both a BS and MS in Computer Science from Drexel University, also located here in Philly. The expectation is that someone with a bit more formal training will have the necessary knowledge and ability to carry the team in cases that would otherwise cause weeks of downtime for R&D. Less downtime means earlier releases, more features, and more time to play StarCraft. (Don’t worry, I’ll try not to let StarCraft distract me too much.)

I’m excited to be here, and I can’t wait to show you guys all the cool stuff we’re working on!

Auditorium + MusicRx

Cancer f#@%ing sucks. No question about it. If you’ve ever known someone with cancer, you know just how scary and devastating it can be. You also know how important hope can be.

Through MusicRx, the Children’s Cancer Association is helping to promote a bit of hope, happiness, and comfort to children fighting cancer. The program is aimed at providing kids with a therapeutic means of escape while allowing them to express themselves through music. MyMusicRx is a place for kids to explore and listen to music, play music-based games, learn about musical artists and sports stars, and connect with others.

To help the cause, Auditorium is now available to MyMusicRx kids as a free to play game. You can also help the cause by searching for and purchasing your iTunes music through MyMusicRx.org. iTunes will donate up to 5% of all purchases to the Children’s Cancer Association.