Devember - Screep Studio

Day 25

Did a bit of work cleaning up my code, as mentioned previously I am going to leave the graphics until later because I started to get too caught up in it and lost focus on the the functionality I need to make the client usable to actually play the game.

But I couldn’t stop tinkering so I abstracted the fixed terrain rendering code, now I have a TerrainRenderer base class that the RoomGraphicsScene uses and I’ve implemented two sub-classes ClassicTerrainRenderer (to do the basic blocky graphics like the official client) and TiledTerrainRenderer to do the fancier tiled terrain rendering … So now I can switch between them by just instantiating one or other of the classes. This way I can concentrate on the core functionality and if I get motivation, feel creative or find a nice tileset, I can do a little work on the tiled terrain renderer and switch back to the basic terrain when I want to work on game mechanics.

Not content with that I decided to upgrade my test server to make it more stable so that I can run the simulation 24/7. The default install uses a file system based database called Loki which is not very performant. There’s a mod available to allow the game server to use MongoDb instead so I figured last night was as good a time as any to make the switch.

Long story short, fun and games with NPM followed and I ended up with a broken server. For some reason every time I tried to install the server mods over the base install NPM would trigger the uninstall process for the server … which resulted in half the packages being removed.

Anyway, after reading bug reports about the same issue (which was supposed to be fixed in the previous major release) and several hours of swearing and declaring my hatred for NodeJS, I have my server working again and it’s using MongoDB.

The good news is, with MongoDB it’s performing a lot better. Usually the server would slow down and the game ticks would lag after a few hours, now it’s been running over 16 hours and the Creeps are still flying around the room.

I’m going to leave the Creeps building some test infrastructure for me while I go have some Christmas dinner with my family.

Happy Christmas all :slight_smile:

Shecks

2 Likes

Day 26

Did some work on the client console, it’s no longer read-only. The player can now submit commands from the Screeps Game API (and pretty much any JavaScript) to the game server for execution.

At some point I’d like to add auto completion to the command prompt for the known Screeps API objects (e.g Game, Room, Creeps etc) and perhaps a basic command history. But I don’t want to get hung up on it, this will do for now.

Next I’d like to start work on the Toolbox panel so the player can create construction sites in the room. This is currently possible via the console by issuing commands from the Game API (Supposed to be used via the JavaScript for your bot A.I) with a command like: -

Game.rooms['W8N3'].createConstructionSite(21,22, 'storage')

But there’s a dedicated REST endpoint available which I think the official client uses behind its toolbox and a graphical point and click interface is much more user-friendly.

Shecks

2 Likes

Day 27

Started work on the toolbox panel. This will probably take a while to complete because its a custom drawn QListWidget. I want to display icons beside the text for each of the tool/structure types using the same graphical rendering as used to draw the entities in the room. I don’t want to duplicate code so I need to extract the entity rendering for each structure type from the existing RoomGraphicsItemXXXXXX classes into reusable XXXXXRenderer classes that I can use to draw the icons in the toolbox. (e.g SpawnRenderer. ControllerRenderer, TowerRenderer etc)

The toolbox also needs to display a description for each type of structure along with constraint information about the structure (e.g What room controller level is required to create the structure, how many of the structures can be created in the room based on the RCL etc)

Also, I am trying to figure out a nice way to switch between room item selection mode and structure creation. Thinking of adding a “Selection” tool as the first tool in the toolbox that needs to be selected to enable the existing entity selection, panning, zooming functionality in the room view, something like how painting applications with tool palettes work.

Shecks

1 Like

Day 27 - Still

Getting there … been a while since I implemented a QItemDelegate in Qt. Measuring and wrapping text is just as fiddly as I remember though.

Shecks

Day 27 - Still

Random progress video if anyone’s interested. (Just creeps refilling the spawn and extensions - nothing exciting)

Upgrading the server to use MongoDB for the back-end database seems to have made huge performance improvements, the server has been running 24/7 for a couple of days now and there’s no noticeable slowdown.

Still working on refactoring/extracting the entity rendering code …

Shecks

2 Likes

Day 28

The plan for today was to continue extracting the rendering code for the room game entities so I can use the same code to draw the tool icons for the toolbox panel. So far I have the creeps (although not needed by the toolbox panel), the extensions and the spawn code extracted.

TL;DR - Skip to the screenshot below

While I was working on that I noticed that I had an “undocumented feature” in my code. If I left the client running for a while without doing anything then tried to submit a command to the console the server would return an authorisation error.

Authentication works using an initial signon (in the case of my test server with the screepsmod-auth enabled anyway) using email and password. This results in an authentication token being returned. This auth token then needs to be included in the HTTP headers of any future calls to authenticated REST endpoints.

However, the auth tokens expire. The server handles this by sending a new token in the response HTTP header of any calls to the authenticated REST endpoints which you use to keep your token updated.

My client does this … but … If you leave it sitting there just watching the Creeps going about their business … you never make any REST requests so never get any new auth tokens … then when you return with a fresh mug of tea and actually attempt to do something your token has expired … DOH

Since I had a fresh mug of tea anyway, the cogs started to turn and I thought “I’m already pinging the websocket to keep it alive, why not ping the REST API as well to get new auth tokens?”

My initial idea was to ping /api/game/time as it only returns the current game tick so is fairly lightweight. I wasn’t sure if this approach would be a good idea so I went over to the Screeps chat room on Slack and spoke with one of the 3rd party developers there and it seems to be what they do.

So I went ahead and re-worked my PING code and consolidated into one timer to ping both the websocket and hit the /api/game/time REST endpoint.

But, it turns out that because /api/game/time doesn’t require authentication … it doesn’t’ return the X-Token HTTP header (Kind of makes sense, but at this point I’d finished my tea and cogs had stopped turning). So it’s no good for my ping.

After a bit more digging I found the perfect candidate in /api/auth/me this endpoint returns information about the currently authenticated user and does return X-Token in the HTTP header. The endpoint is rate limited but this particular one is limited to 120 calls per minute and since I am now only pinging every 30 seconds there shouldn’t be a problem.

Long story even longer … using this endpoint the issue was resolved … and there was much rejoicing.

TL;DR - The Screenshot Below

Check out the 1 toolbox button I managed to complete before being side tracked … for extensions: -

Shecks

2 Likes

Day 28 - Still

While refactoring the Spawn rendering code I remembered that I hadn’t implemented the spawn timer. So I added state handling for the Spawn entity and a progress indicator during the spawn process.

Here you can see the results and the use of the console to issue commands from the Game API.

Warning: Viewer discretion is advised, the following video contains violence … and the death of an innocent Creep :open_mouth:

RIP Creep “h2” :frowning: … you died in the name of progress.

Shecks

3 Likes

Day 29

Did lots of code clean up while working on extracting the entity rendering code. Consolidated all the common colours used to draw into a colour palette in the EntityRenderer base class so they are shared between all entities.

Also implemented the graphics for the Tombstone entity.

Warning: Viewer discretion is advised again, the following video contains murder/death/kill :open_mouth:

At least there’s a tombstone fro “h2” this time. RIP.

Shecks

1 Like

Day 30

Added the tower game entity and implemented the idle animation

Then started working on the attack (heal and repair) animations

Warning: Viewer discretion is advised yet again, the following video contains murder by TOWER!!! :open_mouth:

It was the upgrader Creeps that got it this time, I felt like I’d been picking on “h2” too often. RIP.

Shecks

1 Like

Day 31

Well it’s the last day of #devember2k18. I had hoped to have implemented the attack, repair/build and upgrade actions for the Creeps but I need to re-work the state machine for the Creep entity. They have a lot more states than Towers and “I think” it’s possible for them to perform multiple actions per game tick but can’t find any solid information to confirm this so I am going to have to wade through the server source to find out.

Anyway, here’s a video that kind of sums up the state of the project at Day 31

Warning: This video also contains violence, but this time it’s ok because it’s violence against NPC invader creeps coming into my room trying to steal energy … But … we have 4 TOWERS!!! (Well 3 functional and one without energy) … CARNAGE!

Check out all those little tombstones … muhahahaha. RIP :smiling_imp:

That’s it for my #devember2k18. I am going to continue working on my client and might post progress here once in a while if there is any interests. There seems to be a bit of interest in having a standalone client available over on the Screeps forums so I will either keep working toward a complete client myself while I have the motivation/time or opensource the code once it’s reasonably usable.

Shecks

2 Likes

Looks pretty interesting. Not familiar with the Screep thing in general, looks like a self playing strategy game. Or are you in control of one faction?

Having been so deep in Screeps, do you dream about them now?

1 Like

Do @Shecks dream of electric Screep?

sorry, I had to :smile:

3 Likes

It’s more of a PvP game really, most of the the time your A.I (JavaScript running on the server) needs to defend against and attack your neighbours in surrounding rooms. In order to build bigger and stronger Creeps you need to harvest energy first, so you need to have A.I for worker creeps, then you need build structures to store that energy (you’ll need it later to build soldiers to defend when you’re attacked etc). Eventually you won’t be able to sustain your colony on just the energy harvested from your room so you need to start thinking about A.I to go colonise other rooms (or invade and claim the rooms of your neighbours)

At the moment I am not really playing the game. I have a very basic A.I running in a few rooms on my server just so I have test data while developing my client. But every now and then I need to add to the A.I to get the Creeps to build the different structures I want to implement in my client or have them perform certain actions I need to render.

From time to time the server will send some NPC attackers into your room but these are very easy to defeat and there’s an API where you can summon these hostile Creeps if you need to test, that’s what I used to test that my Tower rendering implementation was working (the actual tower A.I is handled by the JavaScript A.I running on the server).

Shecks

3 Likes

Just a little bit :smiley:

On a few occasions I’ve actually solved programming issues while sleeping, I’d be thinking about the problem so much before falling to sleep that when I wake I’d have a solution … I’ve always been a bit strange :stuck_out_tongue_winking_eye:

I once rewrote the page fault handler for my hobby OS after a lengthy session in the pub … the next morning I’d no idea who wrote the code, but it worked :thinking:

Shecks

3 Likes

I like the concept, programming critters and having them do your bidding. Even battling them, if not directly.
ExaPunks had a bit of that in it, they have done a couple of tournaments.

Also, pretty lucky naturally being able to do the lucid problem solving. Damned if I can do it, think I’d need to take a couple of months off to really shake up my reality and learn to question it all the time!

1 Like

Day ?? - Hmmm

Still working on this :smiley:

Finally got motivated enough to make a start on building out the code I need to manage roads (which will also be used for ramparts and player constructed walls later on)

I’ve been putting this off a while because unlike other entities; roads, ramparts and constructed walls aren’t self contained and need knowledge of their surroundings so I can draw them correctly (e.g a road needs to know if there are other roads around it in 8 directions so that they can be connected)

The server doesn’t give any help here so I need to figure out and maintain this data myself. Fortunately all my playing about with auto tiling actually came in useful here because I used the same algorithm. I check the 8 neighbours (North, North East, East, South East … etc) for each road and store a bitmask of flags with each road entity that the renderer then uses when drawing the road.

I also realised that once the server sends me the JSON for an entity I can do what I want with it. So when I do the calculations to figure out the bitmask for the roads neighbours, I just add it to the JSON as meta data which makes it available to the rendering code.

Still some tweaking to do though. The roads need to be updated as new neighbouring roads are created around them and neighbours need to be updated when roads are destroyed. But the basics are there.

A few other additions:

  • Support for rendering the storage container entity
  • Added some basic lighting effects like the official client (glowing and flickering for entities like extensions, energy sources, minerals etc)
  • Added a mock JSON object system for testing. The client now checks a folder called “debug-mock-entities” for JSON files named “.mock” and if one exists it’s content is used instead of the JSON from the server. This means I can simulate different object properties and configurations without having to tweak the bot A.I to create the test case.

Oh, and I added the Steam authentication code to enable me to connect to the live server … don’t tell anyone but it’s handy for looking at more advanced rooms and, with the mock object feature, gathering test data from “other” sources :innocent:

EDIT: Another short video using the TooAngel Bot A.I for testing. This A.I is a lot more advanced than the basic bots I have been using so far so there’s more activity and they build more advanced structures.

Shecks

2 Likes

Day ?? - Janudevery :wink:

Yep still working on this :smiley:

And still putting off working on ramparts and walls … but it’s slowly getting better (even though it seems that every time I implement a room entity I discover another one that needs to be done)

Here’s a room from a crazy A.I on the live server

And one from my local test server

Shecks

1 Like

Day ?? - Devruary

Slowly getting closer :smiley:
I’ve almost got the basic rendering for all game entities done … then it will be time for all the detail and animations.

BTW, is it still ok to be adding updates to this blog?

Shecks

2 Likes

I don’t see any reason why it wouldn’t be ok? I personally think it’s cool that members continue their Devember projects and keep on giving updates. And it’s your thread after all. :slight_smile:

Maybe @Dynamic_Gravity has better idea?

2 Likes

Yeah, updates are always welcome!

3 Likes