I have developed a map editor and this then brought on more things that I needed to decide.

Rooms (“maps”) will typically have the same layout on room start no matter how they are picked. X amount of bad guys in the room in Y location. The game will decide where to place the doors. I the designer will decide where it can place those doors if it is going to use them.

This led me to understanding that the collision boxes for the walls aren’t going to be predefined, but they will depend on the doors in the room. There are a lot of tricks I can use to simplify how I approach this, but in my case I’m going with top,bot,left,right wall doors. That simplifies the need to do collision detection to determine if a wall should have a gap for the door or not.

In the map editor, I was thinking to have multiple layers for a door. First layer would be the door itself. The second layer would be what to show if the door is not present. This can be doodads and other things. Which leads me to the idea that I need to have a way to control all that.

Doodads can be managed by simple

struct doodad {
int posX;
int posY;
AtlasSprite sprite; // Gives the texturePosX PosY width height for rendering
};

This works out fine to start. Unfortunately, I can see this growing into something bigger if the doodad has animations. And if I want to have interactions I will need a whole different things. I could do the monolith struct approach. I have to think more on this.

For simplicity sake, I can move forwards with the idea of doors and them being “enabled/disabled” and drawing the collision boxes with that data. That will at least get the game to a playable state. The additional task of visual layers is a concept I definitely want to flesh out.

Which I could do so now.

Visual layers can be used when a door is disabled. I’m thinking of quite a few ways to utilize it.

• Blank

• Decor Set 1

• Decor Set 2

• Decor Set 3

Which would be 3 unique styles and a default empty style for the wall. This would help spruce things up with variety. You may have noticed by now I have 2 styles I want things to have:

• Random - RogueLike

• HandCrafted - Designed by a human.

In this game I’m going to combine a lot of randomness and handcrafted elements. Randomness will decide which handcrafted elements to use. So we will have deliberate puzzles, room layouts, etc. However, we will have random connections between rooms and the floors will have random layout per run. Mid session bosses could be picked from a pool.

Ultimately my design decision here is that the game is deliberate events laid out semi-randomly through a playthrough. This allows for my game design skills to shine while also increasing replayability.

That is all for now. I needed to get my thoughts on paper so I could move forwards in development.

One may ask, why do you stop him? The veteran may say “I don’t, I just question him.” And often, the questioning still stop the blunders. The veteran is strong and able to keep his team safe from pitfalls. All is good.

The executives seeking funding will not stop the investors. The investors are beginners typically when it comes to technology. They hear the phrases: blockchain, AI, kubernetes, docker and the drool begins to form.

The executives don’t stop the beginner. The veterans do. However, when the veterans aren’t guarding the gates and the executives go around their veterans they get junior level opinions and all of their blunders.

A junior engineer loves to learn. He wants to keep growing. These are especially good things. However, the junior does not know the consequences of his decisions to a company and that isn’t in the center of his mind, yet.

Because the junior wants to learn he will be very eager to accept a new technology. The junior may have not learned how to push back effectively. This leads the junior to outright accepting their bosses requests. Days or weeks later the veteran might catch on and stop the junior and have a private discussion with the executive. The veteran has to slow him down a bit and refocus him. He has to stop the pitfalls of eager technology adopting in favor of using what is present effectively. He can not be a fanboy.

Sometimes this is all too late and the mistakes are on production, the executive doesn’t want to “go backwards” and the junior is frustrated. This is textbook how to get bad technology decisions into production and setup landmines for later.

These future landmines come out as simple exceptions added to the logs, missed production releases, delayed projects, frustrated team members, and employee turn over. The marching drum of “This is how we have always done it” keeps beating. Beating your company to death.

• How do we get out of this mess?

• Do we really have to become the veteran and stop the mindless technology creep?

• Do we have to stop our investors from making mistakes?

• Do we need to train our executives to listen to their technology team?

I emphatically say “Yes.”