@shedletsky if you would like to write more java/C# style classes in js you can look at the new class syntax in es6 (which the screeps version of node uses) documented here. after that tweak class syntax is mostly in line with what you would expect from other OOP languages, and you can use it as such.

If you want to add types I would really recommend using typescript, it is written by M$ and (despite that jab) is excellent for adding on-the-go typing to a typeless language. typescript just lets you run a transpile into normal javascript but does type validation beforehand. it also has a sublime plugin which works pretty good.

To really understand lodash and its power (and the power of alot of JS in general) I would recommend doing some research/reading on closures. especially what they mean for passing functions around (not as useful for screeps but very powerful with promises in other contexts).

@roncli if i had to guess this is probably because market transactions are intents, and just like 2 creeps trying to move to the same spot, if more than one player (or the same player from 2 different terminals) tries to buy something in a deal, the deal can succeed on call (the game has verified that there are no outstanding major issues with your deal (i.e. you don't have enough credits)) but fail when the intent is processed.

This leads to an interesting question, it isn't stated in the docs (at least i don't think so), but does HARVEST_MINERAL require an extractor?

I do think that berserk has interesting properties, assuming that it will affect enemy as well as friendly creeps, however commander by far has possibly the largest number of abilities whose level scales the cooldown rather than the effects, which means that it often is just using one ability on one creep repeatedly (encourage much?) at lower levels.  And while summon sounds nice, why would you ever get more than one or two levels of it?  perhaps if you had your commander sitting next to your storage, but even then, how much does this actually help your economy unless you spawn creeps knowing the commander will always be there? I honestly think that summon should effect enemy creeps.  This would allow the command to (potentially) exhaust multiple enemy creeps at range and summon some of them individually to be disabled and murdered by multiple of your attacking creeps, allowing you to harry and whittle down enemy forces at range.

I like the above, but agree that sharding the already small userbase might initially have some problems.  Honestly we could get the 2 ish worlds mentioned above with one (small?) tweak, which is that all players in a noob zone have to elect to leave the end the newbie zone protection(e.g, no timer), if one player is rushing to get out of the noob zone, they can just spawn somewhere else,  I also think that having over a certain amount of GCL should restrict either your respawn into noob zones or your actions while in a newbie zone (willing to discuss this) mainly because as dormando suggested, higher codebase/GCL players that are themselves wiped and spawn in a newbie zone are incentivized to wipe their newbie zone.

As far as power and boosts being a problem, I don't necessarily disagree, I feel the threat of bigger codebase players, but honestly that is part of the draw for me.  It is much like EVE mentally in that there is the threat of death and the paranoia associated with that, except i'm telling the spreadsheets what to do, rather than just staring at them.  I do think it would be (easy? possible?) for someone to build out a private server that has different stats around combat  and no power, no boosts etc.  Some community effort on this part would be great, I do wonder if the default phrase spoken to newbie players would at that point be "hey this is too hard to start, go to this server instead (insert simplified community server)", and that this would greatly lower player counts in the main game world.

without some major restructuring to the way power mining works, i don't think that having power spawns earlier is going to help much.  Remote mining and automated scouting are bare minimum for harvesting power at the moment, automated scouting (since you only get observers at rcl8) is already going to be a good amount of time to write.  And if you have remote mining, you can get to RCL8 pretty easily given you can pull in 2-3 reserved rooms that you remote mine for energy.  The only way this makes sense is if you use your terminal (at RCL6) to sell energy or minerals you mine to buy power with however this has 2 potential problems:

1. power's value on the market is almost certainly going to rise if it hasn't already, which means you'll be selling a large amount of minerals (or energy slowing your gcl/rcl gain even more) for a small amount of power (expected).

2. Even with all of the problems with the above, say you get a power spawn at RCL6, get enough energy to get a lvl2-3 power creep (processing this power also takes code and a large amount of energy usage) and spawn it.  How much time do you think it will take to code up efficient/useful behaviors for your new power creep? how much of this time do you think could be better spent just writing remote mining?

If this is what you want (ignore gcl/rcl increase for power increase at low lvls), then I can understand your ask, otherwise i just don't think that it makes much of a difference when you can build power spawns.

Dissi is correct, but a greater thing to understand with this game is that every command you put into the server is *NOT* resolved immediately.  Your code runs, generates some calls against the game server (along with all the other players), and then the game server resolves all of the different calls made by the different players.  This means some interesting things:

1. move can return a 0 (success) but your creep may not move on the next tick (for various reasons, but most generally because another creep had a move call to move to the same location and the server chose that other one to "win")

2. any action to create things (spawning creeps, creating construction sites, creating flags, etc...) only happens on the next tick.

3. any action to destroy things (creep suicide, building destruction, flag destruction, construction site removal) only happens on the next tick.

4. related to this, creep actions that require resources (like repair, building, or transferring) require that the resource be contained in the creep (or structure, as this is also true of labs, towers, storages, etc..) before your code gets run (i.e. on the last tick). which means you can't say harvest energy and immediately use it to upgrade a controller on the same tick.

  So I know this is a solve-able problem, and barring this feature request actually being fulfilled, I will probably just solve it by putting an adapter class around all construction related calls i make so that I can auto handle them. However the issue is like this:

When creating a construction site, without memorizing and tracking the room position at which the construction site was created and the structure type (since some structures can be built on top of each other) and then running lookForAt every tick you cannot easily track a construction site from room.createConstructionSite call to fully produced structure by using the same id all the way, however there doesn't seem to be a reason for this.  Logically it should be easy to produce a preliminary id that room.createConstructionSite() returns if it doesn't return another error (in the same way that spawn.spawnCreep() returns a creep name of a future, non-existent creep)

It should also be possible on construction of the actual structure, to re-use the same id, destroying the object related to the construction site, and then creating the newly created structure object with the previously used id.  Alternatively, if this interferes in some kind of auditing that is done, successfully creating a construction site could create the id for it (the construction site) and the eventual structure that is produced by it, before the eventual structure is ever actually produced, also allowing easy tracking by players.

It just seems that this is an arbitrary exclusion since the other main way players produce entities in the game world (spawning creeps), there are a number of ways of tracking the creep from spawn call (which returns the creeps name) to finish (fully spawned creep).

http://support.screeps.com/hc/en-us/articles/204825672-New-main-loop-architecture

This basically means the only code that runs every tick is the code inside (or called by) your main.loop function. The reason this works (or resets) every time you save code, is because committing code is one of the things that causes a new global to be created (because things could have changed).

To bonsai's point (\o hai bonsai) I do think this game could do with a bit more scaffolding (although not too much as selection of goals is part of the game too imo) I even thing it would be cool to incorporate that into power creeps, such that completing a limited set of quests/achievements can get a player into the power game early (i.e. grants enough power to have a small/weak power creep early on).

Having said this, and having started ~3 months ago, I am more inclined to agree with atavus.  I recently got dedicated upgrading, mining, and hauling up and running, and I can't imagine power creeps being more important than any of those three.  I'm currently working on remote mining which until recently was much harder to test (ty artem and the screeps devs for getting the private server running).  Given that remote mining at the very least (not to mention long distance scouting) is required for power harvesting, saying that power as a feature is (at the moment) "available to all players" is like saying that harvesting source keeper rooms is a feature "available to all players".  While it is true, it's misleading at best.

And to artem's response about markets, any trade on power will be a sellers market, making the players selling power (the highest end players that have the time, energy, and cpu to look for and harvest it) even more powerful.