The week from March 4 to 11 was just crazy.

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 per night!), Most likely because I have become much more experienced than then, and had at his disposal a lot 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 , preparation time before 7DRL is not included here!)

The number of tasks and solutions that went through my head during this week was simply exhausting. Sometimes it is tiring, but at the same time it is amazing to find hacks that allow you to realize so many features and content in such a short period of time. Highly. Lot. Hack. Huge technical debt! In the process of writing most of the code, I felt annoyed, but I had no choice - either to choose the shortest route, or to risk completing everything with failure. The first few days, the code was a bit cleaner, but as the deadline approached, I began to do some really crazy things.
')
Sometimes this project was hard for me, because the years of “normal” work on roguelike taught me to write down everything I’m doing or planning, and also to think long and hard 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 entire process as a whole and the reflections that guided me when making decisions.

Concept - what and why?

Initially, my ambitions for the 7DRL were a little less. The goal was to create a simple demo of my game Cogmind with cutting off all the excess from it and developing a purely combat roguelike. In this case, most of the work was to transform the interface into a more compressed form with a smaller amount of information, but twice as large fonts and tiles. This could be a model that I could show to people interested in a common theme or Cogmind style, 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 devoted to experiments and interesting new roguelike!

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

Suddenly, it seemed to me an excellent basic mechanics, which can be used in the 7DRL, not to mention that the perfect design would require a heap of other changes, in fact, creating a significantly different game within the same world. 7DRL would appreciate this idea much more than the simple Challenge Mode in competition mode, so it became a new direction of development.

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

There were, of course, 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 focus only on the development of gameplay or content, not the basics. Without a doubt, POLYBOT-7 was the best for this.

One of the best ways to work for 7DRL is to limit the scope of the project, but another one 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 sources 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 at the technical part - in fact, I work quite slowly, which is bad when working in close time frame.


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

(However, remember that you can use 7DRL the way you want, so perhaps your goal would not be to complete the awesome game, but simply to build the engine or create a new framework you have always dreamed of.)

However, not everything was so rosy! Part of the reason for my not so good result was the fact that at the beginning of the week I did not have a finished design. In 2012, before the start of my first 7DRL, I had already prepared everything - I checked all the math, formulas and data intervals, I could only transfer all this to code and ASCII. For POLYBOT-7, I only had sketches of plans that lacked details, and this became a problem, because the emerging new details can quite simply create a domino effect. This is what happened. As a result, I had to make serious changes and additions in order to adjust the systems that I had not thought out well enough in advance.

However, the most serious drawback was that I spent most of the week thinking and not realizing. For maximum efficiency, a 7DRL week should be devoted to creating rather than thinking (creating a good design can take more than a week, mainly because ideas usually need an incubation period to check whether they pass the test of time or there is a better solution). Anyway, I barely managed, mainly due to the adrenaline-filled hacks in the code.

Stage before 7DRL

Preparing for the 7DRL starts a little earlier than the week itself. In January, I walked through several design documents, opening the latter from time to time to make changes, when it became chaotic, or I wanted to make a significant change to reorganize everything in a fresh document in order to get a good idea of ​​the current design status. In 2012, I had a lot of free time for a similar job, but this year I was quite busy with developing Cogmind and other things, so I could not 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 on itch.io. In fact, I am writing rather slowly, besides, I knew that I would not have time for good announcements of releases during this week. As a result, I later made small changes in accordance with the changed design, but mostly the announcements remained the same, later I just added some screenshots. In addition, it was a good opportunity to get to know itch.io, which I had not dealt with before. It would be fun to spoil everything somehow after the completion of the 7DRL!

Before the beginning of the week, I even zadizinil version of the cover with the help of unused tileset for Cogmind:


Dorelezny draft box design.

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


The final box design!

Ui

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

I threw out this first layout pretty quickly:


Layout UI # 1 (HUD only)

Vertical stripes are too incomprehensible and difficult to read, besides they do not leave room for additional numbers. Then I realized that I could leave room for myself above the parts list, deleting the four headers / lines used only to separate the types. 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 can be seen below, it was a very bad idea to create an ASCII item that covers the left UI divider! (I tried it as an experiment to save as much horizontal UI space as possible)


UI layout number 2

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


Sample DynaHack screenshot with a modified color scheme.

I studied this idea in REXPaint, but, unfortunately, from the point of view of UX as a whole, orange turned out to be not quite suitable for the POLYBOT-7 mechanics. In Cogmind, the main feature is the destruction of objects, and the whole color scheme is considered to be “good”, while other effects and states use their own logical colors. For the most part, everything that is not green usually requires more careful attention. It also maintains the transition standard “green -> yellow -> orange -> red” for indicators of damage and marks, and this topic is constantly applied in various parts of the interface. When the base color changes, such an intuitive understanding will be disturbed, which will lead to a less clear UI.

A decent final HUD layout was born with four extra lines on top:


UI Layout 3 (HUD only, final version)

Later, I made other changes, but in general, everything remained so. However, since the layout of REXPaint clearly states everything, the implementation has become quite simple and this preliminary work has been very useful.

Instead of re-using the high contrast style with a black background, I switched to a low contrast theme, in which a slightly darker text sits on top of a slightly brighter background. At the end of last year, I added “rendering filters” to my engine (they are described in my blog), which allowed switching 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 should have just allowed the players in Cogmind to customize the interface, but still it was useful in jam!


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 fairly large hack. Cogmind has been developed over the years with the assumption that the background will be black, so in this animation mode it does not always look perfect. Although I definitely will not have time to update the huge number of particles used by weapons, I can at least improve the appearance of the UI. All these changes were made to Cogmind (which largely benefited 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 to force the background to black even in low contrast mode, or to change the animations so that their color interpolates linearly from the given to the desired background color.


An example of the second solution. Note that prior to correction, the animation performs linear interpolation to black, and not to the desired one (that is, it first becomes 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 the text and the map I chose Terminus, because it is a beautiful and pixel-perfect fixed-width font, available in almost any size. But since I didn’t want to create a huge range of sizes, as Cogmind did (working on this takes a lot of time), I forbade the map (and HUD) mode to expand vertically and fixed them at 30 lines. However, the width can be changed, which leads to narrowing of the text on some screens. However, this is a much more pleasant option than scaling, allowing text and tiles to maintain their pixel-perfect appearance right from a bitmap.

In addition, it meant that, thanks to only four different sizes, it is possible to provide support for the entire range of resolutions. At the basic square tile of the 12x12 size map in 768p resolution, the 24x24 font is used (just created using 12 * 2), in the most popular resolution today 1080p the 36x36 (12 * 3) font is used, and the size 48 is higher (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 at them. My son decided to borrow this sheet and drew something on the back.

Gameplay design

The main purpose of the design was to create a fast gameplay in the style of Cogmind, which could be evaluated as a “coffee break”, so everything revolved around this idea. In the game process, fewer decisions should be made, so many systems of interactions needed to be removed. And not only the systems, but even the visual effects of the weapons, which distracted and therefore could slow down the player. With this in mind, in a week I wanted to correct all the slow animations or to exclude most of the types of weapons in which they were used.


Comparison of Cogmind electromagnetic pulse animation with faster animation from POLYBOT-7. (For mechanic reasons, 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 come to that decision immediately. Notice that in layout No. 2 above there is an inventory, which I initially imagined as a modal window, allowing you to assemble the parts and then attach them at your own discretion. So 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, I thought further about an orderly “queue” of parts that are attached after the loss of the previous ones, but this seemed too complicated for what was intended as a simple and concise game.

Then it dawned on me that there was no need for inventory at all - in essence, the player’s “inventory” would be peace , which was simplified thanks to the existing opportunity to attract the parts lying around. This 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 meaningless, because then players will simply disconnect unnecessary ones, since the rest lie nearby (more burdensome!). Therefore, besides the loss due to destruction (slowly and unreliably), we need another way. And then there is another important part of the plan: the mechanics of "Cleaning".

Cogmind already has a go naked command that destroys all attached parts in order to have time 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 an accidental half of them and throw out the other half, leaving the probability of saving potentially useful parts and not creating a huge amount of parts around, re-clogging all the slots. This mechanic will allow players to “shuffle” their configuration when 1) it becomes completely unbalanced and useless, or when 2) they find some good items they want to use.

From conversations with players in Cogmind (the week before I showed them the general plan) it became obvious that the presence of an unlimited “Cleaning” would not work and it would be easy to get around it, so before each use I added “charging” performed by the energy being pulled out of the player. This can be interesting, because it will be much faster with a lot of energy. In addition, after “Cleaning” the player becomes weaker, forcing him to seriously assess the situation before performing this action. I will talk about this a bit later, because there are problems with such a system and now it works differently.

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

Start UI

The first stage of the week 7DRL was an exercise to truncate and reconstruct the existing UI in the most efficient way.



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

Now the set of windows from the source material was no longer required, but, as could be expected, the codebase is full of all sorts of links to them and other content, so it’s impossible to completely remove them and hope for a stable game. What did I do? Just moved them :)


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

Hacks again? Yes of course. 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 POYLBOT-7, there are quite a few consoles, which actually exist and are updated, but are not drawn in the visible area, because they are rendered for the screen.

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

In Cogmind, there was already a system for outputting the battle log directly to the map (separate from the message log), so I connected this system with the message log itself - bam, messages are now temporarily displayed on the map. However, I had to change his behavior so that he always scrolled down and shifted the old messages up, and did not use the cyclical approach from Cogmind (to which I may return and replace with this new system).


An example of messages scrolling up the map.

But we cannot leave messages there forever, closing part of the map, plus we need a way to display old messages, so an interface is still needed to implement this functionality.

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

POLYBOT-7 «m» , (-1,-1) ( /) , . «m», Escape .

, , ?

, , ; , ( , P7):


, Cogmind, — , , !


. , , ( ).

, , — , . , , :


, , roguelike ( , ), . :


, «Scan» «Volley» ( ) , , - .

. , .


« » , /.

(, ), , , , , !


. , , , . , .

UI, — …

: . , Cogmind , . , (4), , .

Cogmind , - , , . , !

, . , , .


.

(: ASCII, , .)

( ), , - :

1. ,
2. -
3. , (.. )

Cogmind , , POLYBOT-7 . Cogmind, . Cogmind , , .

, , , , . , ( ) ( ).


, , .

, , , , . « » , .

, , , . , , .

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


, , ASCII/, , .

, , , Cogmind ! - , , . , , , «», , , .

( Cogmind, ). , . , !

- « , », , , ! , , , 7DRL .

, , , . , , . ( , , , .)

, , , , , . - Cogmind, , Cogmind , , , , ( P7) , ( P7).


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

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

, , POLYBOT-7: , . , , , , . , , .


"Gauntlet" .

, — (, , ), , ( , ...), … . , , - .

, , , , /. , .

Aesthetics

POLYBOT-7, Cogmind. , . UI, , .

— . , Cogmind , ( X@COM). «» , , , , … — , , , ( ).


, , ! … - , , . ( : ASCII, , , Cogmind.)

, , - , . - , /, . 7DRL , , : , , . , , .




, — . , roguelike ( 2015 Cogmind , ; , , , ).

7DRL , . 24x24, , , , .


The screenshot shows a mix of new 24x24 tileset style concepts (marked with arrows) with new text (the rest is old tiles that have not been converted for testing). As you can see, there are solid cells of the floor, which 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 with all the necessary sizes), so its appearance did not match the smaller pixel tiles, and the overall appearance looked unnatural. Therefore, we thought it would be better to go back to using 12x12 tiles and simply scale them up to fit the text and give the entire interface a cumbersome look. I suggested a side view and as flat as possible (Casper decided that he wanted to work with fewer shades anyway).


Mostly flat POLYBOT-7 tileset, with the exception of robots that use two shades.

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


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


Fast testing of different color schemes of objects in the sandbox (in all cases white objects are shown as undefined). Won number 3.


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

As a result, I liked the simplicity of pure blue shades. They are not very often used in the interface and correspond well to 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 the eye. And shades of blue have a nice range of colors associated with them, from azure to heavenly and turquoise.

It is worth noting, however, that initially the player was also blue, and when objects surrounded him, this could be confusing, so at the last moment I replaced his color with green — this color was not used anywhere else on the map (because neutral bots from Cogmind here removed). Then I replaced the color of the upgrade modules with green, because they are 1) 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.

Map generation

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


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

All maps use my tunneling algorithm from Cogmind, albeit with different parameters. Slot modules (a way to get new slot details) 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.


Sample map 100x100 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 rooms of slot modules are used, not the usual three, and in POLYBOT-7 there are much more hidden doors and corridors than in Cogmind. Also there are very few large rooms.

I was especially afraid of failing this phase of development, because it takes a lot of time to create a good set of maps, and there will be no more time for rework. When creating the schemes, I was based on what I learned from the Cogmind map study, and also on the plans that the 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 maps and everything would be fine, but I wanted more variability to increase replayability and preserve the complexity of the game. The size and layout of the map is crucial for the balance, and I decided that it was necessary 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 the generation of the scheme for the 80x80 card (second floor).


Testing the generation of the scheme for the card 100x100 (third floor).


Testing generation for one style of the scheme (each floor has several styles) for a 125x125 map (fourth floor).

It was during the work on the card generation that I made a huge change in the direction of the game: constant upgrades. Unlike the Cogmind evolutionary system, in which the player simply has to reach the exit in order to restore the integrity of the core and get an increase in performance, in POLYBOT-7 he selects random upgrade modules that provide permanent advantages like resistance to damage, additional capacity for energy / matter, increased accuracy or radius of sight, etc. I really wanted to explore this P7 mechanic, but initially it was on the list in the dizdoc, "probably there won't be time for that." 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, the inputs and outputs were very difficult to locate in the same way as in Cogmind, because the P7 cards had to be smaller, but all the feature upgrades were local relative to the floor, that is, I didn’t have to hide exits far away! Players can quickly find exits, 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 process of learning. This is the main difficulty of the gameplay.

Moreover, to get these upgrades, you need to attack Dispatchers (the main sources of enemies scattered across the floor), which allows you to focus on the combat side of the game - either take a chance, fight for upgrades, or run away immediately. In addition, the collection of permanent upgrades in itself is an interesting part of the game, despite the fact that it is almost absent in Cogmind. Therefore, it was curious to experiment with it in an entourage similar to Cogmind.

In Cogmind, stealth / speed strategies arise naturally from the mechanics themselves - the player tries to avoid enemies (or run away from them) while searching for exits, but here it is impossible, and now the POLYBOT-7 mechanics place much more emphasis on battles as the basis of the process. Unfortunately, it also meant that we had to do more work on the content — create all the upgrades.

Content

Although I prepared a fairly good work schedule for 7DRL, fortunately , this schedule provided a couple extra days for “balance and interestingness”, because, as it turned out, I had to spend them in the middle of a week on more necessary things related to content. According to the original plan, I had to mainly concentrate on creating a unique mechanic in POLYBOT-7, saving as many items from Cogmind as possible. But for a variety of reasons, this turned out to be inappropriate, both thematically and mechanically. It would be best to add a bunch of new content ... so as a result, in the middle of the week, I worked like hell on this unplanned part of the project. Closer to the last couple of days she looked pale and I even thought I would not have time! In the end, I had to cut everything I could and work very quickly.

Regardless of the new content, everything had to be reworked to fit the new card size. In Cogmind, you can see the current 50x50 map area at the same time, and all of its mechanics and content are designed based on that size. Noticing the player and even shooting at him from the edge of the screen enemies - this is a bad design, which had to be avoided by all means. At the same time, it is desirable to have objects and systems that maximize the benefits of the available visible area, so this area plays a crucial role in the design.

To keep 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 ​​associated with the range and reduce them by 40% to reflect the change in the field of view from 50 to 30. This was the first change: literally, I simply copied the weapon’s range data and multiplied them by 0.6, and then copied the results back.

But a reduction of 40% gave a significant indirect effect on the shooting time. A little earlier, in order to rewrite the propulsion system, I slightly increased the speed of movement and calculated that in practice (based on the total unloading weight), players will usually need from 0.75 to 2.5 moves to move one unit of space - thanks to this, players do not may move too fast relative to a reduced size map. And with regard to this, again in order to keep the balance familiar from Cogmind’s experience, the next goal will be to select such costs for firing time so that the enemies have about the same number of opportunities for shooting fast or slow players as in Cogmind. The figures were the following - 3 moves for a shot from one weapon, 4.5 moves for a salvo of two. Further testing showed that it worked well, so the configuration was no longer required.


Some calculations of the speed of movement and the relative time of volleys, thrown out during the process of generating maps, to make sure that the sizes of the cards correspond to the required speeds of movement.

Work on objects required much more than just a range change:

• All items of propulsion systems from Cogmind (110 pieces) were removed and replaced with 46 new ones (although some of the names remained the same, the characteristics changed).
• The set of power sources was simplified, 23 sources were removed and a new set of 9 sources was added, most of which are used by enemies (instead of the usual power sources).
• Fourteen modules of upgrades were created (at least for half of them the code of behavior was taken from Cogmind, and for the second half it was quite easy to add the code due to a similar model).
• Auxiliary items were reworked - the majority was removed, which has purely non-combat effects, the rest simplified the naming scheme. In general, the P7 contains 182 fewer auxiliary items than the Cogmind.
• The names and progress of the weapon were also simplified. In addition, 21 new weapons have been added, most of which must be used by enemies. Many of the weapons from Cogmind (approximately 200) were removed, and, as mentioned above, during this process I was getting rid of most of the weapons with slow animation. The only exception was the micronucleus charge, whose coolness was not sufficiently manifested in Cogmind, so I used POLYBOT-7 to show it in all its glory, creating an improved launcher for it. Also, many types of weapons from Cogmind have been significantly transformed to turn them into improved versions of earlier weapons and change their animations to fit their new group.
• In general, POLYBOT-7 contains only 412 items, while Cogmind - 900

Having finished with the objects, I had to go to the robots, whose properties were mainly determined by their objects. All robots were created from scratch, but in most cases I used Cogmind robots as templates when designing their designs. The general idea was that enemy robots use weak parts, so although a player can attach to himself and use whatever he wants, it is often better to avoid trophy parts (difficulties arise when there are a lot of trophy parts lying around that automatically fill in slots This to some extent prevents the player from using the “safe” tactics of battles in doorways). Also in their power sources there is no capacity for energy storage, so if a player relies only on other bots for power, he will have less reserves to support the universal designs of his robot.

In addition, I gave some robots items that they actually do not use, but which can be useful to the player. This design strategy is much more often 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 data robots!

After completing the robots (see? - the work moves in a very proper order), finally, it is time for Dispatchers, the focal point of much of the battle, and therefore the gameplay, including complexity! In essence, Dispatchers are garrisons (Garrisons) from Cogmind, but with a different behavior (activating on the basis of the player’s proximity, creating squads at predetermined time intervals before destruction, after switching off the modules are left behind). But since they turned out to be an important part of the gameplay, as a result, it took a lot of work on balancing them, especially the distance at which they should trigger and the number of bots they produced. Over the last couple of days I have changed these parameters several times. However, their bots do not always attack 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 units in Cogmind.

More or less completed with content, I turned to balancing the card as a whole. I spent a lot of time on this: I constantly loaded random maps, removed them and studied the distribution of objects, patrols, guards, dispatchers, etc., and also set up a set of numbers / coefficients for creating enemies to create something like a balanced game. process.


We explore the content on parts of the map, including the patrol routes (shown by colored lines).

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

• Number of patrols originally on the map
• Patrol size
• Dispatchers distance
• The number of robots produced in the group
• Changing the weights of types of produced robots
• Adding the likelihood that the released robots will be complemented by a supporting Blastbot (uses rockets) or Forcebot (protects allies with a power shield)
• The gap between the release of robots (it was implemented, but I did not see the need to change it, so it remained constant: 100 moves)
• Coefficient of trophies received from destroyed robots

Other changes with NG + not related to gameplay:

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

To simplify the implementation, I made sure that after losing any NG + pass, the player would lose the winning streak and had to start from the beginning and “normal pass”. In fact, it’s like the permadeath of roguelike, but for the New Game series of victories. This is not the best solution, but I had to hurry! Looking back, I think it would be better if one loss would return the player back to the previous NG + mode (if he had already won at least more than one consecutive pass) so that not so much progress would be lost.

Note: one of the best players in Cogmind has already won the very latest NG +++++ mode in P7 , having achieved the final victory!

At the last moment

All the time planned for balancing was eaten by adding content, so almost nothing was left for the “right” balance. There was too little time to perform all the necessary calculations, and although I liked to write completely new content from scratch and use formulas to balance it for the new format, it’s still 7DRL - the 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 enough time for the most urgent patches, and in the last hours of the deadline I made quite strong improvements. Of course, this is by no means the level of Cogmind's balance, but in a couple of quick passes I found the most serious problems that needed an urgent solution.

( !), , : 15% . , , , Cogmind, , .


( ) , , , /.

, ( ), — . , POLYBOT-7 / ( , !), , , , .

, , « » « ». , , (-, ) . «», . « » , , .


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

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

, — . , , . , . , , , , ! 100- — .


. , .

, UI: ( , ), ! , , .


HUD : ! ( : A/B/C/D/S)

, HUD , , . UI Cogmind: , , . , .

the end

, , , , , .

!

, -, , , . , -, Cogmind, -. , , POLYBOT-7 work flow . At first, it was difficult to adapt to such a free approach, but it definitely seemed to me much more productive.

, - Dispatcher. , , ! , Dispatcher, G ( Garrison), , , . , ( , POLYBOT-7 ).


The hacking interface opened theoretically allowed to enter 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.

POLYBOT-7 , 7DRL . , — « ». , , , , , . , « » , . , . , . , .

Cogmind . , Cogmind! , Cogmind .

8 437 ( , ), … 882 . , , . ( , , , 2-3 . , Cogmind, !

POLYBOT-7 , Cogmind, , itch.io, . ( POYLBOT-7 Cogmind — itch.io.) Strategy, , «-», «» … «roguelike». , 20 itch.io ( 100 000 ), .


POLYBOT-7 itch.io.

, — , , , Nookrium, , P7 .

Cogmind: , 7DRL Steam 29,4% (20 — , , ).

, , , , , . , Cogmind , POLYBOT-7 - 6 …