Paul Kuliniewicz » neutronium http://www.kuliniewicz.org/blog After all, it could only cost you your life, and you got that for free. Mon, 28 Jan 2013 03:25:49 +0000 en-US hourly 1 http://wordpress.org/?v=3.8.5 http://creativecommons.org/licenses/by-nc-nd/3.0/us/ Neutronium update – Dec 12, 2011 http://www.kuliniewicz.org/blog/archives/2011/12/12/neutronium-update-dec-12-2011/ http://www.kuliniewicz.org/blog/archives/2011/12/12/neutronium-update-dec-12-2011/#comments Tue, 13 Dec 2011 01:13:52 +0000 http://www.kuliniewicz.org/blog/?p=2379 I’ve continued working on Neutronium daily, but for the past week or so I’ve been focusing on refactoring some of the code I wrote earlier to facilitate actual new features. The biggest change has been putting most of the room-related logic in the STM monad, instead of having parts of it in STM and other parts using IO-based synchronization, particularly MVars. By putting all if it in STM, I avoid having the room directory MVar acting like a global mutual exclusion lock, and let room-related operations behave atomically, which could save some headaches down the time. I’ve also cleaned up various other bits of the code to simplify things and make things more easily testable, but nothing that warrants much discussion here.

Now I’m working on fixing how joining and leaving rooms work. Before, a member of a room was identified by the session identifier of the user’s session, but that’s very problematic. First, it means that opening the same room up in multiple tabs would result in confusing behavior, since the server wouldn’t have any way of distinguishing each tab. Second, it makes distinguishing one member from another difficult on the client side, since session IDs are sensitive information and can’t be shared, lest session hijacking result.

My solution is to assign yet another unique identifier to represent each member joining a room. Since member IDs aren’t sensitive, they can be freely communicated to everyone else in the room. Since it’s decoupled from the session cookie, each tab can be given its own member ID, should someone open the same room up multiple times for some reason. On the server side, each member ID is still bound to a particular session ID, preventing one member from trying to impersonate someone else; if the member ID sent in the request doesn’t match the session ID the request is made under, the request is ignored.

At least, that’s how it will work when I’m finished making those changes.

]]>
http://www.kuliniewicz.org/blog/archives/2011/12/12/neutronium-update-dec-12-2011/feed/ 0
Neutronium Demo Video http://www.kuliniewicz.org/blog/archives/2011/12/02/neutronium-demo-video/ http://www.kuliniewicz.org/blog/archives/2011/12/02/neutronium-demo-video/#comments Sat, 03 Dec 2011 04:41:45 +0000 http://www.kuliniewicz.org/blog/?p=2365 With Renee’s help, I recorded a six-minute-or-so demo of Neutronium, the game I’ve been working on since the beginning of November. You’ll probably want to play it at 720p (HD) and full-screen in order to be able to read the text.

Neutronium is a web-based game inspired by a game inspired by the light-cycle game from the movie Tron. Currently, only the fundamental gameplay and a rudimentary chat function are implemented. Each player controls a constantly-growing line. They can’t speed up; they can’t slow down. All they can do (currently) is change direction. Once a player’s line collides with something, it stops and the player loses. The last player left alive wins.

(Note that the game doesn’t actually detect “winning” yet, so a game lasts until everyone has run into something.)

The video above was recorded from my machine. I am the blue line, and Renee is the red line. The chat window doesn’t yet have a way to identify who says what, but in this case you can tell my messages apart from Renee’s because you can watch me type them.

]]>
http://www.kuliniewicz.org/blog/archives/2011/12/02/neutronium-demo-video/feed/ 2
Working on a video http://www.kuliniewicz.org/blog/archives/2011/12/01/working-on-a-video/ http://www.kuliniewicz.org/blog/archives/2011/12/01/working-on-a-video/#comments Fri, 02 Dec 2011 03:55:43 +0000 http://www.kuliniewicz.org/blog/?p=2363 By popular request, I’m working out a way to record a quick video of my game in action. Before I do that, though, I want add an option to select the size of the game area. Right now it’s a hardcoded size, and it’s large enough to be awkward for an embeddable video. Something smaller would probably look better.

]]>
http://www.kuliniewicz.org/blog/archives/2011/12/01/working-on-a-video/feed/ 0
LoCo Day 30 http://www.kuliniewicz.org/blog/archives/2011/11/30/loco-day-30/ http://www.kuliniewicz.org/blog/archives/2011/11/30/loco-day-30/#comments Thu, 01 Dec 2011 03:44:01 +0000 http://www.kuliniewicz.org/blog/?p=2361 Today I added support for command-line options when starting the web server. Specifically, it’s now possible to specify which port the server will listen on, and the hostname that will be used when showing type-safe URLs. Previously, both of these were hard-coded in such a way that made it difficult to use the server on anything but localhost. I also increased the server-side timeout, so that I can go increase the long-poll duration.

Now that November’s over, I haven’t decided whether I’ll keep posting daily updates about progress on the game. I would like to keep working on it and get it to the point where I can actually put it on the Internet — though I did succeed in my goal of having a playable game by the end of the month, there’s a lot of polishing that needs to be done, to say nothing of the important-but-nonessential functionality I skipped over to focus on the core gameplay. I have no idea how long it’ll take me to get all that done, though.

]]>
http://www.kuliniewicz.org/blog/archives/2011/11/30/loco-day-30/feed/ 3
LoCo Day 29 http://www.kuliniewicz.org/blog/archives/2011/11/29/loco-day-29/ http://www.kuliniewicz.org/blog/archives/2011/11/29/loco-day-29/#comments Wed, 30 Nov 2011 03:50:30 +0000 http://www.kuliniewicz.org/blog/?p=2359 Two small but welcome changes today:

First, I reduced a lot of the lag during game play by excising a bit of debugging code on the server. The server had been printing out to the console the session context for each request before processing it further. Since I had gotten sessions working quite some time ago, all this did in practice was add a slight delay in processing each request, which wasn’t noticeable until you start trying to play a real-time game where each move sends a new request to the server. There’s still a bit of noticeable lag during the game, but it feels much smaller now.

Second, colors are now used to distinguish you from other players: you are blue, and everyone else is red. This way, you can tell right from the beginning who you are in the game. This is currently implemented by having the server reply to the “I’m ready to play” request by sending the client the ID used to identify that player during the game. There’s still no indication of who is who in the chat window, or is information about who dies when presented to the player (other than saying “someone died”), but the information is there for whenever I get around to implementing it.

Also! I discovered that part of the Conf structure passed into Happstack to start the web server is indeed a timeout for how long to let a request sit idle before killing it. The timeout defaults to 30 seconds, which explains why my initial attempt to use a 60-second interval for long polling kept resulting in server-generated errors. One of the next things on my to-do list is to make the host and port the web server listens on configurable instead of hard-coded, so while I’m at it I might as well lengthen the timeout.

]]>
http://www.kuliniewicz.org/blog/archives/2011/11/29/loco-day-29/feed/ 1
LoCo Day 28 http://www.kuliniewicz.org/blog/archives/2011/11/28/loco-day-28/ http://www.kuliniewicz.org/blog/archives/2011/11/28/loco-day-28/#comments Tue, 29 Nov 2011 03:49:11 +0000 http://www.kuliniewicz.org/blog/?p=2357 Today I tried to solve the problem of the “ready to play” button swallowing keyboard input when the game starts, even though the button was disabled. Apparently jQuery doesn’t let you put the input focus on the document itself, which is where the keyboard input handler is attached. I ultimately settled on hiding the button entirely instead of disabling it after it’s been pressed, which has the result I wanted: putting the input focus on nothing in particular, so that the document sees the key presses.

This probably won’t work well if you start using the chat window again before the game starts, since the focus would still be in the text entry box, and arrow keys there will move the text cursor instead of moving your player avatar in the game, leading to much unhappiness as you get killed off before realizing what’s going on. So, this is more of a quick hack instead of an actual fix.

]]>
http://www.kuliniewicz.org/blog/archives/2011/11/28/loco-day-28/feed/ 7
LoCo Discontinuity http://www.kuliniewicz.org/blog/archives/2011/11/28/loco-discontinuity/ http://www.kuliniewicz.org/blog/archives/2011/11/28/loco-discontinuity/#comments Mon, 28 Nov 2011 23:18:31 +0000 http://www.kuliniewicz.org/blog/?p=2355 Apparently my posts for Friday and Saturday never made it out of draft form, and so didn’t appear on the blog until now. Just in case you were wondering what I was up to after Thanksgiving.

]]>
http://www.kuliniewicz.org/blog/archives/2011/11/28/loco-discontinuity/feed/ 0
LoCo Day 27 http://www.kuliniewicz.org/blog/archives/2011/11/27/loco-day-27/ http://www.kuliniewicz.org/blog/archives/2011/11/27/loco-day-27/#comments Mon, 28 Nov 2011 04:18:09 +0000 http://www.kuliniewicz.org/blog/?p=2350 Success? The basic gameplay in the browser is working now, so for the first time ever it’s actually possible to play the game. My loving girlfriend Renee helped me test that it does indeed work with multiple players, and she even beat me in the first real match we played against each other. For posterity’s sake, I will note that the name of the room she created for that first fateful match was named “Stupid time for uncool animals”. (Although I did win against her in some of the subsequent matches, she is quick to point out that there is some lag between changing your player’s direction and when it takes effect on screen. I’m not sure what the precise cause of that is yet, since lag over a LAN should be minimal.)

Although the game is playable in the most basic sense, there is a huge amount of work to be done to make this something that could be exposed to the public. Heck, right now the game doesn’t even provide a way to distinguish your player from the others on screen, so the beginning of each match usually involves each player frantically trying to figure out which one they control before they run into something and die. That needs to be fixed, obviously. There’s still no concept of user accounts, or even user identities, so all status messages refer to everyone as “someone”.

Also, Renee wants more explosions when collisions occur. The baseline number of explosions is zero, currently.

Sometime soon I’ll try to post a screenshot or two of what this game actually looks like, now that it’s in a state where stuff actually shows up on screen instead of living hidden in the server’s memory.

]]>
http://www.kuliniewicz.org/blog/archives/2011/11/27/loco-day-27/feed/ 6
LoCo Day 26 http://www.kuliniewicz.org/blog/archives/2011/11/26/loco-day-26/ http://www.kuliniewicz.org/blog/archives/2011/11/26/loco-day-26/#comments Sun, 27 Nov 2011 04:00:46 +0000 http://www.kuliniewicz.org/blog/?p=2348 Continued work on client-side support for the game. I realize the JSON format I had defined for sending game state to the browser wasn’t very useful for what the client-side JavaScript needs to do to display the state of the game on the page. Instead of doing additional processing on the browser, I decided to do the conversion on the server side, instead of generating JSON that just wraps how game data is modeled on the server. Unfortunately, it’s taking me longer than I anticipated to get my test cases working again following the changes, which suggests there’s some corner cases my existing code isn’t handling properly.

]]>
http://www.kuliniewicz.org/blog/archives/2011/11/26/loco-day-26/feed/ 0
LoCo Day 25 http://www.kuliniewicz.org/blog/archives/2011/11/25/loco-day-25/ http://www.kuliniewicz.org/blog/archives/2011/11/25/loco-day-25/#comments Sat, 26 Nov 2011 04:00:37 +0000 http://www.kuliniewicz.org/blog/?p=2346 Now the server actually runs the game when everyone in a room is ready to play, instead of just waiting for a few seconds and then claiming the game is over.

At the moment, however, there’s nothing on the client side that understands the game, so the next chunk of code to write is the JavaScript (ugh) that implements the game logic on the browser side. When the game is actually running, the client and server are running the game logic relatively independently of one another, with messages being send back and forth only to update each other when a player changes direction. This way, there won’t be a bunch of unnecessary traffic crossing the network.

I also think at some point I’m going to need to change how the server maintains the state of all the rooms. Right now, it’s a Map stored inside an MVar, but that means the MVar effectively acts as a global exclusive lock for anything that wants to do anything with a room. Not a problem for testing, but I bet that’ll be a big problem with even just a moderate load. I think I’ll replace that with a TVar for the Map itself, and another TVar for each room. Using software transactional memory instead of exclusive locks will allow multiple threads (i.e., multiple requests) to operate on pieces of the state at the same time. This matches the actual use much more nicely:

  • Most operations are just sending and receiving messages via a room’s channel, so the room and Map themselves aren’t being modified. Read-only operations are nice for STM.
  • Less commonly, an existing room is being modified (e.g. someone entering or leaving, or games being started up). This modifies an individual room but leaves everything else alone, and with each room having its own TVar, these within-room writes can be isolated from other write operations.
  • More rarely, rooms are created or destroyed, which is the only time when the structure of the overall Map itself needs to change.

Using TVars instead of an MVar also gives a bit more consistency with the message-passing bits of code, which are already using STM objects (namely TChans and TVars). Perhaps each request could be treated as a single STM transaction, instead of separate bits and pieces being run separately and intermixed with other IO operations. But since the next chunk of functionality will almost be all client-side, I probably won’t get around to migrating more stuff to STM for a little while.

]]>
http://www.kuliniewicz.org/blog/archives/2011/11/25/loco-day-25/feed/ 0