A Daring Move:
Rewriting the Prototype from Java to JavaScript

rewrite_angel_and_demon

The Gambit

This week we decided to rewrite the client prototype and change its run target. The prototype is not even done, and we’re already rewriting. This is usually taken as a bad sign in a project, but I think rewriting going to pay off. That’s the gambit.

I wrote the initial code in Java, and it was targeting the console. When the prototype was ready, I would send a JAR file to Andrew, and we could start work on refining and balancing game mechanics. Now the prototype will be in JavaScript, and the text output will be written to a <div> instead of a terminal. It’s the same basic idea, so why the rewrite? These are the pros and cons.

Pros

  • Faster Playable Iterations
    I know there will be bugs that need to be fixed. And I know we’ll want to try different settings for the game. Making changes playable in the JAR means: building the JAR, finding it on the filesystem, sending it through email or Dropbox, and waiting for Andrew to download and run. Making changes playable on the web means hitting save and telling Andrew to reload the page.
  • More Configurable Output
    Doing a console version was supposed to focus on game mechanics, as opposed to graphics, animations, UI, etc. Good idea in theory, but I ran into some problems.
    For example, there’s no universal way to clear the terminal in Java. Best thing you can do is check the OS at runtime and manually send the command: Runtime.getRuntime().exec("cls") for Windows, Runtime.getRuntime().exec("clear") for everyone else. But that works neither in the IDE output, nor in mintty. It’s not a huge deal to have infinitely scrolling text, but compare that to document.getElementById('id').innerHTML = ''. Advantage HTML.
  • A Weak, Dynamic Type System
    This is something that usually drives me crazy about JavaScript, but this early on in the process, I can see the advantage. The server side code is changing everyday, and with JavaScript I can just take whatever JSON string the server sends back and start using the values. In Java, whenever the server sends back new data, I need to change class definitions, track fields that get renamed, parse String to int, etc.

Cons

  • The Rewrite Itself
    The rewrite took about 2 days, and that time could have been spent on new functionality.
  • A Weak, Dynamic Type System
    What’s an advantage in the earliest stages is also a drawback once the code starts getting a little complex. There’s no way to see what’s really in an object until runtime. This gets so much worse with 3rd party libraries. What’s in the jqXHR object, for example? The jQuery docs here are really frustrating. I kind of just want a list of member variables and member functions, and it’s easier to get that from Chrome’s Dev Tools than from that documentation.
    A stronger type system lets a Java IDE provide most of this information, but I haven’t found one that can do the same for JavaScript. Maybe this is why people like WebStorm so much—I haven’t tried it. If it can do that, then it’s probably worth the $50. Anyway, </rant>.

Conclusion

So we obviously thought the move would be beneficial enough that we decided to commit the time to it. Fortunately nothing unforeseen popped up, and the rewrite didn’t take too long. I think the trickiest part was adapting the logic from Java’s synchronous (new URL(url)).openConnection().getInputStream() to jQuery’s asynchronous $.getJSON(url, callbackFunction).

So what do you think? Are there pros or cons that I missed? Should I have just used Java Web Start instead? (Just kidding.) Feedback is welcome. Hit us up in the comments, or @robotfriendgamz.

feedback

Making It Multiplayer

The Prince is going to be multiplayer. It is, by its nature, a multiplayer game. This is part of what makes the game work well, but it’s also going to be one of the more challenging aspects of development, at least from my perspective as the coder. And since multiplayer is central, it’s going to need to be in the prototype from the get-go.

Server-side PHP
Actual server-side PHP

Adding multiplayer changes the game from being a complex, interactive application to being a complex, interactive application running on top of a state machine. Any action taken by the local player needs to be sent to the server, and any action taken by the remote player needs to be read from the server. The game is base on time-limited turns, so this back and forth needs to be coordinated throughout the entire game.

Since the game is turn-based, I won’t need to deal with the usual multiplayer difficulties, like serializing packets, using dead reckoning, optimizing my protocol, etc. Instead, I can just use TCP to ensure packet delivery, and structure data into JSON strings. Then my main concerns are for synchronizing time and the getting the logic right.

I don’t have too many implementation specifics to offer yet because it hasn’t been completed. What has been done on the server side was written in PHP with MySQL backing for storage. I realize that going to the DB on every call may not be fast enough in the future, but I’ll cross that bridge when we come to it. In the meantime, it’s familiar, (relatively) easy to work with, and it’s more than enough for these early prototyping days.

2015 Goals

This year we’re focusing on a new project called ‘The Prince’ (working title). Our goal is to launch a commercially viable product mid-to-late 2015. We super excited to share progress, wins and fails on this blog as we go along.

More details to come soon about the game itself but in the meantime, enjoy these concept images.

Screenshot 2015-01-02 11.51.47 Screenshot 2015-01-02 11.51.59 Screenshot 2015-01-02 11.52.02 Screenshot 2015-01-02 11.52.15Screenshot 2015-01-02 11.53.53

Feel free to follow us @RobotFriendGamz

– AB