ACID Cloud databases to keep an eye on
So far, "database in the cloud" options have been pretty limited. You have Amazon's SimpleDB, which is slow, eventually consistent, and not really a database except in the loosest sense of the word; there's Amazon RDS, which is a managed MySQL instance and scales up, but not out; and of course you can run database server yourself on any of the cloud servers out there (Amazon EC2, Rackspace, GoGrid, Linode, Slicehost, etc etc). But none of these offer one-click scale out ability, which is really the hardest part of database scaling. However, there are a few options cropping up, most of which are in beta.
Quasi-turn-based game design: movement
I'm fiddling around with building an online browser-based game right now, but am having some trouble trying to figure out how and when different units should move (since they can move at different speeds). The game is turn-based, i.e. actions happen in fixed time intervals, but it has real-time elements, since each unit is on its own clock -- actions that happen every 5 minutes for one unit don't necessarily coincide with actions for another unit that also has a 5-minute tick interval. In my mind, these are the requirements:
- No unit should move multiple tiles in a single turn -- in a given turn/tick/whatever, they move at most one tile.
- Some units can move faster than others -- namely, cavalry can move 3x as fast as infantry, for example.
- Units that have varying movements speeds could have the same attack speed -- just because they move faster, doesn't mean they do everything else faster.
- The speed of units can change dynamically -- if they are Haste'd by magic spell, or Slow'd by a bog, then...they do what you'd expect.
So far I've come up with three strategies for how one might implement these in a game.
Ye Olde Key-Value Store: BerkeleyDB
This weekend I explored the possibility of implementing something resembling Redis but on top of an existing, mature database engine. It's a key-value store, it has transactions, it supports locks and concurrent writes, replication, etc. While it ultimately didn't end up panning out (trying to get sets to work efficiently just wasn't working out), it was an interesting learning experience for me familiarizing myself with the Java DPL (Direct Persistence Layer) in BerkeleyDB. (Let that be your warning that there's Java in this post!)
AutoPull: you push, it pulls
So you use GitHub and some compiled language, but not everyone can or wants to compile the source, they just want the artifacts. I made a tiny app that aids in this sort of thing. If you have ever wanted to execute an event in Ruby in response to a push to a repo via GitHub's Post-Receive URL hooks, this is probably a good starting point.
Additionally, it doesn't have to just be used with GitHub (anything that can automatically hit a URL works), and it doesn't even have to be used for pulling down source -- it can send an email or something. Right now I'm using it for HydrateJS -- when I push some new CoffeeScript to GitHub, it automatically pulls and rebuilds the .js file on my server.
HydrateJS: Smarter Javascript Serialization
Finally, here it is: HydrateJS.
It's a library that helps you serialize proper Javascript objects, more than just hash-like objects like JSON.stringify can handle. Anyway, I put a lot of time into the documentation inside the library as well as on the Github Pages link, so check those out! There is also a full suite of specs.
For some of the technical challenges, see my previous post.
Let me know what you think in the comments, and if you're using it, feature requests, etc.
Javascript Serialization
Note: RSS subscribers, I've (finally) enabled summary-only feed entries, so you will have to click through to see the full post.
Have you ever wanted to serialize entire Javascript objects? When I say objects here, I don't mean the simple hashes that you get by saying {foo: "bar"} -- I mean instances of your User, Product, Query, etc prototypal Javascript instances. JSON.stringify gets you part of the way there, but notice this doesn't work:
Inconvenient, to be sure -- and to make matters worse, there don't appear to be, well, any libraries out there that handles intelligent serialization of Javascript objects. So that's what I'm writing now (but it's not ready yet). Look for it soon though!
MVC, Games, and a message bus
It seems to me that many approach the use of MVC in games with skepticism, but the more I develop a game in MVC, the more I am reassured in my decision to do so. I operate by the principle that models should absolutely not know about their view(s) (or controllers) -- models should be completely standalone chunks of state and logic that can only reference other models. However, this can present us with a few problems.
Cr-48 Hardware
For those curious exactly how much RAM, HD, and what CPU the Cr-48 has, the chrome://system display is rather helpful. Hit the jump for details.
Time matcher for RSpec2
I've found myself reusing this matcher a bit for time-sensitive tests, so I thought I'd share it. It allows you to verify that a block took a certain amount of time to execute.
Ruby Monitor Basics, or, How the heck do I synchronize producers/consumers
Have you ever written something like this?
threads = [] threads < < Thread.new { something_slow } threads << Thread.new { something_really_slow } threads << Thread.new { go_take_a_coffee_break } threads.each {|t| t.join} puts "all done!"
This works fine, but...it's expensive to start up and stop threads (even green ones), and what if you instead used/needed Ruby's queue:
1 2 3 4 5 6 7 8 9 10 11 | require "thread" q = Queue.new q < < 3 << 10 << 10000 < 2352352 threads = [] 10.times do threads << Thread.new do num = q.pop # marker 1 puts "#{num}: " + calculate_fibonacci_for(num) end end |
For those of you who don't know, Queue is basically a (threadsafe) array that puts the calling thread to sleep if #pop is called on it while it's empty, and wakes it up again when it's not empty.
But how do we know when we're done? You can't call #join on all the threads; they never terminate because they're blocking on q. Here's where monitors come in.