There’s no new content besides some portraits, and no new game mechanics, but just about all of the game server was recoded.
Why all the work for no change right now? Well it opens up possibilities for future content. There’s far less restrictions. It’s also because I want an engine that can be used to make all sorts of games. I had the goal of making sure it could be used to remake anything that’s on Byond, RPG maker, table top games, and so on. But you know, the whole running in the browser, being easier, having a networked development tool so people can collaborate, etc.

The result is that things are a bit more complicated, since things are more general purpose, but hopefully I still hit on that goal of making something easy enough to use for just anyone that can write. I’ll be making a tutorial/guide post about how to use the tool soon.

Yeah this took a lot longer than expected.  I kept waking up thinking of potential problems, or a better way to do something, and redoing a lot that was done the day before.  I also ended up doing way, way more than I initially intended to. I wanted to have a minimal amount of the game hard coded, and more of the logic being directly exposed in the tool. There’s still some ways to go on this.
Initially I hoped I could rush through this, but a strong foundation is needed so that there aren’t issues later.

I still need to recode the client, add custom events and event triggering, custom functions, tick-interval function execution, and to make less of LEWD hard coded and instead coded through the tool.
When those things are done, I’d consider the game an alpha instead of pre-alpha

Site:

• Registration and login pages now use SSL. (Improved security)

Game Server:

• -Function/argument lookup is now a hash rather than switch. I found that to perform better.
• -More changes that put it in line with the new dev tool. IE, the custom logic that can run on creation, instantiation, and other events.
• -New dialog options on scenarios allow multiple function calls, as well as multiple arguments. IE before I could only put one requirement on an option, but now there can be multiple ones.
• -Buttons on items can now have arguments. They work the same as scene otions.
• -Eliminated lots of function calls when it came to simple simples. (performance increase)
  Funny thing is that lots of people will tell you to make function a lot, and use them a lot. It compartmentalizes the code and makes it more organized.
  That’s true, but there is a performance overhead for functions. When your logic is something that’s able to be done millions of times per second, wrapping it in a function is a really significant slowdown.  I rewrote a lot of code to still be clean without having those function wrappers.
• -Deleted ~80% of the code on the server and wrote new code. (New amount of code is ~19% smaller despite doing far more)
• -Deleted ~60% of the code on the dev tools and wrote new code. (New amount of code is ~90% larger)
• -Replaced the underscore library with lo-dash.
• -Every function is now agnostic to where it’s being called from.
  Before functions were limited to their context. Like items had an equip function. Dialog options were limited to things like pointing to another scene, ending, or opening the system map.  Now every function can be used anywhere, which opens up a lot more possibilities. Before I was running into some restrictions on having to have the bulk of logic run on the start of a scene.
• -Unloaded Scenarios no longer count as a completed “roll”.
  This means if the Scenario rolling that happens when you move rolls a Scenario, but the Scenario otherwise ends before finishing loading(is completed, or some other requirement not met), it will continue trying to roll the next one.
• -New system of object update notification.
• -Proper support for bools, objects, arrays, etc.
• -Added a way to add new custom functions/arguments without requiring a server restart, similar to how content could be added without requiring a restart.
  This is like the “hasQuest” function. The code for that would be looking at the player object, seeing if a supplied quest is in the player’s quests array, and returning true if it is. Normally adding new hand written code like that would require a restart, and only the references of “hasQuest” in content didn’t. Now new hand written code can be added “just in time”.
  The foundation for this is set, but there isn’t an area on the tool to actually add them. Plus, there needs to be a way to give a good indication of what the objects passing through Events look like in order to really write them. That’s difficult, given how highly dynamic things are, but doable in time.
• -Probably fixed the bug where people could move while a scene was active, and/or could get stuck and unable to move.

Game:

• -Some characters have been renamed. Alraune -> Luarane Rualane.
• -Species for Spajss Ajss set to Taurran. Taurran, Terran, get it?~

Client:

• -No longer assumes that just because the user’s browser assumes websockets, that a websocket connection can be established(due to poor security software, faulty router, or a very closed ISP that blocks those sorts of connections, IE in many Middle Eastern countries). It now establishes an old and reliable(but slower and less efficient) connection and then attempts to upgrade it to websockets.
  This should allow more(almost everyone, I hope) to connect, if they couldn’t before.

Known Bugs:

• -Since I essentially entirely recoded the back end, and readded all the content largely by hand, there is surely A LOT of bugs with scenes, and may still be a few crash bugs left.
  If you notice dialog options directing you to a scene that doesn’t look right, or things just looking messed up, report them on the forum, please.

A lot of recoding was done on the server, in addition to the new tools.
I ran a number of performance tests to see where I could perform things.
For example, I had a haunch that a switch() became slower than a hash of functions when you start getting a few dozen of them.
It’s hard to know what sort of magic happens with the optimizations of Google V8. Traditional knowledge of optimizing in C just doesn’t apply. Things just have to be tested to see. So, test I did.
My guess was a switch would be handled like a chain of if/else.  A chain of if/else becomes slower the further down it goes, as it has to check so many failures before it finds the block to run. I didn’t know if switch() had some secret optimizations to make it faster, and I needed to see.
On the other hand, a hash lookup isn’t the fastest thing in the world(nor is it slow. It’s faster than array[array.indexOf(lookup)].)
So I tested. With just half a dozen things populating the hash and switch, switch was faster by about 25%.  But when I put two dozen in there, hash became 50% faster at 18million ops/second with my simple functions versus 12million ops/second of the switch.  This gap grows wider and wider the larger the hash and switch both are.
http://jsperf.com/fn-hash-vs-switch (Results will be different in Firefox. Chrome gives the more optimistic ones, as it’s similar to V8.)

Lots of recoding on the server also just had to do with making it more modular, to match with the tools, so it can be used for making a wider variety of games.

Going to be taking a break. Playing games, exercising, checking up on the node v0.12 update notes and new features.

I also wore out a keyboard and I’m getting used to a new one, so programming is a huge pain right now.