New capsule art, Droid Team logic, and Code Architecture.

TL;DR

• I created a new capsule for the game in Blender

• I am pivoting game into more "Action-RTS". I pushed my design of managing your droid team to support it.

• I changed architecture of the game's code and have some thoughts

• Optimization by removing mechanic of "switching computers in action"

• I am working on the next iteration for https://itch.io/jam/improve-my-game-jam-44

New capsule art for the game

I decided to move back to blender and create a new capsule art. My goal was to make I more "light" and show more key features of the game:

• Fight on surface - few droids, many enemies, mining minerals and buildings

• Modular droids inside a lab (process of building them)

• Command center with the view on the planet

In front of the scene I put the game's sign banner.

I feel it's much more "creative" than previous one. I feel it's not the last iteration, there is still something "off" about it. Probably it's something related to colors or composition.

What is most important for me is fact of learning Blender. It's so powerful software. From my perspective I feel it's the most versatile tool in gamedev. With great competence you can be useful for any gamedev team or marketing team or anything :D

Previous version:

New version:

Droid Team Management

This is the "pivot" I am working on.

Initially my game idea was more "RTS" way. You create units and use them on a mission. You can have different units with different classes. It's sound great but I was still in middle between Action game and RTS game. It was not pretty working for me.

Finally I decided to move into "Action-RTS" way. To make it more clear player has droid team which he can upgrade and extend. What important each droid is fully capable of beating the game but it should be different build, different experience. I think about weapons in "Hades" game. There was concept you can swap weapons that completely change your play style.

So I could rephrase it to: "You can create different builds of droid and use them how you like"

It's move to make game clearly in Action side. I want to simplify design od the game so it's much more easy to understand and finish as first steam project.

What I want to keep is idea of "Action-RTS" so you can control directly only one droid but you can "drop" more droids and switch between them to perform some strategy. The simplest use case is when you defend your base but the game shows extra opportunity in corner of the map, so you keep one droid in your base and drop extra to explore the map.

In practice that means I create extra layer in the game. It's "hangar" where you keep your droids. You can upgrade them, improve, add new one etc.

I still need to push this concept further but I pretty certain it will remain. It's simple and pretty common solution for games.

Game version in the corner

It was just classic problem of "wich version of the game you are playing?", "Did you play the latest version?".

I added extra "higher" layer of UI where I could put just information about the current version of the game. It will be displayed on all screens so I can easily answer above questions if someone share screenshot, video or just showing me on his computer. Simple :D

Code Architecture

It was right time to do something with the game's code architecture. Before I was just doing stuff as fast as possible but it's not something you can carry longer.

Good architecture keeps longer goals so it's always so hard to make decision to sacrifice your time to rewrite some code instead of pushing the game features :/

I decided to move in direction of simplest MVC architecture.

• Controller

  • Game runs controllers, they glue together all components. They mostly use managers/service to pass data to view

  • In practice they are Node but they not responsible to render data from models

• Model

  • Contains data and game logic

• View

  • Anything that renders, so I assume in Godot's language we call it Node

It's not obvious but we still have extra layer of "manager". It works on models but add extra layer of logic mostly on collection of models. In my case I can have "droid manager" that operates on collection of "Droids"

The most important part of architecture is clear separation of data and node. No matter what kind of architecture you pick, just keep them separate!

• Model

  • In Godot's language we could call it Resource, more here https://docs.godotengine.org/en/stable/tutorials/scripting/resources.html

  • It contains data and pure logic

  • It can be saved on disk and loaded from disk

  • It can contain relations with others models (eg. Planet contains PlanetPositions ..)

• Node

  • takes data as parameter (export)

  • It contains "view" so it reads data and display the character

  • It asks model about decisions "can I attack this other character?", "How often can I attack?"

This is "more common" approach in business applications but I didn't care about it when I started my gamedev journey. It is "pretty ok" when you make small jam games but this approach won't really work for bigger game. To be honest it could "work" but maintaining it will be horrible and forget about making fast expansion for the game if you succeed.

I saw devlogs about terminating projects after one year because of super spaghetti in code, so it's serious.

Screen shot of current catalog structure:

Fun fact: I did some Godot tutorial but not single one was talking about code architecture. To be honest mostly shows pretty poor practices. I cannot really complain, we must remember many beginners in gamedev starts with coding as well. Tutorial makers must adjust code level to them! What most important: Finally player DOES NOT care about code quality so you can make a hit with poor code (with assumption that game works fine for gamer), it's all about supporting your long goals in gamedev.

Optimization

This is still in progress but I decided to simplify design and get rid of idea of switch between computers in action.

It's good optimization bump because I come back to render only one scene at once, before it was at least 2 scenes at once.

Anyway I couldn't find any good design for this mechanic and explain anyone what to do this. I keep my solution in pocket, maybe it will comeback in different use case.

I will more focus on optimization when I finally catch "wind" with better game design.

What's next

I am working on publish next iteration for

https://itch.io/jam/improve-my-game-jam-44

and few others jams.

My plan is to now simplify design of game and then again start to building up complexity. If I can't find fun in simple design I cannot really make it better with extra layers of features upon.