3. This game has potential if all the irritations are fixed...

This game has potential if all the irritations are fixed...


  • I've just made a number of posts of bugs and feature requests, but here are my general thoughts:

    I love the idea behind the game; it feels like a modern version of core war combined with a typical simplified Flash RTS. (Though I don't think this is quite "The world's first MMO strategy open world game for programmers" - schemaverse has you beat by at least three years, judging by the date on this blog post

    The API is fairly well documented, though there are a number of irritating edge cases (how do you tell when a creep dies? Dead creeps seem to sometimes hang around in Game.creeps with zero hits remaining or undefined ticksToLive, but a newly-spawning creep also has undefined ticksToLive, so my solution is to treat a creep with one ticksToLive as dead, since it'll go away next tick). And the distinction between dinstance and range caught me a few times; attacking the "closest" enemy will attack the one with the shortest path, which might miss one close by but with a longer path. These aren't insurmountable issues, but the lack of a good development environment makes these bugs painful to track down.

    And that leads to my major issue with the game - the development environment is impressive for a small online game, but miserable for any real work. I've posted separate bugs or wishlists for these, but the fact that the only way to "save" is to make the code live, and typos cause the entire system to grind to a halt is irritating. More seriously, testing against enemies seems to require either spending time (tens of minutes? I haven't actually tried) building up a custom map to test what you wan't, or waiting in the survival simulation for the right set of enemies to show up. And then when something goes wrong, pause the game, add some debugging statements, run a step, see what happened. And then suddenly there's an undefined reference! Okay, comment out the offending line (and anything depending on it) and add more debug statements to the area to figure out what's going on. But those don't trigger! Because the creep that caused the error just died, and so that bit of code isn't being hit at all anymore.

    There are just too many ways things can go wrong in ways that are undetectable until the exact right trigger, and then there's no way to go back and re-run that exact situation and see what happened. This is getting more and more frustrating as I try to add more and more elaborate functionality.

    And finally, the straw that will keep from playing (at least for a few days; I may be back): the editor sometimes losing code if you pop it out, start a new game, and keep editing in the old window. Losing ten minutes worth of work isn't the end of the world, but on top of all the frustrations above, I just can't bring myself to re-implement it.

    I'll definitely be keeping an eye on screeps (and I have a few more ideas I'd like to implement), and might come back to play with the MMO side of it. But for now, I'll have to satisfy myself with my (current) third place on the May survival.

  • Dev Team

    Thanks for your interesting points, we will take them into account. Here are some answers.

    (Though I don't think this is quite "The world's first MMO strategy open world game for programmers" - schemaverse has you beat by at least three years, judging by the date on this blog post

    Schemaverse is not a real-time MMO with a shared and evolving world. It's a round-based game with a limited number of players in each round.

    (how do you tell when a creep dies? Dead creeps seem to sometimes hang around in Game.creeps with zero hits remaining or undefined ticksToLive, but a newly-spawning creep also has undefined ticksToLive, so my solution is to treat a creep with one ticksToLive as dead, since it'll go away next tick)

    A dead creep is just destroyed, i.e. removed from the Game.creeps object. A creep which is just created, but not spawned, doesn't have the property ticksToLive since it is still being spawned, and his spawning property is true. If you observe any creeps with spawning=false and ticksToLive=undefined, this is a bug, please report it, preferrably with instructions on how to reproduce the situation.

    And that leads to my major issue with the game - the development environment is impressive for a small online game, but miserable for any real work.

    Please take note that the game is now at a very early development stage. The Early Preview means that it is not a final, complete product. We understand that many issues need to be addressed, and work on them. For example, while the Custom Mode is already sufficiently functional and allows reproducing some game situations, we understand that it would benefit from some game situation import/export function. We plan to add it soon, as well as other improvements, like separate deployment targets, commits history, etc.

    Also, soon after the release, we're going to publish the game engine as a standalone node.js package in order for you to be able to launch the game simulation completely locally and thus test your own scripts.

    And finally, the straw that will keep from playing (at least for a few days; I may be back): the editor sometimes losing code if you pop it out, start a new game, and keep editing in the old window. Losing ten minutes worth of work isn't the end of the world, but on top of all the frustrations above, I just can't bring myself to re-implement it.

    For maximum ease of script writing, we recommend that you use your own local script editor with synchronization via Grunt.


  • Thanks for the reply! I've been playing with the live game, along with a quick script to sync my local code using the API. The local development and better syntax errors from the live game are making my life much more pleasant.

    Regarding dead creeps, I'll see if I can run into that again and get it consitently.

    And yeah, I understand that the game is at an early stage; this was a combination rant and list of the things that most irritated me; I was hoping that you would fix them. And sure enough, I learned in another thread about /api/user/code (I saw grunt, but I don't want to deal with a whole new tool when I can use a couple of lines of Ruby to do the same thing), syntax errors working on the server, and use strict, which handle most of my complaints about development.

    It sounds like you have solid plans to handle my other complaints around debugging; I think things are good enough to live with for now.


  • Was searching for a faster simulator / simulation tool and came across another thread that highlighed and linked to this thread in particular:

     

    • Also, soon after the release, we're going to publish the game engine as a standalone node.js package in order for you to be able to launch the game simulation completely locally and thus test your own scripts

     

     

    When is release considered? I see its on Steam which is where I got the game but how long will this tool be? Finding the 500% limit in the current simulator no use really as I still need to wait hours to get to the point where I can test things. 

     

    Also the problem with the simulator is a single room, this doesn't allow any testing of multiple room or room attack code and testing code in the live world has caused me a number of problems in the past. 

     

    Also sorry for the necro. 


  • Esteemed colleague,

    Your feedback is much appreciated. Here are my opinions on your points:

    I. Schemaverse is not an mmo and the AI programming part is considered a secondary not the primary way to play.

    II. You should use the spawning property to avoid processing of creeps which are not yet alive. Every other creep in your Game.creeps array should be treated the same (imho).

    III. You should definitely, without a doubt use an external editor. I strongly suggest webstorm if you are looking for an IDE which takes care of minor details for you or sublime if you prefer to keep things light. This allows you to use a proper git structure for managing your code. If you must use the editor for whatever reason, then accept the various inadequacies it might have. Eg, writing/saving code whilst looking at the world map will be lost once you zoom into a room.

    IV. Regarding testing your battle code or more difficult scenarios. Simulator is one way which works, although I haven't used it much. The alternative is to just send out units to neighbors or source keepers to test things out.

    As a closing note, you should realize that this game is slow. Really, really slow. If you make a mistake and lose a few ticks while understanding what is happening, it will not have a true impact.

    For my first 7 days, I think an aggregate of 3 days was lost due to script errors.

    Kind regards,
    Atavus

    PS: I've been playing video games since 1990 and I can tell you this one is a pretty unique experience. It may draw inspiration from a lot of other games, but after devouring thousands of games, I can say it is quite an original experience.