R6: Post Mortem

I recently completed working on a game with 3 other people titled R6. Check it out.

Tech: Socket.io and Babylon.js were the heavy lifters in this project.

it is a 3D multiplayer in browser robot racing game. I wanted to take a moment to go over what worked, what didn’t, any odds and ends of observations.

The Good:

  • Scope: It was surprisingly well scoped. Even though none of us had done a multiplayer game before, and I was the only one who had worked with 3D before (definitely not in browser, or with javascript before.)
  • Research: We broke off into 2 teams at the start. One for front end (Babylon research) and the other for back end (Socket) at the end of the second day we had game logic tied to 3D representations that could be integrated with an event driven back end.
  • Iteration: We hit numerous bugs and hiccups (camera jitter, frame rate issues, rotation / scale.) But because we always worked to have something playable at all times, they never built up. Frame rate was also something that we all ended up improving over time as we spotted things could be improved, because we all worked the whole code.
  • Naive first: While we definitely spent time architecting, especially the core game logic, often times we’d hit areas we just didn’t have enough experience in to make educated guesses. We’d talk briefly, decide on a plan of action, make a note of the probable down falls, and take action. More often than not these solutions worked well enough.
  • Sound: One of our programmers was a musician as wel

The Bad

  • Art Pipeline: art is a large and sometimes unwieldy beast. in order to be efficient we used a bitmap as collision detection server side, which meant there was no actual relation between what the client saw, and what the server was doing other than, I lined them up in 3DS Max. Due to time constraints this was a very manual process, and prone to error. But worse than mild collision inconsistencies, was it was time consuming. While it worked for this project, the next order of business would be building art tools.
  • Art Seclusion: I’ve been an artist on a project where I can’t get my own art in the game, because it has to go through an engineer. This is a terrible experience, I don’t get immediate feedback, as well, in order to tweak and polish requires me to eat up engineer time. This project had a reverse, nobody else could really touch the art / design in any way because of how tied up into my 3D applications it became. Which meant that I was very alone with problems, and if they wanted to input on it, they could not directly do so.
  • More Design Time: This always happens with shorter projects, but by the time it really starts coming to shape and you can polish the levels (or re-make them) your project over. This game could be quite good with another week or so.

I actually really enjoyed doing double duty as a programmer (about 70% of time) and an artist (remaining 30%.) It felt really good to flex a full range of ‘muscles.’

Advertisements