WEED GUN Posted:

Dan0rz Posted:

i can’t see any holes in that, what you think?

This sounds essentially like the “state-saving” notion I posited a few posts up, except that I’d like to see it implemented site-wide. (E.g.: You leave on the bookmarks screen, you come back on it.) This way, when you start pwning a thread in a forum, and only when you do so, does your daily forum-visit counter decrease, and only when you personally click out of the forum will you end up leaving it. I’m bumuming this could be implemented (relatively painlessly) in the code used to maintain a user’s session.

Firstly, I’ve updated the code on the dev server to only record a “visit” once you perform your first attack. You can enter a forum, re-arrange your toolbar, even go into a thread. But the second you start to interact with it, the site logs the visit. Seems to be working well, will push it live when I get a chance.

Technical Stuff

Even though it’s pretty simple to play, the battle system for Forumwarz is quite complicated. There are lots of different abilities that work in different ways, mixing in with properties that may or may not be there. Early on in development I noticed that a simple operation like eating a Happidex was resulting in like 30 database queries to get and update all the relational data, which wasn’t going to scale easily, especially since Ruby has some (justified) notoriety as a slow language.

What I ended up doing was loading all the data you’d possibly need when you enter a battle, then creating a state machine in Ruby with everything a battle could need. This state machine is serialized into a string and shoved into a memory store (Memcached.)

Every time you attack, it retrieves the state machine from memory, does the operation, sends it back with virtually no database access. The great news of this approach is it’s very fast. The bad news is it doesn’t work for long lasting operations. In fact, if you don’t finish your battle within 60 mins the memory will expire.

Anyway, what I’m getting at here is the session data is not around long enough to remember it if you leave for more than an hour or so. I could try and implement a system where the serialized session is stored to disk somewhere, then restored, based on how people do things, but it certainly wouldn’t be trivial Log in to see images!

tl;dr version: the programming involved to persist an in-battle state is hard.

Anyway I’m not saying never, just not right now Log in to see images!