We’ve all played games where you command groups of AI characters, or team mates.
OBEY instead puts you in the position to command your enemies (human opponents), and to be commanded by them. Players are always free to obey/disobey. It is up to them to deal with the consequences of their actions in the game.
If you are being coerced you have only stealth, intelligence, trickery, and creativity to escape.
It is sort of like Counter Strike Jail Mod meets Spy Party meets Texas hold ‘em.
You win by making more money than any one else by the end of the round.
To make the most money, you have to take command of the robot (the robot player makes 20x more than the other players per second)
You take control of it by walking into a door at the base of the robot.
The player in the robot can easily destroy any player he sees trying to approach (IF he sees them).
That’s the basics – so superficially, it plays like ‘king of the hill’.
Here is the twist:
Experienced robot players will know that it is not always in their best interest to simply kill the approaching players.
Why not? Because he can instead coerce them to do what he wants.
and that’s where the game gets interesting…
A huge step has been accomplished in getting the game ready for release on Steam.
OBEY is a Unity game.
If you enjoy technical posts, let me tell you a story about what it is like to implement in-game voice chat in Unity.
I started by buying a license to use Daikon Forge's DF Voice plugin. It converts the microphone data into something you can manage and pass around in the game. It doesn't care how you pass it or where you send it to, that's for the dev to take care of(as expected).
Considering that if players want badly enough to communicate with each other against the spirit of the game (ie cheat by spectating and informing another player) it would be so easy to sidestep any security measure in the game that it would not be worth having security at all. Secondly, since voice data is also not the most vital data in a game, if some packets are lost it is not a big problem and players can repeat themselves regardless. Therefore I decided that the best way to send voice chat would be to stream it unreliably peer-to-peer among players, and avoid taxing the server at all with voice functionality. This seemed a pretty obvious approach since I couldn't think of a good reason to not stream or to expend server resources on voice chat.
DFvoice comes with some examples using RPC calls to get voice packets from one computer to another. RPC's are verified and would waste bandwidth confirming and re-sending lost packets. So I started building a system that would stream the voice data (not use RPCs). DFVoice gives the voice data as byte arrays. Unity's bitstream.serialize() method does not accept byte so that meant I would have to send it in another format, and then convert it back.
I wrote a method that would buffer, split it up, and serialize it bit by bit as bools, and another that buffers those and reassembles them. I thought I had crashed Unity when I first ran it. But I hadn't. It was just so slow that it would not even be worth trying to optimize it to get it to work. After trying a few other things, I realized that there was no way to get it from one machine to another using any form of unreliable streaming because either the method would be too nasty a hack and/or be unreasonably slow because the Unity bit stream class does not accept any form of... well... bit streams. Sigh. I could sidestep it by integrating yet another library... or god forbid, torture myself with sockets .
Instead I rewrote the system again, this time biting the bullet and using RPC's peer-to-peer. It wouldn't be as fast as it could be, but the voices would be reliable and very clear. After spending the time I could not get it to work. I also could not find bugs, my code was good. What was going on? Well it turns out Unity has nuked the concept of peer-to-peer (even though it uses Raknet under the hood, which is fundamentally peer-to-peer networking library). You can't do ANYTHING peer-to-peer via Unity's native networking paradigm. I would have to send the data via the server.
So again I bit the bullet... this time really hard, rewriting the entire system YET AGAIN, to utilize RPCs and send them to the server and then via RPCs again to appropriate clients.
But only after trying every logical and (imo) best practice way failed.
I had to architect it in the EXACT OPPOSITE way that I had wanted, for it to work.
I haven't yet encountered enough problems with it to push me to rewrite it again using another library, but this is word to the wise:
If you ever want to add voice chat to your Unity game, prepare to do it in one of 3 ways:
1) using very nasty hacks
2) using a 3rd party networking library
3) modify Unity itself
4) the most ass-backward way from an architecture perspective
I hope this helps someone.
I don't regret using Unity's native networking system. It does what it is supposed to do, and I know it is built around making things 'user friendly', I just wish that I had known what I know now before starting.
OBEY player KOPFSTOFF used his incredible art skills to make one the best fan art pieces I have ever seen! AND IT'S FOR OBEY!
OBEY is now available as Early Access via Humble Store!
OBEY has just been launched on Kickstarter and Greenlight! Grab your copy!
Several new features have been added, bringing OBEY's unique gameplay closer to the public eye.
No articles were found matching the criteria specified. We suggest you try the article list with no filter applied, to browse all available. Post article and help us achieve our mission of showcasing the best content from all developers. Join now to share your own content, we welcome creators and consumers alike and look forward to your comments.