As I am writing the game, there are times I want to test something out in the game, but because of the nature of the game, getting to that state naturally will take some time. What I am doing is building in buffs that assist with that.
For example, I’m currently working on a lock, and the lock opens after some time. I can manually add a lock into the game and set it to a low time to open, but this is also an incentive to add a new buff to the game. Let’s make a buff that speeds up lock openings.
This does two things. First, it gives another stat that I can use. Now I can add more locks around the game world and make for more interesting interactions. Players have more control and can manage this. I can also make locks that take longer more dangerous because players have a way to offset that danger. Also, locks that are completed faster can give bigger rewards. Once again, because players can manipulate this.
Secondly, because I have the new stat, maybe I can use it for other lock-based mechanics. What else can this stat do? Right now it’s just for locks, but maybe it’s about manipulating other elements in the game that I’ve yet to design. I want to build in puzzles, so maybe this also gives more leeway in the time needed to defeat the puzzles. Maybe this is a general time state, and it allows us to modify anything that has a time component? I don’t know.
Basically, it lets us put more gameplay into the lock mechanic and add more depth to it because players have multiple ways to deal with it, and it opens the door to other non-lock uses.
I could have just dragged a lock into the scene and set it to a short timeout, but I find putting my solutions into the game opens up more doors.
In my head, I had picture guns circling the player, bullets firing from him. Each gun would be unique, and it would look cool. However, I also wanted you to have many guns shooting at once. You’re a robot after all, and you aren’t limited to two guns. When I added a second gun, it looked cool. To hand cannons each firing at its own target was pretty awesome. But when I added a third gun, it started looking messy. It started looking confusing. And I wanted you to carry even more weapons.
It occurred to me that as the player, you wouldn’t be paying attention to your guns. Rather, you’d be paying attention to the bullets and enemies around you. This meant that all those guns I was showing on screen were only useful for distracting you. Instead of having a clear understanding of where you were, there were these big guns spinning around you.
When I removed the visual representation of the guns, things became much easier to read on the screen. It was helped when I also gave the enemies their own unique bullets. Your bullets were blue, so you could see them, but they weren’t asking for your attention. The enemy’s bullets were brighter and they seemed larger. Now, instead of having too much going on, I could focus more on dodging and attacking.
Removing Assets and Work
The result of this is I won’t use gun assets in the game, it won’t fill up the scene, and as a result, I’ll probably not need to do as much work creating art for every gun. Instead, I can invest that time into creating the bullets you are firing, and coming up with more of them.
The real lesson to take away from this is to make sure that if something is on screen, it has to serve a purpose. The guns served no real purpose. You aren’t aiming your weapons, so you don’t need them to indicate where you are pointing. You are using all your weapons all the time, so you don’t need to see what you are holding at the moment. The only reason I added them was because you shoot from a gun, so obviously you’d have a gun. But we don’t need it in the game on screen.
So, I’m going to have to take a pass at everything I create and ask myself, what does this serve? And does it serve multiple purposes? Is it providing value? If it doesn’t, we should be able to remove it.
Enemy Colors
During this time, it also occurred to me that I should attend to the colors of the enemy. The squid monsters I have stand out, but the robots are blue. The same color as you. While I don’t necessarily think I need to change the robot’s color at this time, it made me think about camouflage. Enemies that are colored in certain ways can be hidden in plain sight. They don’t stand out. The key here is to know that you are doing that. And the enemies should still be easily distinguishable from a distance. The difference is that you aren’t drawing your attention to them. So while I’m not going to change anything now, as I design more enemies, I’ll do so with color in mind.
What does that mean? Visibility becomes an attribute. If an enemy has lots of strengths, making them easily seen is one weakness. If an enemy is relatively weak, with low health, and relies on sneaking up on you to do melee damage, making them less noticeable is one of their strengths. Again, the idea here isn’t to make the enemy invisible, only not to go out of my way to draw attention to them.
For people with color blindness, I’ll have to pay attention to what colors I pick, or at least handle this in color-blind modes, but that’s a long way off.
Playing with Shaders
I spent some time playing with shaders and built a simple app that lets me mess around with shaders. It was fun and reminded me it’s easy to build simple things like this in Godot. It helps me explore the different systems. The lesson here is to not be afraid to create new projects for the purpose of just exploring a certain aspect of the engine.
I released the project on GitHub. There are no expectations of anything. It’s merely there for testing purposes. However, you are free to explore and use it as you see fit.
The current codename for this game is xenod, Xeno Defense. This is a very early look at the game. There is still a lot to do, but I wanted to share this out to show progression. xenod is a roguelike set in space as you try to make your way back home.
Crafted Dynamic Levels
Crafted Dynamic Levels – Each level is the wreckage of a ship in space. You fly to these ships and salvage what you came from them. Because of this, I can design ships, and then randomize the interior. Think of it like this. Each ship is designed and build. Think of classes of ships. In Star Trek, you have the Constitution class, or the Galaxy class, or the Olympic class. Those are classes of ships. However, internally, they have different configurations. I design the class of the ship, and the randomized portion works with the various rooms and modules in the ship. This means you’ll recognize different types of ships, and you’ll have a good idea of the layouts, but you won’t know precisely where everything is internally.
I like this because it means you can learn the different types of ships and what that means for your excursion. Ship layouts will be different: some might have larger rooms, some might have many small rooms, some might have long corridors, others might have few to now corridors. The point is, different types of ships will provide different challenge. At the same time, different classes of ships serve different purposes. You might come across a class of ships that are used for scientific study, where as the next ship might be a warship. This makes a difference in where you go. Are you looking for more ammunition? You might look for a warship, or a military cargo ship.
How is this a roguelike?
There are several key elements that I’m focusing on, and it happens that it fits into the roguelike theme. First and foremost, let’s talk about permadeath.
xenod is build with permadeath in mind. You have one life. If you die, it’s over. However, you are generally not playing directly as your character. Rather, your character is sending a robot into the hostile derelict spacecraft to scavenge the supplies. Your robot can die, but that’s not you. If your robot fails, you get nothing. You lose the parts used to make the robot, and anything you weren’t able to recover. While you can rebuild robots, fail often enough and suddenly you are stuck out there. No fuel, no food, nothing. And you die. This isn’t meant to be a way around permadeath. Rather, it’s the gameplay I wanted, and it happens to fit into this category.
This also gives you resources to manage. You need to balance where you spend your resources. Upgrading your robot means they have a greater chance of survival and success, but it also means diverting resources that might make it easier to reach the wreckage you need to get the resources you want. That food you need to survive? It’s just out of reach, and if you’d improved your engine efficiency, maybe you would have reached it.
I didn’t set out to design a roguelike. However, as I’ve worked on the game, I find elements traditionally associated with roguelikes can help improve the game. In future posts, I’ll talk more about other design choices that are informed by roguelikes.
It looks like a bullet hell
Yes. One of the inspirations for the game was Vampire Survivors. I want crazy weapon combinations, and I want the player to enjoy that while they explore and scavenge the ship. They can focus on dodging enemies and attacks, and target things they need to retrieve. All the while, the robot targeting system does the work, and your arsenal of weapons fires away.
Initially the idea was to allow you to point to shoot, but I found it cumbersome. And if you were pointing to shoot, it meant you were focused on that, and not the other elements of the game. I wanted you to be focused on getting in, getting what you need, and getting out. I want you to loot. However, the idea of shooting waves of enemies is fun, too. And since it’s a robot you are piloting, the robot can use its AI to shoot at the enemy. You, as the controller, can focus on moving the robot around, setup turrets to defend, and find loot that needs to be taken back to the ship.
This doesn’t mean you can’t fight. Quite the contrary, your arsenal is strong, and because of that, sometimes you might focus on clearing out a room, but in that space, you are focused on dodging and getting the best angles on the enemy, avoiding attacks, and looting items that drop on the ground.
It might be interesting to allow you to customize your AI on your robot, to change how it targets and what it targets. Some weapons will just shoot everywhere, and some will target enemies. However, I’m not sure if I’m ready to commit to that. Is that an interesting thing? It might be. Part of planning your attack, but that also means knowing what you will see before you board. How will I share that information with you? While it’s one thing to know the layout of the ships, how will you learn what kind of enemies you will face, and whether you should set the AI for targeting fast enemies, or hard hitting enemies? I want to avoid having to spell things out. I’d rather show you things, rather than tell you things. And I’m not sure if I can do that right with the AI setup.
Anyways, this is my first post on the subject. I’ll post more as time goes on. I’m considering making videos. Maybe I can do that? We’ll see.
Jason Lotito 