|
|
|
|
|
|
by mike_hearn
4234 days ago
|
|
|
Initial thoughts: very cool, very nice API, nice minimalist graphics, helpful tutorial. Lots of things I love about screeps so far, having done the absolute minimum of playing with it. Things I do not love so much: it appears to have serious performance issues, at least in simulator mode. Though the UI is responsive, my screeps routinely stopped for several seconds with a "CPU limit exceeded" message printed to the console. How is that possible, given that all I was doing is playing the tutorial and I had only a handful of screeps on screen? I am hoping they haven't backed themselves into a corner here by building on Javascript and HTML rather than simply doing a desktop app, because the game mechanics have a lot of promise. I tried pressing the button to double the game speed but it didn't seem to help much (I guess that won't function when connected to a server). Also, no way to zoom the playing view? The screeps were tiny on my retina macbook. I could barely see what was happening. But biggest dislike: Indiegogo to complete the game? I'd have preferred a more traditional model in which maybe there are fewer features to start with, and they simply charge me a monthly subscription or a one-off purchase price. Crowdfunding is best used IMO to develop public goods or public infrastructure but Screeps is just a plain old proprietary game - nothing wrong with that, but it seems somehow bogus to expect people to give you the money to finish it, for free. Moreover it sounds a lot like they haven't actually got the server side mode working yet. That's fundamental to the whole concept. If they didn't build it yet, they don't really know if they can - what if the game just doesn't have good enough performance to work well? I think I'll pass on this crowdfunding campaign, myself. Still, I'm looking forward to when they have the problems worked out (if they can) and I can just pay an honest buck to play. I can imagine it being a huge time suck :) |
|
|
Its also possible that their rate limiter is not tied to the performance of the system, but rather to the wall-clock. Given that the simulator runs in the local browser, there would be a lot of variability in this kind of thing.
For my ant simulator, I'm focusing heavily on performance testing and instrumentation for precisely this reason. Having to adapt to various browsers means you need to have some pretty tight metrics.
Performance in the browser is an interesting problem. I've seen some advanced libraries rely on Acorn.js - a JavaScript based JavaScript interpreter - because its faster than some built in JS bits on older browsers in regards to processing large amounts of JSON. Boggles the mind.
Once this thing gets up and running, I doubt the limitations of the browser's runtime will be an issue since it will be relying on node.js on some type of cluster server.
I'd really love to dig into this thing on my own. I hope they get funded and start hiring.