The week of March 4-11 was simply insane.

Everything was not as bad as I expected based on my experience in 2012 (this time I actually managed to sleep for a good 7-8 hours a night!), Most likely because I became much more experienced than then, and had at his disposal much more tools. The desire to create something amazing made me spend more than 80 * hours of work on POLYBOT-7 , my game for this year's Seven-Day Roguelike Challenge . (* This is only a week , this does not include preparation time before 7DRL!)

The number of tasks and solutions sweeping through my head during this week was simply exhausting. Sometimes it was tiring, but at the same time, it’s amazing to find hacks that allow you to implement so many functions and content in such a short period of time. Highly. Many. Hacks. Huge technical duty! In the process of writing most of the code, I felt annoyed, but I had no choice - either to choose the shortest route, or risk to fail. The first few days, the code was a little cleaner, but with the approach of the deadline, I started to do really crazy things.

Sometimes this project was hard for me, because the years of “normal” work on roguelike taught me to write down absolutely everything that I do or plan, and also think for a long time in search of the best solution. I had to overcome this habit and just work - not to write about work, but to do it right now! I had to remind myself of this all week.

This article is a detailed post-mortem describing the development of POLYBOT-7. It examines both the whole process as a whole and the thoughts that guided me when making decisions.

Concept - what and why?

Initially, my ambitions for 7DRL were a little less. The goal was to create a simple demo of my Cogmind game with cutting off everything superfluous from it and developing a purely combat roguelike. At the same time, most of the work was to convert the interface to a more concise view with less information, but twice as large fonts and tiles. This could be a model that I could show to people interested in the general theme or style of Cogmind, but who did not have a large enough screen to display the game. I called this version of the concept "Bigmind."

However, after deliberation, the idea began to seem boring to me. This is 7DRL! It should be dedicated to experiments and interesting new roguelike!

I had to become more radical, and at that time I was just sketching notes about the new Cogmind functions, one of which was the top secret Katamari Challenge Mode. I wanted to release it with the big Challenges update this year - in fact, the player has to play the role of a magnet for nearby objects.

Suddenly, it seemed to me to be an excellent basic mechanic that can be used in 7DRL, not to mention the fact that an ideal design would require a bunch of other changes, in fact, the creation of a significantly different game within the same world. 7DRL would have appreciated this idea much more than the simple competitive Challenge Mode, so it has become a new direction in development.

In general, the proposed changes significantly changed the gameplay of Cogmind. You can read the list of similar and different functions in this game in the original POLYBOT-7 announcement , although I will discuss some of them in more detail below.

Of course, there were other reasons why I chose Cogmind as the starting point. Not the last of them was that I did not have to plan and prepare for too long, and I could only focus on developing gameplay or content, not the basics. Without a doubt, POLYBOT-7 was the best fit for this.

One of the best ways to work for 7DRL is to limit the scope of the project, but anotherone of the best ways is to build on an existing game, or at least on a powerful engine or framework. I am well acquainted with the source code of my games and the engine, having worked on them for many years, and the lack of the need to reinvent the wheel really suited me because I am not very good in the technical part - in fact, I work quite slowly, which is bad when working in tight time frame.


The source code for my early projects spawned new projects for many years. I rarely start projects from scratch, instead just changing the code.

(However, remember that 7DRL can be used the way you want, so perhaps your goal will not be to end the awesome game, but simply build the engine or create a new framework that you always dreamed about.)

However, not everything was so rosy! Part of the reason for my not so good result was that at the beginning of the week I did not have a finished design. In 2012, before the start of my first 7DRL, I already prepared everything - I checked all the math, formulas and data intervals, all that was left was to transfer all this to code and ASCII. For POLYBOT-7, I had only outline plans in which there were no details, and this became a problem, because new details that appear can quite easily create a domino effect. And so it happened. As a result, I had to make major changes and additions to adjust the systems, which I did not think well enough in advance.

However, the most serious drawback was that I spent most of the week thinking, not implementation. For maximum efficiency, 7DRL week should be about creating , not thinking over (creating a good design can take more than a week, mainly because ideas usually need an incubation period to check if they pass the test of time or if there is a better solution). Be that as it may, I barely managed, mainly thanks to adrenaline-filled hacks in the code.

Stage before 7DRL

Preparation for 7DRL begins a little earlier than the week itself. In January, I went through several design documents, occasionally opening the latter to make changes when it became chaotic or I wanted to make a significant change to reorganize everything in the fresh document in order to get a good idea of ​​the current state of the design. In 2012, I had a lot of free time for such a job, but this year I was pretty much busy developing Cogmind and other things, so I couldn’t have the necessary time for design. I came to 7DRL with a technically completed high-level design document, but if I had a little more time, I would have improved it much more.

Before 7DRL, I also wrote release announcements on my blog and onitch.io . In fact, I am writing rather slowly, and besides, I knew that I would not have time for good release announcements during this week. As a result, later I made small changes in accordance with the changed design, but basically the announcements remained the same, later I just added a few screenshots. It was also a good opportunity to get acquainted with itch.io, which I had no business with before. It would be fun somehow to ruin everything after completing work on 7DRL!

Before the start of the week, I even designed a cover option using an unused tileset for Cogmind:


Pre-release draft box design.

This simplified the creation of the box design for POLYBOT-7 at the end of the week, after Casper completed the tileset. You may notice a similarity:


The final box design!

UI

In addition to working on dzdokami I also spent a little time in REXPaint, creating layouts UI. Initially, I tried to fit everything I needed into a 106x30 grid, and I tested the interface from the very beginning, because I knew that restrictions could affect the mechanics.

I threw away this first layout pretty quickly:


Layout UI No. 1 (HUD only)

Vertical stripes are too incomprehensible and poorly read, and also do not leave room for additional numbers. Then I realized that you can leave a place for yourself above the list of parts by deleting the four headers / lines used only for type separation. In any case, I can add an ASCII / tile for each part next to each line, and they are automatically sorted, so there is no strict need for these headers. Then came the first serious layout (with notes), although, as you can see below, it was a very bad idea to create an ASCII item that covers the left UI delimiter! (I tried this as an experiment to save as much horizontal UI space as possible)


Layout UI No. 2

It is also important to consider ways to change the overall appearance in order to create an interface that is as different as possible from the Cogmind style. One of the simplest ways to do this is to change the colors, so I (and separately from Casper), of course, first of all I decided to move away from green and try to choose another main UI color, namely orange. Gold on black is a curious theme, as can be seen in this inspiring screenshot of DynaHack.


Sample screenshot of DynaHack with a changed color scheme.

I studied this idea at REXPaint, but, unfortunately, from the point of view of UX, in general, orange turned out to be not quite suitable for POLYBOT-7 mechanics. In Cogmind, the main feature is the destruction of objects, and the whole color scheme tends to the fact that green is considered "good", and other effects and states use their own logical colors. For the most part, everything ungrounded usually requires closer attention. At the same time, the transition standard "green -> yellow -> orange -> red" for damage indicators and labels is preserved, and this theme is constantly applied in various parts of the interface. When changing the primary color, such an intuitive understanding will be impaired, which will lead to less understandability of the UI.

So a decent final HUD layout was born with four additional lines at the top:


Layout UI No. 3 (HUD only, final version)

Later I made other changes, but in general everything remained the same. Be that as it may, since the layout from REXPaint clearly sets out everything, the implementation has become quite simple and this preliminary work has been very useful.

Instead of using a high-contrast style with a black background again, I switched to a low-contrast theme in which a slightly darker text is on top of a slightly brighter background. At the end of last year, I added “rendering filters” to my engine (they are describedin my blog), which allowed me to switch to a low-contrast view by simply changing the configuration parameter. At that time, I didn’t know that I would use them here - the system was just to enable the Cogmind players to customize the interface, but still it came in handy in jam too!


This line in the configuration file does not allow the front layer to be too bright, and also gives a green tint to the whole background.

However, the low-contrast filter itself is a pretty big hack. Cogmind has been developed over the years with the assumption that the background will be black, so in this mode the animations do not always look perfect. Although I definitely will not have time to update the huge amount of particles used by weapons, I can at least improve the look of the UI. All of these changes have been made to Cogmind (which benefited a lot from this 7DRL). I still wanted to do it sooner or later, but in this case the work shifted to the time of 7DRL.

In fact, I had two types of problems that needed to be solved: either force the background to black even in low contrast mode, or change the animations so that their color is linearly interpolated from the background color to the desired one.


An example of the second solution. Note that before the correction, the animation performs linear interpolation to black, and not to the desired one (that is, it first turns black, and then switches to the desired color). After correction, it looks much better (as it should), because it initially knows the desired color.

Before starting work, I also thought a lot about fonts. I wanted something simple - both in terms of appearance and implementation, so for text andI chose Terminus, because it’s a beautiful and pixel-perfect monospace font, available in almost any size. But since I did not want to create a huge spacing of sizes, like Cogmind did (it takes a lot of time to work on this), I forbid the map mode (and HUD) to expand vertically and fixed them at a size of 30 lines. However, the width can be changed, which leads on some screens to narrow the text. However, this is a much nicer option than scaling, which allows text and tiles to maintain their pixel-perfect look directly from the bitmap.

In addition, this meant that with just four different sizes, it was possible to provide support for the entire resolution range. The base square tile of a 12x12 card in 768p resolution uses the 24x24 font (just created using 12 * 2), the most popular 1080p resolution uses 36x36 (12 * 3) font, and the size 48 above (12 * 4, 1440p ) and 72 (12 * 6, 2160p). The text uses half-width cells, which also need four sizes with basic dimensions of 6x12.


My notes written before 7DRL. I carry folded sheets of paper with me in my pocket and throw thoughts on them. My son decided to borrow this sheet and painted something on the back.

Gameplay design

The main goal of the design was to create a quick gameplay in the style of Cogmind, which could be estimated for a “coffee break”, so everything revolved around this idea. Less decisions must be made in the gameplay, so many interaction systems had to be removed. And not only systems, but even the visual effects of weapons that distracted and therefore could slow the player down. With this in mind, for the week I wanted to fix all the slow animations or exclude most types of weapons in which they were used.


Comparison of electromagnetic pulse animations in Cogmind with faster animations from POLYBOT-7. (For reasons of mechanics, I wanted to keep the EMP in the game, so I had to speed them up.)

Another step to reduce the number of decisions made was the complete removal of inventory, although I did not immediately come to such a decision. Notice that in layout # 2 above there is an inventory that I initially imagined as a modal window that allows you to assemble parts and then attach them as I see fit. Very slow! Even with all the automation features, one of the slowest aspects of Cogmind is inventory management, and I thought it would be great to limit it. Therefore, further I thought about an ordered “queue” of parts that are attached after losing the previous ones, but it seemed too complicated for what was conceived as a simple and concise game.

Then it dawned on me that there was no need for an inventory at all - in fact the player’s “inventory” would be the world, which was simplified due to the already existing ability to attract the parts lying around. It turned out to be simple and provided interesting consequences for the gameplay.

After attachment, parts cannot be removed individually, because then automatic attachment of parts will be pointless, because then players will simply disconnect unnecessary ones, because the rest are nearby (more tyagomotina!). Therefore, in addition to the loss due to destruction (slowly and unreliably), we need another way. And then another important part of the plan appears: the mechanics of the Cleanup.

Cogmind already has a go naked command that destroys all attached parts in order to escape in case of emergency. Therefore, converting it to POLYBOT-7 will lead to a much better gameplay. Instead of destroying all the parts, he can destroy their random half and throw away the other half, leaving the probability of preserving potentially useful parts and not creating a huge number of parts around, re-clogging all the slots. This mechanics will allow players to “shuffle” their configuration when 1) it becomes completely unbalanced and useless, or when 2) they find some good objects that they want to use.

From conversations with the players at Cogmind (the week before I showed them the general plan), it became obvious that having an unlimited "Cleanup" would not work and it would be easy to get around, so before each use I added a "recharge" performed by the energy pulled from the player. This can be interesting because it will be much faster if there is a lot of energy. In addition, after the "Cleaning" the player becomes weaker, which forces him to seriously assess the situation before performing this action. I will talk about this a bit later, because there were problems with such a system and now it works differently.

Also in the next section I will talk about other unique mechanics.

UI start

The first step in the 7DRL week was to truncate and reconstruct the existing UI in the most efficient way.



The best approach would be “primarily the UI,” because it will allow me to work on displaying the content of the game (originally similar to Cogmind Beta 5) and remain a known variable, speeding up the development process.

Now, many windows from the source material were no longer required, but, as one might expect, the code base is full of all kinds of links to them and other content, so it is impossible to completely remove them and hope for a stable game. What have I done? Just moved them :)


The default Cogmind UI scheme. The arrows show how in the POLYBOT-7 the consoles moved out of scope or narrowed.

Hacks again? Oh sure. Easier than alternatives? Of course. I also blocked commands that interacted with the contents of these windows.

Therefore, from a technical point of view, when playing in POYLBOT-7 there are quite a few consoles that actually exist and are updated, but they are not rendered in the visible area, because they are rendered out of the screen.

One of the most interesting hacks is the message log. POYLBOT-7 needs its own message log, but the game does not have enough space to display it constantly, as in Cogmind, so I used a tandem of two solutions ...

Cogmind already had a system for outputting directly to the battle log card (separate from the message log), so I connected this system to the message log itself - bam, messages are now temporarily displayed on the map. However, I had to change its behavior so that it always scrolls down and pushes old messages up, rather than using the cyclic approach from Cogmind (which I can probably come back to and replace with this new system).


An example of messages scrolling up the map.

But we can’t leave messages there forever, closing part of the map, plus we need a way to display old messages, so anyway we need an interface to implement this functionality.

So I came up with the idea of ​​simply using Cogmind's “complete message log”. In the original game, when you press F4, the message log expands to the very bottom of the screen and displays much more messages.

In POLYBOT-7, pressing “m” moves the message log so that the upper left corner has coordinates (-1, -1) relative to the screen (to hide its title / border) and expands its height so that the inside closes the map. When you close the log with the "m" key, Escape, or with a mouse click, it is compressed again and moved out of scope.

Conveniently enough, we allowed this separate message log window to continue to exist off-screen, right?

This is how the process looked when I configured only some of the windows; notice how the expanded log opens a little off the screen (I later turned off the built-in move numbers because they took up valuable space in the P7 log):


Initially, the message log expanded only half the width of the map, as in Cogmind, but later I enlarged it to the width of the map and completely closed it - so it gets more space, and messages are easier to read because they take up less lines!


Opening a detailed message log on top of a map. It is worth noting that later I decided to leave its borders visible, because taking into account the way the fonts worked, it looked better (otherwise the letters would be displayed right next to the edge of the screen).

The last thing I did before resizing the main terminal was reorganizing the contents of the help screen so that it roughly corresponded to the size of the desired area. Here is a screenshot where everything is not ready yet, but most of the content has already been removed:


I did not have enough time to make a convenient menu of options, but roguelike needs a help screen (besides, it is not so difficult to do), plus it duplicates the game menu with buttons. The final version after switching to a new font and terminal sizes:


As you can see from the previous layout, the “Scan” and “Volley” windows (respectively used to get brief information about the object under the cursor and attack details) are removed from the scope, but the information contained in them is too valuable, so you need to display it somewhere .

The console windows themselves are located at the top of the screen and their rendering logic works fine. I also added a one-line bar with a list of parts at the bottom of the screen, which literally reads the display output from these consoles and copies them down.


“Information bar” under the list of parts, which displays brief information about different objects / states.

I did not immediately add this interface function (note that it was not on the original layouts), but later, after a little testing, I realized that by sacrificing a potential slot for an item, I would get much more!


The full code of the information strip is shown here. It's pretty confusing, it's a quick hack, like almost everything I did during the week. It copies text from other consoles and reformatts it as necessary to display in a new area.

Mechanics

After spending the first couple of days on the implementation of the UI plan, I moved on to the next stage - implementing all the new mechanics ...

First, I set about one of the main new functions: attracting parts. It wasn’t so difficult to make it work, because Cogmind had a special function with a similar effect for a long time, so I could just adapt this code. From the player’s position, Dijkstra searches for all the details within the radius (4), and each of them uses the path search code, trying to get closer to the player one step per turn.

In Cogmind, tactical positioning has always been important, but because of this function, it has become even more necessary, because for an optimal game, you also had to take into account the location of objects, including possible loot falling out of enemies. If it is too close, it will fill the empty slots with weak details!

The attached part is randomly selected among those closest to the player, which makes creating a specific configuration even more difficult. In addition, the details cannot be removed separately, otherwise the game would turn into a tedious routine.


Attraction of the nearest details and their fastening.

(Note: this week I only worked with ASCII, but now I demonstrate most of these functions with the help of tiles that were created later.)

When all these objects are lying around (especially in the form of trophies left over from the battle), and most of they remain unused, you need some way to get rid of all this chaos:

1. when a card is cluttered, it becomes difficult to find a suitable part
2. because of the mechanics of attraction, excess garbage makes the task of attracting the necessary objects even more difficult
3. almost always there will be a set of various parts nearby, which easily avoids the presence of empty slots (i.e. it is easier to survive in general)

Cogmind uses processors for this purpose, collecting trophies in recycling plants, but in POLYBOT-7 I firmly decided to use only combat bots. Therefore, I reworked the existing Cogmind system, and implemented self-destruction of objects. In Cogmind, this mechanic is used only in special cases, but here I wanted it to be universal.

All items that fall out of the robot like trophies start their counter of moves, and when the timer expires, the item destroys itself. After each of them leaves a little matter, which is both useful (as ammunition) and looks interesting (you can see the remains after the battle or a group of parts).


We skip moves to demonstrate the self-destruction of parts, because the player’s slots are full.

Obviously, there should still be good details nearby that the player could find, so they don’t have a timer until the player starts pulling them . And in order to prevent the player from “dragging the details” on the map for too long as spare, for all actively attracted parts, the timers decrease twice as fast.

Items glow a bit when their timer is active, and begin to glow more strongly when their timer approaches zero. You can make improvements to this system, but I did not have enough time, and it was not particularly important.

Another major strategic change in gameplay was the removal of slot types. Thanks to this, the design moved along the unexplored alternative path, which I considered in 2012. In my opinion, it turned out to be quite suitable taking into account other new POLYBOT-7 mechanics, in particular, the attraction of parts. The resulting very flexible configurations of the P7 made the passage more chaotic and interesting.


Although there are no more type headers in the game, details are automatically sorted, and their ASCII / tile is displayed on the left, so you can quickly determine how many details of each type are currently available.

The implementation of this turned out to be much less painful than I imagined, given that in Cogmind there is a fundamental assumption that the slots belong to different types! Inside the code, the slots still have to be of type, you only need to remove or change the input and output restrictions in order to ignore it. From a technical point of view, every time a player receives a new slot, he is of the “weapon” type, despite the fact that this is not obvious to the player, because anything can be placed in the weapon slot.

Another important principle of simplifying interaction with objects and controlling the player’s configuration was the permission to mix different types of propulsion systems (unlike Cogmind, where only one type of propulsion system could be active at a time). The mixture was quite simple to implement, but in general, the system of propulsion systems while maintaining the old mechanics with the simultaneous use of several types of installations has become very clumsy. There was no way around this problem, so I had to redo the mechanics of movement from scratch!

Initially, in the design document, this change was on the list “it would be great, but I won’t have time for it,” so I got worried when I found out in the middle of the road that I would have to create a new propulsion system! To become high-quality, the system should preferably undergo testing and multiple iterations, so it is obvious that this was not suitable for 7DRL.

Well, what to be, that cannot be avoided, so one morning I just rolled up my sleeves and did it all over again. I won’t go into details here, I’ll just say that reducing the number of options to three types of movers helped a lot. (I still intended to remove the flight, because he no longer approached the game with emphasis on fights, and the wheels, because they seemed foreign and could not get into their niche.)

Therefore, the air cushion provides speed, but does not have the ability to provide greater support, the legs slow down the player a little, but provide somewhat more support, and the tracks greatly slow the player, but provide more support. Conceptually, this is more or less similar to Cogmind, despite the fact that Cogmind math does not allow mixing types, and at the same time it is more complicated because it supports other functions, for example, overload (remote in P7) and a propulsion system that increases the base speed (also non-existent in P7).


My preparation for the implementation of propulsion systems. The mechanics of POLYBOT-7 propulsors are completely based on brief mathematical calculations “on a napkin”, and not on the analysis and testing of a spreadsheet.

Fortunately, I did not have to make changes to the system at all - based on practice, it turned out to be quite balanced! I did not even need to change any of the templates for these items, of which 54 new items for propulsion systems were obtained. What a relief!

The absence of non-combat bots, in addition to the problem of cluttering up the space, led to another side effect of POLYBOT-7: there were no engineers repairing the walls in the game. Of course, this is not such a big problem as littering, but rampant destruction in a completely destructible world could have some unforeseen consequences, which I wanted to get rid of. Plus, map recovery looks great, so I implemented it.


"Gauntlet" restores its structure.

It would be great if the animations became faster - in fact this is the slowest part of the game (which, as you remember, I wanted to make fast), but I worked fast and did not want the animations to be without sound effects (taking into account that everything else was voiced ...), and the only suitable sounds had such a duration ... so I compared the duration of the animations with them. At least, this only happens when, after the previous cycle, some part of the relief was destroyed.

Some actions have warning sounds so that players can respond to level recovery, for example, by moving to the other side of the wall to block pursuers / attackers. Looking back, I see that the whole system needs a long time to work.

Aesthetics

I mentioned the importance of finding ways to create the unique look of POLYBOT-7 in order to separate it from Cogmind. The style of his gameplay is very different, so ideally, the appearance should differ as much as possible. We already have new UI sizes, larger pixel fonts and color changes, but there are other ways to accomplish our task.

The simplest and most obvious is the use of oriented walls based on lines. Fortunately, Cogmind still has code that implements this style (originally left over from the source code of X @ COM). Although this “switch” was easy to switch, it has not been switched for many years, so, of course, it was not fully functional ... After fixing all the bugs, I also took into account the oriented doors - a new feature, for the quick implementation of which hacks were required, and despite this, I was not able to completely improve it (the card recovery system does not always correctly recreate doors).


Oh, when I finally fixed all the problems with the doors, faulty tiles appeared outside the scope! A typical game dev ... A few additional difficulties arose because I needed the card's memory system to correctly handle orientations. (About tiles: although I usually work in ASCII, I had to check if the orientation for tile mode worked, so at this point I still had old Cogmind tiles.)

As a side effect of the simple implementation of oriented walls, the player can get more information about what is happening behind the wall, although in the world of robots this can be explained by some logic, so I left everything as it is. However, it took me some time to upgrade the system so that it ignored connections to hidden corridors / doors that would otherwise render pointlessly. By the end of 7DRL, at least one anomaly remained, which would have taken much more time, so I did nothing with it: the hidden corridors connecting in the corner of the room reveal their location. The orientation system has already become quite complicated, and taking into account special cases would require much more work than the simple rules that I implemented.


Oriented Wall Behavior

As seen from the screenshot above, the floors have also changed - they use bold dots instead of full-sized floor tiles. This allows the foreground tiles to stand out even more and also preserves the more traditional roguelike look (in 2015, filled floor tiles appeared in Cogmind, because the game stood out from the rest; in addition, Casper wanted to experiment, but I did not mind, because in the end any approach would work).

CasperHe agreed to participate with me in 7DRL and create a tileset, so we needed a new style for him. At first, we thought to make a base size of 24x24 for it, and at the beginning of the week, Casper created several concepts based on this size that we inserted into the game to see how it would look.


The screenshot shows a mix of concepts of a new 24x24 tileset style (marked with arrows) with new text (the rest are old tiles that were not converted for testing). As you can see, there are solid sex cells here that were later disposed of.

The main problem was that I created the text by increasing the scale of the Terminus 6x12 font (for good readability at all the right sizes), so its appearance did not correspond to the finer pixel tiles, and the overall appearance looked unnatural. Therefore, we thought that it would be better to return to using 12x12 tiles and simply increase their scale so that they match the text and give the whole interface a bulky look. I proposed a view exactly from the side and as flat as possible (Casper still decided that he wants to work with fewer shades).


Basically a flat tile set POLYBOT-7, with the exception of robots that use two shades.

As you can see in the finished style shown above, as in ASCII mode, oriented doors and walls are used in the tileset, and the “ground” (the filled space between the walls) is converted into a simple square. This creates a different look from Cogmind and reduces the requirements for tiles to a minimum so that Casper can finish the job (or at least spend more time on what is really important!).


Another pretty big change was the replacement of the color scheme of objects. I quickly tested many different designs. Such a change was not necessarily required to move away from Cogmind, but was rather an experiment to simplify the UI.


Quick testing of different color schemes of objects in the sandbox (in all cases, indefinite objects are shown in white). Won number 3.


It was also important to compare how the diagrams would look in the parts list, where their tiles also appear (it was a rather poor comparison, because the content is not the same, and the distribution is poor, but we were in a hurry!)

As a result, I liked the simplicity of the purely blue shades. They are not very often used in the interface and are in good agreement with the green UI. Although it was a more or less monochrome scheme, bright shades of blue could be used to highlight valuable details so that they immediately caught my eye. And shades of blue have a good range of colors associated with them, from azure to heavenly and turquoise.

However, it is worth noting that initially the playerit was also blue, and when objects surrounded it, it could be confusing, so at the last moment I changed its color to green - this color was not used anywhere else on the map (because neutral bots from Cogmind were removed here). Then I changed the color of the upgrade modules to green, because 1) they are very important compared to everything else on the map and 2) are unique to the player’s character, so using the same color for them looks logical.

Card generation

I spent the whole day generating a card. By the end of the day, my desk looked like this:


My table after thinking about the various schemes of the POLYBOT-7 card.

All maps use my tunneling algorithm from Cogmind, although with different parameters. Slot modules (a way to get new parts slots) are actually among these parameters, existing in the form of prefabs , which are randomly located in different places relative to the inputs / outputs from the card.


An example of a 100x100 map with notes. The player enters the card from one of the red dots and must exit through the other. In this particular scheme, four distributed module slot rooms are used , not the usual three, and POLYBOT-7 has many more hidden doors and corridors than Cogmind. It also has very few large rooms.

I was especially afraid to fail this development phase, because it takes a lot of time to create a good set of cards, and there will be no more time for them to be redone. When creating the schemes, I based on what I learned from the study of Cogmind cards, as well as on plans that POLYBOT-7 content should change everything (the next stage of the process, which I will discuss below). Honestly, I didn’t have to spend so much time generating cards and everything would be fine, but I wanted more variability in order to increase replayability and maintain the complexity of the game. The size and layout of the map is crucial for balance, and I decided that I needed to increase the size of the map at each depth, that is, several different layouts were required for each floor. Therefore, it took a long time.


Testing circuit generation for an 80x80 card (second floor).


Тестирование генерации схемы для карты 100x100 (третий этаж).


Тестирование генерации для одного стиля схемы (у каждого этажа есть несколько стилей) для карты 125x125 (четвёртый этаж).

It was during the work on the generation of maps that I made a huge change in the direction of the development of the game: constant upgrades. Unlike the evolutionary system Cogmind, in which the player simply has to reach the exit in order to restore the integrity of the nucleus and obtain an increase in performance, in POLYBOT-7 he selects random upgrade modules that provide permanent advantages like damage resistance, additional capacity for energy / substance, increased accuracy or radius of visibility, etc. I really wanted to explore this mechanics of P7, but initially in the dizdok it was on the list "probably there will be no time for this." I had no idea that in the middle of the week I would have to use this idea to balance the design.

When I came to it, in the conditions of the new mechanics, it was very difficult to arrange the inputs and outputs as in Cogmind, because the P7 cards should have become smaller, but all the feature upgrades were local relative to the floor, that is, I did not have to hide the exits are far away! Players can find their way out very quickly, and this is normal, because they will want to explore the floor in search of new upgrades, while trying not to lose too much in the learning process. This is the main difficulty of the gameplay.

Более того, для получения этих апгрейдов нужно атаковать диспетчеры (Dispatchers) (основные источники врагов, разбросанных по этажу), что позволяет сосредоточиться на боевой стороне игры — или рискуй, сражаясь за апгрейды, или сразу убегай. Кроме того, сам по себе сбор постоянных апгрейдов является интересной частью игры, несмотря на то, что его почти нет в Cogmind. Поэтому было любопытно поэкспериментировать с ним в антураже, похожем на Cogmind.

В Cogmind стратегии скрытности/скорости возникают естественным образом из самой механики — игрок пытается избегать врагов (или убегать от них) в процессе поиска выходов, но здесь это невозможно, и теперь механика POLYBOT-7 делает гораздо больший упор на бои как основу процесса. К сожалению, это также означало, что придётся проделать ещё больше work on content - create all upgrades.

Content

Although I prepared a fairly good work schedule for 7DRL, fortunately , this schedule provided for a couple of extra days for “balance and interest”, because, as it turned out, I had to spend them in the middle of the week on more necessary things related to content. According to the original plan, I had to mainly focus on creating unique mechanics in POLYBOT-7keeping as many items as possible from Cogmind. But for many reasons, this turned out to be inappropriate, both thematically and from the point of view of mechanics. It would be best to add a bunch of new content ... so as a result, in the middle of the week, I was hellishly working on this unplanned part of the project. Closer to the last couple of days, she looked pale and I even thought I wouldn’t have time! In the end, I had to cut back on everything I could and work very quickly.

Regardless of the new content, everything had to be reworked for the new card size. In Cogmind, the area of ​​the current map of 50x50 size is simultaneously visible, and all its mechanics and content are developed based on such sizes. Enemies noticing the player and even shooting at him from behind the edge of the screen is a bad design that had to be avoided by all means. At the same time, it is desirable to have objects and systems that make the most of the advantages of the accessible visible area, so this area plays a crucial role in design.

To maintain as much balance as possible without unnecessary labor and testing, the easiest way to work with the available data was to take all the values ​​related to the range and reduce them by 40% to reflect the change in visibility from 50 to 30. This was the first change: I'm in literally, I simply copied the data on the range of the weapon and multiplied them all by 0.6, and then copied the results back.

But a 40% reduction gave a significant indirect effect on the firing time. Earlier, to rewrite the propulsion system, I slightly increased the speed of movement and calculated that in practice (based on the total unloading mass), players usually need from 0.75 to 2.5 moves to move one unit of space - thanks to this, players do not may move tooquickly relative to a map with decreasing dimensions. And regarding this, again, in order to maintain the balance familiar from the experience with Cogmind, the next goal will be to select such expenses for the shooting time so that the enemies have about the same amount of shooting capabilities for a fast or slow player as in Cogmind. The numbers were as follows - 3 turns per shot from one weapon, 4.5 turns per volley from two. Further testing showed that this worked well, so the setup was no longer required.


Some calculations of the speed of movement and the relative time of volleys, sketched during the process of generating maps, to make sure that the size of the maps correspond to the required speeds.

Work on objects required much more than just changing ranges:

• Все предметы двигательных установок из Cogmind (110 штук) были убраны и заменены 46 новыми (хотя некоторые названия остались прежними, характеристики изменились).
• Набор источников питания был упрощён, убраны 23 источника и добавлен новый набор из 9 источников, большинство из которых используют враги (вместо обычных источников питания).
• Было создано 14 модулей апгрейдов (по крайней мере для половины из них код поведения был взят из Cogmind, а для второй половины код добавить было довольно просто благодаря похожей модели).
• Вспомогательные предметы были переработаны — убрано большинство, имеющее чисто небоевые эффекты, у остальных упрощена схема наименований. В целом, P7 содержит на 182 меньше вспомогательных предметов, чем Cogmind.
• Названия и прогресс оружия тоже были упрощены. Кроме того, добавлено 21 новое оружие, большинство из которых должно использоваться врагами. Множество оружия из Cogmind (примерно 200) было удалено, и, как сказано выше, при этом процессе я избавлялся от большинства оружия с медленной анимацией. Единственным исключением стала микроядерный заряд, крутость которого недостаточно проявилась в Cogmind, поэтому я воспользовался POLYBOT-7, чтобы показать его во всём величии, создав для него улучшенную пусковую установку. Также значительно было преобразовано множество типов оружия из Cogmind, чтобы превратить их в улучшенные версии более раннего оружия и изменить их анимации для соответствия их новой группе.
• В целом, POLYBOT-7 содержит всего 412 предметов, в то время, как Cogmind — 900

Having finished with the objects, I had to move on to robots, the properties of which were mainly determined by their objects. All robots were created from scratch, but in most cases when developing their design I used robots from Cogmind as templates. The general idea was that enemy robots use weak details, so although a player can attach to himself and use anything, it is often better to avoid trophy details if possible (difficulties arise when there are a lot of captured parts lying around that automatically fill the slots ! This to some extent prevents the player from using the “safe” tactics of fighting in the doorways). Also in their power sources there is no capacity for storing energy, so if a player relies on other bots to get power,

In addition, I gave some robots items that they actually do not use, but which may be useful to the player. This design strategy is much more commonly used in Cogmind than in P7, but in some cases it helps. For example, Aimbot has a Structural Scanner, so that the player has frequent access to it to recognize hidden doors - do not forget, there are much more of them in POLYBOT-7! (In addition, thematically it makes sense - Aimbot, which can attack targets through walls, can have such devices).


Full details of robots!

After completing the work on robots (see? - the work is moving in a very correct order), finally, the time has come for the Dispatchers, the focal point of most of the battle, and therefore the gameplay, including the complexity! In fact, Dispatchers are Garrisons from Cogmind, but with different behavior (activating based on the proximity of the player, creating units at predetermined intervals before destruction, they leave modules after disconnection). But since they turned out to be an important part of the gameplay, as a result, it took a lot of work to balance them, especially the distance at which they should fire and the number of bots they produce. Over the past couple of days, I changed these settings several times. However, their bots are not alwaysattack the player directly! This could be very boring, so some of them stand still and protect the Dispatcher, while others are sent to the point where the player triggered the Dispatcher, but from a technical point of view, they never look for the player directly, like some squads in Cogmind.

More or less finished with the content, I switched to balancing the card as a whole. I spent a lot of time on this: constantly loading random cards, moving them away and studying the distribution of objects, patrols, guards, dispatchers, etc., and also set up a lot of numbers / coefficients for creating enemies to create something that looks like a balanced game process.


We examine the content on the map part, including the patrol routes (shown by colored lines).

POLYBOT-7 was supposed to be short enough: only five floors, but in addition to unique card schemes, I found another relatively inexpensive way to increase replay value for those who liked the game - adding the “New Game +” mode after winning. Many complexity-determining variables can simply be changed depending on the number of player wins, so why stop at simple NG +? I decided to add five consecutive New Game modes, each more complicated than the previous one. Changeable parameters:

• Number of patrols initially on the map
• Patrol Size
• The distance at which Dispatchers are triggered
• The number of robots produced in the group
• Changing weights of types of manufactured robots
• Adding the likelihood that the released robots will be supplemented by a supporting Blastbot (uses missiles) or Forcebot (protects allies with a power shield)
• The interval between the release of robots (it was implemented, but I did not see the need to change it, so it remained constant: 100 moves)
• The coefficient received from destroyed robots trophies

Other changes to NG + not related to gameplay:

• Each has a unique name: "Alpha," "Beta," and so on.
• Each has its own unique color of the walls.
• The point multiplier increases with each mode, giving a huge amount of bonus points for all actions for which points are awarded, even if the player has not won

Чтобы упростить реализацию, я сделал так, чтобы после проигрыша в любом прохождении NG+ игрок терял выигрышную серию и вынужден был начинать с начала и «обычного прохождения». По сути, это как permadeath из roguelike, но для серии побед в New Game. Это не лучшее решение, но мне приходилось торопиться! Оглядываясь назад, я думаю, что лучше бы один проигрыш возвращал игрока назад к предыдущему режиму NG+ (если он уже выиграл хотя бы больше одного последовательного прохождения), чтобы терялся не такой большой прогресс.

Примечание: один из лучших игроков в Cogmind уже выиграл в P7 самом-самом-самом последнем режиме NG+++++, добившись окончательной победы!

В последний момент

All the time planned for balancing was eaten by adding content, so almost nothing remained on the “right” balance. There was too little time to do all the necessary calculations, and although I liked writing completely new content from scratch and using formulas to balance it to the new format, it is still 7DRL - plans should be at least half realistic.

With this in mind, I was very impressed and delighted at how well everything turned out, because I only had time for the most emergency patches, and in the last hours of the deadline I made quite significant improvements. Of course, this is by no means the level of balance of Cogmind, but in a couple of quick walks I found the most serious problems that needed an urgent solution.

In addition to reducing the number of robots (at first there were too many of them!), I added a bunch of weapons to the map, essentially hacking them into the usual distribution system for objects: at least 15% of all individual objects began to be created in the form of weapons. Usually the distribution of objects doesn’t look like that, but after I ran out of weapons regularly during test runs, I used the Cogmind object distribution debugging output system to investigate the usual probability of creating a weapon and noticed that on most floors the values ​​are surprisingly small.


The final (after balancing) distribution of objects on each floor, both conventional and prototypes, by slots / types.

In addition, in the same way, I forcibly placed launchers on each floor (there are more of them on large floors), because launchers are FUN. In addition, sometimes players in POLYBOT-7 do not have free slots for collecting found / desired items (do not forget that the game does not have any equipment!), Therefore, despite the large number of interesting things lying around, not all of them are actually will be used , that is, you can safely add more of them without making the game too easy.

Also, in the form of guaranteed blanks, more weapons and other good items were added, namely, “weapon rooms” and the so-called “assembly rooms”. These are rooms in which there are blockages of details, namely only weapons (again, so that you can play with it) and only a balanced set of objects for the entire range of slots. Players who find such rooms can perform a “cleaning” by dropping all their items and getting a good new collection of items. In the "assembly rooms" are guaranteed to present a power source, propulsion system, auxiliary devices and weapons.


Special blank rooms with notes. Note that these rooms often have double doors so that they can easily be recognized from the outside.

Now I think that I went too far with weapons (now it is lying around everywhere), but more choices always have their advantages, so it’s better to bust than shortage! I did not have enough time to achieve the perfect balance. In the end, I had to do all this in the last hours.

Another one of the basic mechanics that changed at the last minute is the cleaning timer. At first, it seemed to me that strategically it would be more interesting to use a device that draws energy from a player during each move for its charge. This behavior will add the need to make a decision about the cleaning time, because this action will be followed by a decrease in energy production until it is fully charged. But I realized that in general this is not particularly desirable, because cleaning already destroys random parts and can lead players to a situation of uncertainty, so it makes no sense to kick him when he already has problems! Therefore, I replaced this mechanics with a simple 100-way timer - it is more predictable and interesting.


Cleaning timer in action. Performs a countdown and constantly attracts objects remaining nearby, only to perform cleaning again.

At the very last minute, I tested the game very quickly and found important parameters that were not in the UI: the number of parts assembled on the current floor (there are a guaranteed number of parts on the floor, so this is a vital parameter), and even the letter of the current floor! Both of these parameters are useful for assessing progress, but there was almost no space on the screen, so I slapped them next to the progress counter.


Adds to the HUD at the last moment: the number of slots collected and the floor ID! (Instead of numbers on the floors, the corresponding letters are: A / B / C / D / S)

In addition to being useful to the player, the HUD indicators make screenshots much more informative when the players share them, which avoids many simple questions and gives the discussion more context. This is one of the advantages of Cogmind's UI style: almost everything you need to know is visible on one screen. In addition, it allows you to gain speed faster after returning to incomplete passage.

the end

Although in my time zone I finished everything on time, I continued to work with Casper, and he needed the rest of his Sunday to complete the tileset, so I did not publish the game until the next morning, when I had the opportunity to wake up and pack all his tiles into the game .

And she’s finally ready!

Even though he worked on his project almost all week non-stop, it was a surprisingly invigorating week, during which I did not seem to have to rush. So much time has passed since I did something other than working on Cogmind, so I forgot the pleasure of purely developing the times of my hobby games. In a commercial product, everything should be documented, honed and assembled with carefully selected specifications, and for POLYBOT-7 I could simply surrenderwork flow . At first it was difficult to adapt to such a free approach, but it definitely seemed to me much more productive.

Shortly after the release, I was informed that the game still has a garrison hacking interface when clicking on Dispatcher. I removed the possibility of hacking in a collision, but forgot that the processing of mouse clicks is performed in another part of the code! This meant that players could hack into the Dispatcher, which created a staircase to the floor with the strange name G (the first letter of Garrison), and from a technical point of view it was a real link to the garrison map, however I deleted all the garrison data, so trying to enter simply led to game crash. I quickly added a fixed version so that people could not get into this black hole (not to mention that the design of the hacking interface for POLYBOT-7 did not change).


The hacking interface opened by the bug theoretically allowed access to the Dispatcher.

Speaking of bugs: during the development time, I found quite a lot of them in Cogmind, and even in the engine itself. Nothing serious, but it was great to get rid of them, too.

In general, I find the POLYBOT-7 concept very interesting, but 7DRL only partially revealed its potential. One of the ideas that can greatly increase the factor of interest is “kit rooms”. In essence, these are rooms that contain all the details for an excellent assembly, balanced with respect to a particular style or weapon, which will force you to immediately clean up when you find such a room in order to turn into a killing machine. In fact, the “assembly rooms” added at the last minute were a simplified implementation of the concept of kit rooms, but with completely random details. However, unlike assembly rooms, kit rooms must be hidden behind secret doors that require scanners to detect or a successful random shot. From a technical point of view, the game has only onethe kits room, which I quickly sketched on the top floor. It will be great if you can find her.

Players reaction

A large number of Cogmind players downloaded the game and they liked it. One even said that she helped him better understand Cogmind! It seems that even those who are not aware of Cogmind enjoyed it.

In the first 8 days, the game was launched 437 times (not by individual players whose number is less), but downloaded ... 882 times. Obviously, many people downloaded it to play later. (I know that some downloaded it several times because I updated the game, but not 2-3 times more per player. It would be interesting to collect statistics and leaderboards, as I did in Cogmind, but for now I have to focus on my main project!

Although POLYBOT-7 is not a demo, it is similar enough to Cogmind to serve as an advertisement for it, especially on the itch.io platform, which I have not used before. (At the same time, connecting POYLBOT-7 with Cogmind is an indirect way to find the latter on itch.io.) By its popularity, the game was in the top of the Strategy category and also won first place among most of the tags I selected, for example, “pixel art”, Step by step and ... roguelike. She was popular enough to be in the top 20 games on itch.io (which at that time had a little over 100,000 games), and the next day she was on the front page.


POLYBOT-7 as recommended on the itch.io homepage.

Of course, popularity is just the number of clicks on a page, so it helped me that I published announcements on many sites, plus the solid Nookrium letsperser, who played my other games, also showed P7 on the first day of release .

I continued to monitor Cogmind sales: there was no significant impact, but after the release on 7DRL, adding to the Steam Wishlist increased by 29.4% compared to the previous week ($ 20 is a little more expensive than free, plus the game is in early access )

Be that as it may, I will release another release with a few minor bugs fixed, and then put the game on the shelf until the next time it is possible to polish it a little more. I think after Cogmind I should take on a smaller project , and POLYBOT-7 already looks like an interesting opportunity to develop into something serious in 6 months ...