Entering virtual environments

It's been awhile since I last wrote in this blog, and now I'd like to introduce what I've been working on during the last few years, after doing the one-week game project.

Shortly after that, in November 2010, I got back to work as a programmer for Blit Software, including mobile, web and desktop development. In all of these cases, I worked with applications that provided a web-based approach to retrieve data from a webservice. Then I worked with Unity3D on some augmented-reality game for mobile platforms: Drop Defender.

After a year, I moved on to worked at Digital Chocolate (Barcelona) as Lead Game Programmer, first in Galaxy Life: Pocket Adventures, then as Lead Tech Programmer in Battle of Heroes: Land of Immortals, an exciting project. In both, I got to work with a web-based online game that would perform a client simulation but would retrieve and update its progress with a remove server using web endpoints.

In both of these positions, I've had the opportunity to work with web services, which was a new kind of paradigm for me, even though these days it is a rather standard way of storing and accessing remote data. You build a front end that manages the user interaction and most of the logic, but then you get some significant data from a service, through an asynchronous HTTP connection.

Some time ago, while working at Tragnarion Studios, I got in touch with Squeak, an environment built on top of a Smalltalk virtual machine, an old project dating back to the 70s. I found this kind of environment enlightening, so wonderfully interactive, that I found it surprising that there was no other modern project with the same kind of interactive, edit-from-inside development environment. On top of Squeak, another team developer the Croquet Project (and then the Cobalt Project, now actively developed).

Finally, another project I got to work in Tragnarion Studios involved a multiplayer experience where multiple players would share a common experience across a distributed environment. That's when I learned how to work with replicated variables, remote procedure calls, and predicted, interpolated and remotely controlled behaviors. A deliciously interactive environment would replicate changes to its state across all players sharing the same simulation across a local, or global network. And that considering delays and all sorts of unpredictable network situations, is quite a feat.

Let me summarize these kinds of scenarios:

• a client front end providing user interaction that will get its content from a server
• a interactive environment for editing data and behavior
• a distributed simulation shared among a number of player over a network

Now what I've started to think is: what if we took the interesting pieces of each of these approaches to a distributed interactive experience, and put them together with cutting edge technology, over multiple platforms? That's of course what I've been working on, and I'd like to share with you the interesting findings of this approach.

Of course the development of such an environment has been highly incremental, for basically each piece is built on top of the previous one. First we build (1) an interactive environment we can download from a website, then we add (2) some edition capabilities, then we (3) share it with multiple clients. It is this combination that brings us the full power of collaborative virtual environment.

(to be continued)

The one week game project: aftermath

The week of my OWGP is over, and it's time to wrap-up and summarize the lessons learned while conducting this experiment. First of all, I would like to explain what the idea of the project was all about.

Motivation

During my years working in the game industry, the most disturbing pattern I noticed was one that has to do with planning, prototyping and delivery. Basically, these steps only existed as a good idea but they were never truly developed.

Planning was just a way of casually stating what kind of game we were doing and some general rules about the directions, but the whole project was rapidly driven off course by means of improvisation, unexpected requirements and general trashing that came from upper management, or simply from the last person to join the team.

Prototyping didn't exist, or at least not intentionally. Turns out everything we were doing was treated as a prototype, because everything was open to tweaking and experimentation.

Finally, delivery was just a requirement to fulfill, but had nothing to do with the actual development schedule. Significant changes were made during the beta stage, introducing new bugs and cases, and the final version released was just the one that crashed the least, and included the features that had made it through the chaotic development cycle with as fewer bugs as possible.

In fact, I was actually able to ship only one game, and reaching gold was a nightmare of last minute changes, unforeseen features and overtime.

Unfortunately, these things are usual in the games industry. Not all studios like it, but most accept it, and even exploit it, as part of their culture. And these things are the cancer of an already troublesome industry, leading projects to delays, overbudget, cancellations, and teams to frustration, turnover and burnout.

What I want to prove is that planning and prototyping can happen in very short development iterations, where features can be tried and tested. And with a consistent application of these, and some work discipline on the part of managers, producers and designers, it is possible to actually deliver on time and on budget.

This is why I decided to conduct this small-scale experiment, where I would play all the roles, and feel the urge to delay and trash, but restraining myself from doing so because of the short time schedule. And I also had to keep myself from the programmer urge to overengineer and aim toward perfection, basically because there was no time for that. I had only five days to get the job done (hit a fictious beta stage, let's say) and that had to be it.

Postmortem

So let me summarize briefly the day-by-day development of this project:

• Day 1. I created a small scale simulation of the game idea, without using any actual resources, only abstract progammer art (cubes and spheres) representing the game entities (the stage, the props, the player, the enemies and the projectiles). I could get a simple game like this done in less than a day work, given that I had the technology for that (I used the Zombie Demo framework). Also, the game was a simple shoot'em up retro-style game, so I guess design was not such a big issue here.
• Day 2. This was the moment to start creating an environment for the game. I decided to use resources I had from an old project I worked with using the Zombie Engine. Problem is, I didn't want to use the Zombie Engine itself, because the complexity of defining and managing entities was too big and I wanted to keep such a small project small. So I tried to load only the data I needed and go with it. By the end of that day, it was obvious that I couldn't do that in just a few days, and still get the game done.
• Day 3. This is where I had to be practical and came up with an interesting idea. The only thing I knew for sure of the Zombie Engine is that graphics and edition worked really well. It was gameplay I couldn't really grasp. So I had this idea to create a level for my game that was made only of "dumb" entities, that is, entities with no logic or behavior. Then, I would get access to each of these entities and let my game logic update their state. I didn't even think this was going to work, but it was worth a shot, and by the end of the day, I could move my non-animated player through the level, so I decided to go this way.
• Day 4. After finding this indirect way to use Zombie to my advantage, I kept on developing the game but instead of abstract graphics, I used to entities in the level, and had to write the gameplay logic to move and animate graphics, and let game objects interact with each other (shoot, etc.) By the end of the day, I had my player running up and down, shooting forward, and enemies attacking. Unfortunately, I had only one day left to finish it off and still had some important things to figure out.
• Day 5. This was the day I had reserved for the finishing touches and I still had the important task of defining end game conditions, and restraining the movements of the player (I didn't want to use the collision system in zombie) so that's pretty much what I ended up doing. By the end of the day, the game ran more or less ok in my test level, but not so much in an actual game level. But this was something for the beta stage to work on, and I had already proven my point.

The result of this experiment has been enlightening. I've realized how easy it can be to stray from your original concept when faced with technical limitations, but also that short iterations lead to practical solutions, and having a clearly defined timespan, you don't get to trash or change your mind, so you just work with what you have. If it's not perfect the first time, you will do better next time. But if you deliver, you'll most likely be able to deliver again.

As Seth Godin states it: "You don't make a living out of being creative. You make a living because you ship." Being creative is something that happens only in the first stages of a project, but the kind of changes and redirections I've had to suffer (and many other developers for that matter) because of the hierarchical nature of development in the games industry are proof that poorly understood creativity leads to projects that are finished late, over budget and with a hidden cost of lost human motivation and satisfaction.

These factors may not usually be taken into account, but they are part of the process of creating games as well. And what I wanted to prove, myself included, is that it is possible to think of games development in a more practical and imperfect way, but one that ultimately leads to shipping, and getting to try again because of that.

So maybe I'll try again, and see what comes up next time.

I can't really publish the resulting product, because it's too shameful, and because some of the resources it uses are copyrighted by a former employer. But if you're interested, the code can be found in the SVN address.