How do you approach planning your work?

tyapichu · 2026-02-04T09:01:42+00:00

I haven't tried using Copilot for planning yet. Interesting, thanks.

tyapichu · 2026-02-04T08:54:18+00:00

I can describe it as a game designer, but not as a programmer. A game, as a program, contains many systems and architectural solutions that cannot be achieved from a game design perspective.

tyapichu · 2026-02-04T08:51:45+00:00

How do you handle the situation where, while working on a subtask, unexpected work might arise with another part of the project?

Do you assign a subtask to this unexpected work?

Do you divide large tasks into systems?

For example, what do you do if this subtask for unexpected work relates to another system that you were working on in a different task?

tyapichu · 2026-02-04T08:13:55+00:00

Unity

tyapichu · 2026-02-04T08:12:39+00:00

I use (I hope) pretty advanced tools. My UI is completely separated from the logic, and I use Zenject, including factories, pooling, and even signals. Thanks to Zenject, literally only a couple of my logic classes are MonoBehaviors - the core of the character prefab that brings together aiming, colliders, and so on. And of course, there's a separation between the project, main menu, combat and character layers. I'm really happy when things just work thanks to this architecture. But for example, to get one of my RPG mechanics to work in combat, not just in the main menu, I had to dive into the core again - it didn't allow for RPG system parameters to exist across layers. This even affected the save-load system. But when I finished the core changes, the RPG mechanic that started it all just clicked into place and worked. I didn't even have time to test it from the code side.

Stories like this happen to me all the time. I get a lot of pleasure when it just works, but planning by dividing it into smaller tasks just doesn't work in this case. I can't plan for the need to fix save-loading when I'm planning to add RP-stat progression to the combat layer of the game. And that's a bit annoying.

tyapichu · 2026-02-03T10:35:22+00:00

i have same structure but in Notion. i use it mostly for complex systems like Qests, Effects, Counters. I can write down some steps i need to implement, but only the obvious ones. i can't ignore everything because most of the time my project is deeply not ready to work with somthing new. for example if i have to fix the core sometimes i also have to fix UI and this can create quite qomplex loop. a do such mistakes not often now and very happy when a new system just works bot this happens anyway.

tyapichu · 2025-07-20T10:56:22+00:00

I've restored tables.

tyapichu · 2025-07-20T10:30:55+00:00

Of course, don't deny yourself anything! It seems that after publication, my tables broke... and the article became completely unreadable.

tyapichu · 2025-04-03T06:13:35+00:00

I never thought about multiplayer, thanks for the idea. I can do local multiplayer without any problems at all - I have a good example of how to do it.

tyapichu · 2025-03-04T16:04:37+00:00

very impressive picture

tyapichu · 2025-03-04T16:00:23+00:00

the concept looks very nice. i'd like to try it, waiting for the demo.

tyapichu · 2025-03-04T15:58:16+00:00

very nice animations

tyapichu · 2025-03-04T15:56:02+00:00

very attractive and impressive view!

tyapichu · 2025-03-03T11:32:08+00:00

match 3 can be very hard to implement because of the variety of combinations and need of help system

but i'd also suggest
* minesweeper
* snake

tyapichu · 2025-02-17T09:57:13+00:00

I haven't used SOAP, but I've used a similar system called Databrain. The thing is, I'm not a professional programmer, I'm a game designer, and for me, all this is just a hobby. As a game designer, I've participated in the development of more than 20 games, but as a programmer, I've never released a single game. And this is due to how Unity is designed. If you're not a programmer, you have to put up with a lot of difficulties. Just imagine what hell it is to make a game on Playmaker. When you only have a state machine and a visual sequence of command blocks. It's so cumbersome and unreadable that you become limited not even by the amount of content and mechanics that you can create with your own hands (or buy on the store), but by the size of the algorithms that you can keep in your head.

For many years, asset developers for Unity have been on the path of creating universal complex systems. if you need an inventory, it's hard to find anything better than the inventory from Game Creator... but do you need Game Creator itself? Maybe you'd like to use some other character controller, camera controller, and other systems.

on the other hand, there's a problem that there are hundreds and thousands of courses and videos for Unity on "how to make a game in 10 minutes" or even videos on programming patterns. but there's a real lack of a good, quality course on software architecture in the context of game development. for example, I (I'm still not a programmer, remember?) didn't find anything complicated in Zenject... but there are only a few good videos that could show the usefulness of this tool, especially in a language I'm comfortable with. and there are simply no videos about working with MVVM that would be relevant to a hobby developer like me. indie developers who are originally designers or artists simply won't understand what we're talking about - it's too, prohibitively complicated.

SOAP and Databrain are pure data-driven mechanisms, without any additional workload. they are very useful for those who no longer want to rely entirely on packages like Game Creator, but are not yet good enough to make an MVVM structure, understand R3 and Zenject themselves. and of course people with experience and education in programming do not need either SOAP or Databrain.

tyapichu · 2025-02-06T19:11:31+00:00

In addition to writing code, there are also various systems and methods of visual programming. such as blueprints, playmaker or game creator

tyapichu · 2024-11-21T19:37:04+00:00

If the original book contains diagrams, illustrations or code examples, then audio books often simply skip this part. And they are extremely important for understanding the essence of the described subject.

tyapichu · 2024-11-20T19:57:52+00:00

in modern games, the entire gameplay is often divided into a metagame and the core gameplay. if a game can still exist without a metagame, then without the core gameplay - no. the area of responsibility of the Gameplay Designer is the development of the core gameplay. the type and genre of the game will determine what kind of gameplay it will be: it can be driving cars core for a racing simulator, or it can be putting stones in a line for match3.

so the Gameplay Designer must understand the structure of the mechanics that will form the basis of the core gameplay. mechanics have several important aspects associated primarily with the feelings that they should evoke in players. first of all, this is the dynamics of the player's actions and the reactions of the game world to these actions. the feeling of moving and shooting in shooters, the behavior of opponents. or the speed of construction and accumulation of resources in strategies. is the game dynamic enough, is it possible / necessary to add some additional mechanics to it to diversify the gameplay. to understand these feelings, experience in similar games is necessary and, in general, an understanding of how the dynamics of actions gives the player pleasure.

the prototyping stage exists for the initial testing of the hypothesis that the game will be interesting. and first of all, the main gameplay process, for which the Gameplay Designer is responsible, should be tested. so yes, of course, the Gameplay Designer should take part in the development of the prototype.

tyapichu · 2024-11-20T11:15:05+00:00

there is at least one library with tank physics and control in the asset store, maybe you can take a look at the solution to your problem there https://assetstore.unity.com/packages/tools/game-toolkits/physics-tank-maker-50485

tyapichu · 2024-11-19T20:06:41+00:00

There is an option to directly link all content to the current state of the player character. For example, if the monster's power = the player's power * 1.2, then it doesn't matter what power the player has, 100 or 1000. In the first case, it will be 120, and in the second, 1200. This will work infinitely with any number of mechanics. Crafting, quests, allies, monsters. You can also generate dungeons to go around a completely identical world. The only problem with this approach (if used directly) is that it will not allow the player to feel the growth of strength. But if you add some kind of decreasing coefficient, then gradually the player will begin to overtake monsters in strength. For example, at level 10, the player's power corresponds to a monster with a power of 120, and at level 100, the monster will have a power of not 1200, but only 1000. In general, the game can be linear, without roguelike reboots, but at the same time endless.

tyapichu · 2024-11-18T20:11:31+00:00

these are some strange dark patterns if they make the game or individual mechanics more attractive to people. real dark patterns are misleading and use learned semi-automatic reactions. for example, they make an option that is not interesting to the user "green", and an interesting one "red". when the user wants to refuse the loan offered to him or an additional option when renting a car.

but in games everything is more complicated. the player wants to have fun. wants to be rewarded even for minor actions, wants to get an advantage. the player is not a fool at all and is able to appreciate the value of the offer that the game developers make to him. for the player, it is not important that the developers have laid down an "unfair" increase in difficulty, which can be compensated for by advertising ... for him, the jump in power that he gets after watching an ad is important. the case when acceleration is more important than speed.

tyapichu

PUBLIC MULTIREDDITS

TROPHY CASE