Who's Dumb? Who's Smart? That Question Gets Flipped On Its Head

In the world of writing B2C or B2B applications there's a pretty consistent view of the world. The server is smart, the front end (client) is dumb. Now, the smug amongst us may think that that is an accurate reflection of the developer community as a whole.

Front-end developers where only too happy to let the server (back-end developers) worry about all of the nerdy sticky business logic and worry about all of the "hard stuff" while they work on the attention-getting "easy" stuff. The back-end developers were also happy, those wanna-be real developers couldn't possibly understand how smart they are and how critical the code they write is, so yeah keep out! Oh yes, front-end developer, may have some input as to what format the JSON will be, but aside from that, you go play with your latest image carousel script.

With that being the state of the world, you had n-tiered applications where the front-end was a very thin, very "dumb" (meaning, it didn't know a lot about what was actually going on, it just knew what and how to display information) and exceedingly smart (meaning, every possible business rule, requirement and functional piece of code) back-ends.

I think in the now, where the lines blur between front and back end development and the rise of the full-stack developer (the true full stack, who can work in HTML/CSS and JavaScript (and the frameworks) along with being experience in iOS and Android and can design a database, and architect and build full blown back-end systems) this line is all but vanished, it doesn't exist. In the company I work for, there is no designation of front-end or back-end developer, you are a developer and you absolutely need to be comfortable working with AngularJS as you are in Java.

Which brings me to the whole point of this rambling piece (I'm pretty sure "rambling" is right in the title of this blog, so you've been warned). In game development, as I have learned, this line between what is front-end and back-end reemerges and it is heavily skewed front-end. But not front-end as I know it.

When I first started building ZONE, I started doing so as I have known for years, start on the server, carefully model the entities in Java, and then write lots of methods to handle all of the various pieces of logic that these entities (such as Player, Item etc.) will have to implement (all of the rules, like how many items can a player hold in their pockets?) And because of this, I also started writing API endpoints (using the excellent Play Framework, a Java framework I have used for years and have had a lot of success with) but then as my first prototype came into being (using a hastily hacked together app using Ionic) discovered that with all of the logic living on the server, players would have to wait for a response in order to proceed with whatever the next action or event would be.

I could see even with just my simple tests this just wasn't going to work. With possible latency introduced by ever increasing complexity with database queries. This realization made it very clear, the client was going to have to be very very smart.

Enter Unity.

With my switch over to Unity, it just made total sense that all of the game play logic, all of the rules and entities be implemented as part of the what is effectively the front end. The client can now respond "natively" to events and actions without having to completely rely on the server.

With this change in perspective (which has not been easy for me) I then ditched my existing server code in that it just isn't needed and instead found GameSparks, a back-end-as-a-service service which greatly reinforces this idea that your back-end is actually pretty dumb (well out of the box it's pretty "dumb" (it's actually a very clever, well put together service) you can do all sorts of customizations in GameSpark, implementing your own endpoints to do whatever you want) but the thing that struck me immediately is that the back-end here is just responsible for serving as a common storage facility, a channel to synchronize the client with the server (which is really important in a multiplayer world game like what ZONE is supposed to be) and provide the ability to stream realtime data.

Granted this means a certain amount of flexibility one is afforded in mobile development in "classic" B2C/B2B apps is lost in that rolling out new features doesn't necessarily require a production build of a new client. But again, in terms of creating an experience that relies critically on the immediate feedback produced by the execution of logic and rules of the game is way more important to leave up to even the most reliable server infrastructures.

Yes ZONE will be dependent on the server, but the way this game is being built the server could, in theory, disappear at any point during game play and while some impact may be felt, it would not mean the game is unplayable.

Changing perspectives has been one of the more, entertaining, challenges with respect to building this game, one that hasn't been completely resolved, but it'll be fascinating to see where this leads. Let the dumb be smart!