nitrosodiumrapidproto - Tumblr blog

[nitrosodiumrapidproto]

Adding PawnSensing

On a new map, I added PawnSensing to all the enemies. Unfortunately I could not make it a circle around the actor, so the best I could do is a flat hemisphere. I do have an idea of how to remedy this though. I'll connect the PawnSensing to a scene component that can then be rotated independent of the eventual flipbook that will be added, if that is even possible. I want the enemies to move like the player: that is to say, no rotating. I don't want them to turn to face the player, I just want them to move.

Basically I've achieved very little, because as it always is in gamedev, solving one problem will always create one.

[nitrosodiumrapidproto]

Proposal for my new Project

Having now made all three of the “tutorial” games, I have been able to make an educated decision on which will be the most interesting and rewarding to develop. I have chosen the dungeon crawler, as I believe it has the best potential and ability to be innovated on. The infinite runner is something I have done before for Sweat Pursuit, and the block breaker is a very rudimentary concept gameplay-wise and something I am not interested in. Meanwhile, the dungeon crawler is immediately a multifaceted idea with elements of exploration, combat, and strategy interwoven. A lot can be added to this basic framework, including more complex health and ammo systems, AI for the enemies, and interesting level design and emergent gameplay in terms of problem-solving and combat puzzles. The top-down perspective is also something I have not yet really tried, which will require new artistic solutions to make assets for.

The current name for the project is “Accursed Crucible”. It will take place in a fantasy setting; specifically, within the titular Crucible, which is an ancient forge overrun with fell creatures. You play as a lowly dwarf armed with the Hammer of Heaven, a holy weapon that can banish the evil and purify the Crucible. Lore-wise I have some basic ideas; that the Hammer was created in the Crucible and is naturally drawn back to the place from which its metal was first poured. Forging its own destiny, as it were. The artstyle and sprites will likely be 16-bit, since smaller sprites take less time to draw, but I don’t want to make them too simplistic. This should allow a level of detail to be retained roughly on the level of a Terraria or RPGmaker NPC. The enemies will be typically evil fantasy creatures: orcs, undead, liches, and similar things. Lore-wise they have taken over the Crucible to forge their own holy weapon and wreak havoc with it, and of course the powers of heaven cannot abide that, so they have sent you as a sort of dwarven messiah. The combat will be as simple as it was in the dungeon crawler tutorial – move away from enemies while shooting your hammer’s projectiles at them. Strategy will be added by having to manage your own ammo; staying alive and out of danger while finding more. This then incentivises exploration when it would have otherwise been unnecessary beyond finding the exit.

I plan to go back to basics when it comes to the art assets for this game. I will use Photoshop for both character sprites (i.e. the dwarf and the enemies) and also for the tilemap. In-game most things will be paper flipbooks, as they were in my first project, Toxic Waters. Then Unreal is the obvious choice for development; though other things are available like Unity or Roblox, I see no benefit to using them for this, especially when my original dungeon crawler code is on Unreal anyhow. There will not be any new techniques this time, I think.

Here is a MSCW (Moscow) analysis of the project:

Must Have - Some nice spritework, health + ammo system, multiple enemy types

Should Have - Notes with lore, high score system, locked doors

Could Have - Chests with randomly generated loot, immersive-sim elements such as choosing to bash down a door at the cost of ammo, using a rare lockpick to open it, or searching around for the key

Won't Have - Multiple weapons, arena-locks

This week, I plan to lay the groundwork for the project, which is mostly gameplay. Health and ammo, enemy detection, more enemy types, ammo and health pickups, et cetera. If I have time, I will make sprites for everything, including the tilemap. How I will make the map I am still not sure - maybe a tilemap pointed upward with collision boxes to bulk out the walls?

[nitrosodiumrapidproto]

What I would add to the Dungeon Crawler

Before this project, I had little interest in dungeon crawlers, but I now see that this idea has some potential. If I made it a full game (which I very likely will), I would add spritework for the player, the dungeon, and the various enemy types. The enemies themselves would also likely require proper PawnSensing to see the player instead of beelining right for them. Then there would be the matter of health and ammo for the player. I would also like to add randomly generated loot for chests, though that would obviously require a lot of effort.

[nitrosodiumrapidproto]

Adding New Enemy Types

Meet "EnemyBigBoy", a child actor of the usual enemies. He's larger but slower, and his health values are the same as usual (albeit added by hand). This was my test to see if I could make child actors of the main enemy template and have them still kill and die. Because of his size, I also gave him a box collision that fits his new spheroid, and it works perfectly off OverlapAllDynamic.

[nitrosodiumrapidproto]

Fixing the Enemy Issue

I set the projectile hit code to run from the enemy completely. Now the projectile itself just destroys on hit with anything, and the inner functions are contained within the target actor.

My main thing now would probably be to make a health system for the player, and maybe my own sprites and such. Though that is more something I'd do for a full game. I will probably make the Dungeon Crawler the game I 'uplift' and turn into a full experience though, so it does make sense to at least do some more rough code stuff right now.

[nitrosodiumrapidproto]

Issue with the Code

I've put all of the "enemy HP" sort of code inside the enemies for obvious reasons. However if you hit them now, the first enemy placed in the world always dies first, no matter which one you hit first. You can imagine that this is intensely frustrating, because no matter what I do with this projectile-centric code, it will be running from the Get Actor of Class which pulls the original enemy no matter which one I hit.

[nitrosodiumrapidproto]

Adding a Score System

Firstly I made a game instance which had a Score variable in it.

I put this code in the enemy. The EnemyScoreVar variable is public, meaning you can give each placed enemy their own value.

I also altered the enemy death code so that it adds to the score.

This code is in a basic widget and shows the score.

Now the main bulk of the things is done, but I have a few changes I want to make. Namely, the enemies shouldn't die in one hit. My theory is I can make child actors of the main one, with their own health variables which get decremented on hit.

[nitrosodiumrapidproto]

Adding a Basic Shooting System

Firstly I made a basic projectile actor with projectile movement component. I also made a new collision system for it.

I then made a new input action for shooting.

This is the code inside the player for shooting. It gets the location of the shooter sphere and spawns the projectile on it.

This is the projectile code. Granted, it does destroy an enemy, but it also only appears for a split second and doesn't move.

Here is an image I got before it disappeared.

EDIT: I fixed the projectile by adding an initial speed above 0.0 units. However it only lasts about one second before disappearing, and doesn't travel far in that time.

EDIT 2:

By setting the projectile gravity to 0 instead of 1, it flies forever.

[nitrosodiumrapidproto]

Failing to Create Enemies

I first made a basic character with some movement code.

The idea is to always know where the player is. A few variables were also changed in the project settings, including having it possess AI from both spawning and placing, and making it an invoker. However it did not move at all when put in game.

Apparently everyone was having the same AI problem, and the solution was to spawn it in.

This code ran off a 'spawn point' scene component placed into the floor parent, which brought it in the game finally. However...

The "move to player" code just constantly failed on repeat. So I have no idea what to do.

[nitrosodiumrapidproto]

Making a Cursor System

Firstly I made a scene component and connected a sphere to it.

This is how it looks. The sphere also has no collision.

I then made this code, and had the event trigger on event tick. It essentially rotates the Pivot scene component about the actor in conjunction with the cursor.

This is it in-game. Sort of looks like a planet with a moon.

[nitrosodiumrapidproto]

Making Random Rooms

In the FloorMaster actor I made a variable which was an array. I then made child actors of the FloorMaster and plugged them into the index.

I then connected a random value of that to the classes of the room spawn code.

These are some of the random rooms that spawned.

[nitrosodiumrapidproto]

Fixing the Proc-gen System

It turned out that fixing my code required two things. The first was to destroy the landscape that automatically spawned in the level, as this was being detected by the landscape and therefore not triggering the room spawn code. I then had to change the variables on the spawn code to run from Y instead of X, as this was causing them to appear in the corners instead of flush door to door.

This is how it now looks, with the line traces made visible.

[nitrosodiumrapidproto]

Adding a Macro

A Macro is some sort of multifaceted event whose variables can be altered from the outside. It seems to draw a line trace, to check where the doors are.

I then added the macro to this code from before, which would supposedly put the new room squarely in the doorway instead of up in the corner. Instead you can go through the door and not come back. And also no rooms spawn. So it still doesn't work, and in fact the error makes less sense than before.

[nitrosodiumrapidproto]

Making a Procedural Generation System

First I made a FloorMaster actor, which consisted of a flat platform with four doors at each cardinal direction.

I put this code in the player, which uses linetraces to check when the player enters a new room. This then sets the camera to one above the new room.

I then made four big lines of code for each doorway, which essentially spawns a new series of rooms when the player goes through a door.

It looks like this in-game when you start.

However, the room generation soon breaks down and becomes like an M.C. Escher painting.

[nitrosodiumrapidproto]

Creating a Dungeon Crawler: Making the Player

To start off, I made an empty Character and added a cube and a camera looking down at it.

I then made an input action and set it to Axis2D (Vector2D).

Then I put the action into an Input Mapping Context and made various values and keybinds.

I put this code in the player, and also made a gamemode which I made the default in the Maps and Modes area.

In game it looks like this, and moves around.

[nitrosodiumrapidproto]

What I would add to the Block Breaker

While the game is fine on a functional level, if I was going to make it a full game, I would probably make the bat larger. The ball's code should also be tweaked; it's frustrating in a way I can't describe. In something like Arkanoid, the ball usually bounces off at roughly a 90-degree angle relative to where it first hit. Meanwhile in my version, the ball instead bounces off at a 180-degree angle, i.e. right back to the paddle. If you want a ricochet, you have to target the side of the capsule, which tends to send the ball flying unpredictably.

[nitrosodiumrapidproto]

Adding a Level System

This system, when it recieves a BrickManager event, changes the level and restarts the actual playable level.

This sequence counts how many bricks are in the level, and sets the BrickCount variable hence.

Altogether, this gives the appearance of level progression.