ar-rapidprototyping

[ar-rapidprototyping]

Dungeon Crawler - 17/10 - the finale

Today is the last day of development and so I am going to be cleaning up the stuff with the build system and the upgrade screen, preventing the player from shooting themselves to death, try to fix the long lasting bug where the enemies decide not to shoot and more.

So starting off with the enemies, I changed the recovery time from 1 to 1.8 so that it isn't a frequent thing, but if an enemy has been hit and is moving really slowly - they can recover. After they have recovered once, the time taken to recover is doubled.

Now for the issue I have had since the start; sometimes the enemies will just stop shooting. After looking through my code a bit, I noticed that to shoot; the enemy needed to be completely still:

So I thought it could help to have the velocity set to zero whenever the enemies isn't being hit.

From looking at these two screenshots, you might see that I am using two different vectors: this is because it vector2 will only monitor the x and y values while vector3 does x, y and z. As it didn't really matter if the enemies are moving along the z axis (which they can't) but just incase I reset all of the values.

Anyway this seems to have fixed the issue!

Now for the player stuff. I reckon a solid 33% of my deaths while playing my game has been from killing myself by shooting (to put it a little clearer; health = ammo, when ammo = 0, health = 0). So I made it so when the player has only 1 ammo, they can't shoot and it'll play a sound to let them know. Pretty simple stuff.

I also increased the player's move speed from 3 to 3.5 because it was a bit of a bore getting from room to room. I also want to change how the rooms are generated a bit. So in the player movement script, I increased the amount of things that can spawn in each room from 1-2 to 2-3 as there were not many rooms where it would have a different layout and enemies in. However I also have to decrease how many enemies, materials, etc can spawn at once since its going to be doing this up to 3 times. So the enemies have gone from 2-5 to 2-4, the materials have gone from 1-6 to 1-3 and the gems have gone from being a 1/30 chance to 1/40 chance and cannot spawn on the first 3 rooms.

Something I don't have yet is a game over screen, so i'll get on that...

So I got the game over screen, and its simple but it does the job (plus it fits in with my theme).

And here we control what happens when the player dies:

The variable "playerIsDead" is used to turn off the stuff I dont want to use when dead, like shooting and moving. Also the reason I delete the enemies is that they themselves make a lot of sound, and I don't want the player knowing this is just a screen I put over the game.

I also made reloading the scene into a function so I can access it from my button in the game over screen.

After some more play testing of my own, I decided that I made the gems too rare so I changed it from a 1/40 chance after 3 rooms to 1/20 chance after 5 rooms.

In an attempt to steer away from the building aspects, when you collect a gem, the upgrade screen will pop up and the player can buy upgrades using their ammo.

I also made it so that the enemies will spin whenever you hit them, just for visual effect.

I added the 3rd and final upgrade, which is a chance to dodge an enemy bullet.

And finally, I published my game to Itch (where you can play it WITHOUT downloading anything). Click the link above to go to my itch page.

[ar-rapidprototyping]

Dungeon Crawler - 16/10

Just some bug fixes today.

So first things first I fixed a bug that would return errors when the game manager is trying to set the enemies to a random size. This was an easy fix though, I just had to check if the enemy exists before I try to change it.

Another important thing to know is that null isn't a thing, literally.

I also made it so that all three barrels will disappear when enemy no3 dies.

Then I made the mass scale with the enemy's size, so that the larger they are; the less knockback they take.

I add 1 to both of the values so that its not gonna be something like 0.4 * 0.9 (which would make the mass way too small).

For whatever reason my bat wasn't a trigger, so it would make my player bounce off walls. So I changed that super quickly.

I also added a new feature, where the enemies will recover after a second and go back to moving and attacking the player.

However I may have to tweak this as it is hard to kill enemies now.

[ar-rapidprototyping]

Dungeon Crawler - 11/10

Todo:

Finish adding sound to stuff and fixing that which breaks

Add the objective stuff I had planned yesterday

Fix some bugs

Add a new enemy type (optional)

-----

So far I have made some new sounds with jsfxr, imported them to my project and have linked them up within the scripts. Also I fixed that problem with the parry system's sound by simply unchecking the "play on awake" box on the audio source. The play on awake box makes it so the source will play the current clip whenever the component becomes active (like during my swing animation).

And for whatever reason - the lower the "priority" the higher the priority? Anyways, because I needed a sound for the player getting hurt; but couldn't make the enemies' bullet output a sound because the sound would be played for about 0.01 seconds; I made a function inside of the player behaviour script and triggered this from the bullet script.

Also don't mind the indentation, Visual Studio is being a bit wack at the moment.

And one accidental PC shutdown later, I have made a new object and given it a particle system for when it spawns - and have made it so that it has got a 1/10 x 1/10 chance to spawn when a new room is created; which sounds like a lot, but I have gotten it within the first few rooms before. This will be what the player needs to find to beat the game.

I'm thinking that every one of these you get should make the game harder, like making it so the enemies' bullets bounce off walls. Here are the designs for the endgame objects:

I'm also thinking of changing the end of the game from having to fight waves of enemies to just returning the crystals to the player's base.

I don't know why I don't use colour more, this is delightful.

Turns out we may be doing another play test sesh this afternoon, so I quickly whipped up a sick looking tutorial page:

I also added a new enemy real quick. The design is kinda lazy but it adds more variety to the game:

You can properly guess, but they shoot slowly all around them. They also can't move.

[ar-rapidprototyping]

Dungeon Crawler - 10/10

Todo:

Add some sort of objective the player has to complete to beat the game.

Make it so the player can access upgrades through the workbench.

Finish the build script from yesterday.

-----

So I started off with the script that gave me trouble yesterday, and turns out I was spot on with my ideas as I completed the script in a fairly short amount of time.

I did a bit of tweaking to this script and made some of the IF statements into functions and made it so the player can't pull out the build menu in a room that isn't their base (apart from if they don't have one yet).

On to the work bench upgrade screen problem, it seems there were two sides to it. The first side is that the text was covering the button and the second side is that because the work bench is a prefab, I can't set it to a function.

So after a bit of testing different methods from the Scripting API, I found a method that works. I also learnt a useful method known as FindComponentInChildren<>()...

With this I can set the button to do trigger different functions during runtime. Now I can remove all the stuff with the max ammo count and the automatic upgrades.

Also these are pretty important for scripts that control UI, scene management and the text mesh pro stuff:

While doing some play testing of my own, I noticed that my turret script kept return errors. This is because I made it so that the script will look for enemies IF it has already found the enemies, otherwise the whole script is useless...

This is what the improved script looks like:

Now for the end objective, I'm thinking the player should have to collect 3 items and return them to the base before fighting waves of enemies. The items will have a small chance of spawning in with each room and there can only be one of each item. I'm also thinking of making it so that the game gets harder depending on what items you have.

However I don't have a lot of time left for today so I am going to be adding some sound effects from jsfxr.

Because I can't remember if this is already on my blog, this is how you add audio. You need an AudioSource and an AudioClip variable where the AudioSource is a AudioSource component and the AudioClip is just your sound.

So I have added sound for when the player and enemies shoot, and also for when the player catches/parrys a projectile. Although after catching a projectile, it will always play the sound when you swing, even if you miss the projectile.

[ar-rapidprototyping]

Dungeon Crawler - 09/10

Todo:

general tweaks

making the build script work normally

-----

For some reason the building is really inconsistent, sometimes it'll let me place buildings and sometimes it won't.

For whatever reason I can only place buildings down here where the crosses are.

So turns out that there was a random object with a collision box attached to my main canvas.

With this the building works again, which was a lot easier to fix than I thought it would be. Now I am making the turrets actually work as I kind of neglected them since the start.

So I tried to take a shortcut before where I got the enemy reference from the game manager script instead of just casting to it from the update method.

This was all I had to write by the way... Anyway that that I have changed this the turrets will look towards the enemies and will shoot the same projectile the player uses to kill them.

So they now work as planned, however I need to limit the buildings to only spawn in the room where the work bench is.

Real quick, I changed my animator so that the 'New State' state plays 10X as fast so that there isn't any delay to have the build menu appear on screen.

So a bit of planning ahead, I'm going to see if I can point a ray forward from the workbench and set that as the collide that the other rays must hit to spawn.

I ran out of time for today, but here are some ideas I had:

Raycast2D whatever = Physics2D.Raycast(workBench.transform.position, transform.TransformDirection(Vector3.forward), 5);

if (whatever.collider.gameObject.CompareTag("roomMid") { Vector2 whereever = whatever.collider.gameObject.transform.position; }

if (buildRot.x < whereever.x && buildRot.y < whereever.y && buildRot.x > -whereever.x && buildRot.y > -whereever.y)

[ar-rapidprototyping]

Dungeon Crawler - 04/10

Todo:

finally add doors

add more upgrades

add another enemy variant or enemy ai

-----

So I have added four squares on top of the doors, and they will become active when there are enemies present and deactivate when there are no enemies left. It is attached to the game manager object, so like the camera it will follow from room to room. I have also given it the appropriate tag, so that enemies will die when they touch it.

This wasn't as bad as I first thought it would be, and was only like 8 lines:

The short timer makes it so the doors dont spawn fast enough to block the player from entering the room, but also not slow enough to give the player time to enter and leave the room; trapping them in the previous one.

On to the enemy ai, I got this done so far:

What it should do is: when the timer gets to 0, it will get a random location within a rectangle around the enemy. From this location - a ray will emit downwards (or forwards) and if it hits a wall, it will get a new location and repeats. If the wall is not hit, it resets the timer and moves towards that location.

But my enemies are quite fond of running into the walls.

So I made this which is an upgrade, but they will still run into the walls a little less often. Also top tip; Vector2.MoveTowards is a value not a method, so it won't move anything until you tell it to with something like transform.position =.

I tried this again but with a BoxCast instead of a Raycast.

It was a fair bit better but they would still kill themselves, so I took a break from that issue and made it so the enemies would be a random size when they spawned.

They look a little funky, but I like it. Besides, the two variants are still distinguishable.

Although another problem had risen from the creation of the ai, the enemies can't die (unless they kill themselves). This is because I didn't write any code to make the enemies move when hit, it was just a result of the colliders colliding and pushing the enemy.

And this no longer works as the enemy is constantly trying to move to a different location.

So once again this was easier than I had thought, I just made a bool in the enemy script where it must return false to let the enemy move; and then just set it to true in the player bullet script.

It also looks a lot cleaner than it did before, so thats a bonus.

Something else I learned is that you can declare components like this:

Which doesn't serve any purpose that I can see other than looking nicer.

Back to the enemy killing, ammo is now very valuable as you can no longer barge into enemies to send them flying; which is what I was looking for originally. I will add a another melee option however, just not one as powerful as walking into the enemies.

So I added a bat that knocked enemies to the side, but then I found out that I wouldn't need to shoot at all just like before.

The bat was a cube with an animation that made it swing around the player.

Now I am going to add a mechanic where - using the same animation - the player will grab the enemies bullet and that will give them +1 ammo temporarily.

Here I made it so that the bat will absorb the bullet and give the player +1 temporary ammo. This only works if the player doesn't already have the temporary ammo. I also made it so that the text changes colour when you have temporary ammo:

The Color.Lerp method gets a value between A and B, so here it is more blue than white (so its now more like a light blue).

The ammo stays for 3 seconds then disappears.

[ar-rapidprototyping]

Dungeon Crawler - 03/10

Today I am setting targets built upon the feedback I received yesterday.

Most of the reviews I got were about the enemies, which was fair enough as they were fairly neglected until now.

So with this I will be creating two new enemy variants, as well as making them spawn more often. I plan to get this done this week.

I also plan to fix the bugs were the enemies and ammo dots can spawn in walls. I plan to do this this week. ✔

Finally, I will finish my upgrade system. Once again I plan to do this by the end of this week.

So starting off with the bugs as they seem the most disruptive and the simplest to fix. I make a new script for the ammo where it will just delete itself if it touches a wall:

Nevermind...

I forgot that when using triggers, at least of the objects needs a rigidbody for whatever reason. Now it should be working.

Now time to work on the enemies. Because my enemies already die when hitting a wall I had to stop the particles from playing only when they spawn on one.

This was a lot simpler than it sounds, in fact I just got a timer and when the timer is done, the particles will play upon touching a wall. Otherwise, they won't.

The timer is 800 milliseconds long (0.8 seconds) so that it gives it a window for any enemies that spawn a little later.

I also made the delays between the enemies' shooting random:

I originally had the idea of the player using their workbench to open the upgrade menu, but after some trying I just couldn't get it to work. So now I am gonna make it so that the player has a max amount of ammo / health and when the player reaches it, the upgrade screen will open.

Doing this, I also changed it so that the player dies when their ammo is at 0 rather than -1 so now the player can die by shooting too many bullets.

So far I have made two upgrades: Move speed and free shot chance.

As you can see, the move speed upgrade increases the player's movement speed by 10% and the free shot upgrade increases the chance to shoot without consuming ammo by 7.5%.

I gave the building a big update so that you can no longer place buildings on top of other buildings and the walls. This also makes it so you won't accidently place a building when selecting another one.

This points a ray downwards from the snapped mouse position and tries to hit the same collider I used to detect what room the player is in. I also made the wall a 1x1 block rather than a 1x0.5 block.

I was going to add an invincible enemy, I decided against it as I didn't feel like it worked well in my game.

I felt as if there was no point in fighting the enemies as they don't do much other than shoot you, so I made it a 50% chance for them to drop ammo when they die; not only making it easier to upgrade, but to give them a natural reason to fight them.

I also made it so they will wait a bit before shooting as a lot of the time they would blast the player, firing squad style as soon as they entered the room.

[ar-rapidprototyping]

Dungeon Crawler - 02/10

Today we were doing some play testing, so there isn't much in the development department for today.

Here are the results:

[ar-rapidprototyping]

Dungeon Crawler - 27/09

Todo:

some kind of visuals

some general tweaks

improve the enemies / maybe add more?

-----

Immediately, I made the holograms of the structures snap like the they do when placed (I need Vector3Int.RoundToInt like before) and changed the wall hologram to be the same size as when it is placed.

I wanted to add some more variation to the rooms, but then Unity throws multiple errors at me. Say Stuff like:

Namespace <GameManager> type is already defined in "GameManager" of class.

Which was tricky to find out why this was happening, although I got it in the end, my game manager script had duplicated itself and so it was trying to define the same type with two different classes.

Now that that is cleared, time to add more variety...

So I added 3 new types of room layout.

I also neatened up the game manager script. Instead of there being 9 layers to the first IF loop, there are only 4 now. This means there is a higher chance for enemies to spawn.

By changing 2 lines of code, I just overhauled the combat system.

Now instead of hurting the enemy, your bullets will knock them back and like before if the enemies touch the walls, they die.

I just made the player bullet a solid collider and removed the line where it just destroyed the enemy upon hit.

Naturally, the next thing I added were explosions. When an enemy crashes into a wall, they will explode in a fiery (or bloody, depends on how you look at it) explosion.

I achieved this with Unity's particle system. I also deactivated the sprite renderer so it didn't look so awkward when the particle system was playing. Also important thing to note:

GameObjects use .SetActive("") / Components use .enabled = ""

I also made the turrets.

They don't do anything at the moment as I can't figure out how to cast to the enemies as both enemies and turrets don't exist at the start of the game. But this is what I got so far:

I just added a new enemy type... They are pretty much the same but they shoot in a spread.

The best part is that I didn't even need to make a new script for this guy, I just changed and added some public variables and that's it.

Surprisingly they aren't as lethal as the normal enemy, however trying to shove them is very difficult and can result in you getting hit up to 5 times in one shot.

In the game manager script, I gave them a 25% chance to spawn instead of a normal enemy.

Here's how I did the shooting for the new enemy.

I multiply the number of shots by a random.range value and add it to the rotation the bullet spawns at to change it's accuracy.

You see here if I were to set the amount of shots to 20, the acccuracy gets a bit wild.

[ar-rapidprototyping]

Dungeon Crawler - 26/09

Todo:

Finish building

add some weapon upgrades

some general tweaks

-----

First off I did some play testing, and I am removing the room that divides the screen into two. This one:

I just found it a bit annoying and most of the time, the smaller room is unreachable.

I then added these white dots that I want the player to be able to pick up.

These will be some of the materials the player requires to build with and upgrade weapons with.

I added these to the spawn script like so:

And I have fixed the building system, the issue was that I would do take away the player's position from the mouse position, and that means that it could only be on the first floor as it wouldn't change position with the player.

So I just made a new variable and set it before the position was taken away.

So the plan for the base building aspect is that the player can build both structures and defences in their base (the room with the workbench in) and can upgrade their character in such base.

So if the player finds a room like this, it could make for a good base.

I think I'm going to make a build menu (a little pop up from below) and then I can add more structures (like a makeshift wall).

For now the build menu will look like this:

So I have added an animation and some code to raise the menu from the bottom of the screen and to make it go back down when space bar is pressed.

I went ahead and moved all the building code from my player behaviour script into my new build menu script just to keep it tidy.

Then I started work on the walls, which was literally just the copy and pasting the work bench spawn and changing it to spawn walls.

I also added a way to rotate the walls with the R key.

Safe to say I had a lot of fun with the walls.

I made a little hologram of the selected structure at the mouse cursor so that the player can see the size and rotation of what they are trying to place.

The hologram appears and disappears upon opening and closing the build menu.

That's enough on the building for today.

At some point I will polish the building so it doesn't have all these overlaps:

I increased the size of the player, enemies, player made walls, all bullets, the materials and decreased the player's speed by a little.

I added an ammo counter, so the player only has so many shots before they run out. Ammo can be found on the floor (those white dots from earlier) and enemies can be kill by pushing them into a wall.

I had the idea to make the ammo counter, also work as the health bar; where if you have zero ammo and you get shot, you die otherwise you lose 1 ammo for getting shot.

I have added a UI panel with some buttons and some text that will serve as the upgrade screen. This will only be accessible from the workbench.

[ar-rapidprototyping]

Dungeon Crawler - 25/09

I am yet to think of a name for this project (hopefully something more creative than ten...) so for now I will just refer to it as Dungeon Crawler.

Plans for today:

Add some basic building mechanics so that it may be fine tuned later

Finish the spawning script from last week

-----

So starting off with finishing the spawner, I noticed that all I have got so far is a reference to trigger the function and where to spawn:

and a the function that spawns a single enemy on an if loop with random.range on it. The 4 references on this function is for each door, because they need to set spawnPlace differently.

And well it works, it's just rushed; so I'm going to add a way to spawn different enemies at once.

I've got it so that it spawns up to 3 enemies in a random formation whenever a new room is created.

However this didn't seem to work when I tested it, so I looked at the script and realised that I made it so that the FOR loop would run when i is less than or equal to 0 (which it never will be...).

I am still new to FOR loops in C# so this mistake was quite common. I simply corrected it so that as long as i is greater than 0, it will run.

Something else I realised is that it would keep adding onto the spawnPlace variable until it got reset by going through another door, meaning the enemies could spawn anywhere.

I fixed this by applying the random integers while it's spawning rather than before. I also made it so it's a 1 in 2 chance that it spawns a room with enemies or a room with nothing.

So grabbed a random wall from one of my room prefabs, made it its own prefab, and added so code so that its one of the options

I then decided that because it was a bit boring having either nothing, a wall or some enemies; I made it run the function itself twice 50% of the time. This adds a large amount of diversity to the levels

Also note that for some of my Random.Range values, I am setting it as an integer and some as a float. As an integer it can pick between the numbers like this: 1, 2, 3. Whereas for the float, it picks it like this: 1.01, 1.02, 1.03.

So for the building part of today I made these lines of code to place a work bench where the mouse is using some values from getting the player to look at the mouse:

It rounds to the nearest integer so that it can only be placed in a grid. However it breaks completely when the player leaves the starting room. So I'm going to leave it for now and work on it some more tomorrow.

[ar-rapidprototyping]

Rapid Prototyping - Proposal

I am going to be continuing the dungeon crawler, as I believe that it has the most potential and that I can add some interesting new features that many other dungeon crawlers lack. I think that I can add and experiment with many concepts and ideas I haven't tried before; such as building and crafting. I plan to export my finished game to Itch.io after the project is done, as it would be good to build my portfolio, as well as getting some feedback from those not within my class.

I plan to add a few unique mechanics to my existing project, like a feature where the player can build structures in the rooms out of materials they can gather from the floor or the enemies. The ammo is going to be in fairly short supply, as this will make the enemies a lot more threatening. As for the sprites, I want to try and make them as simple as possible, allowing me more time to focus on other aspects of this project; but also so that it makes my game stand out among all the low graphics dungeon crawlers (The Binding of Isaac, Enter the Gungeon, etc).

By the end of these three weeks, I plan to have: the base dungeon crawler I made last week with some new rooms, new enemies, building and an upgrading system.

Some other features I will try to add are: a limited ammo system where ammo can be a currency of some sort, a shop where the player can use said ammo to buy other materials or upgrades and a lot more variation in the rooms and enemies.

If I have time I may add: multiple animations for different actions (like shooting or going from one room to another), retro style sound effects, a settings page, a way for the player to drop some kind of marking to navigate the rooms easier, a raid system where the player's base can be raided by enemies and some kind of crafting element.

As for what I will not add, I choose to not make: complex and detailed sprites, custom sound effects, different levels or a level select, a mini map, multiplayer mechanics and a score system.

Overall I think that with these differing concepts, ideas and mechanics; I could make a game that stands out from the rest.

[ar-rapidprototyping]

Dungeon Crawler Research

The Binding of Isaac

The Binding of Isaac is a top down dungoen crawler where the player (Isaac) must gather items to escape the basement before his mother kills him. The items the player gathers makes them stronger in certain ways: whether it's making their bullets do more damage or making them shoot two bullets at once, there is quite a lot of variety in what used to be a 2011 flash game.

2. Enter the Gungeon

Enter the Gungeon is another top down dungeon crawler similar to The Binding of Isaac, where the player has to venture through a dungeon, collect empowering items and escape.

3. Hotline Miami

Hotline Miami is a retro style top down shooter where similar to games like Superhot, most of the enemies and the player dies in one hit. This means that the player must plan their actions before making them. Hotline Miami has many different weapons and masks the player can equip to change how they might approach a challenge.

4. Hades

Hades is a top down dungeon crawler based upon greek mythology. The player starts a run by fighting through several rooms drawn from a pool of pre-determined layouts, with the order they appear in and the enemies that appear being randomized. Upon clearing rooms, the player will be granted upgrades or "boons" to make them stronger.

5. Crypt of the NecroDancer

Crypt of the NecroDancer is a roguelike rhythm game where the player's actions must line up with the beat of the soundtrack. the player can only have their character move or attack if they perform the action on the beat of the music. As the player explores, they will collect new weapons, armor, usable items, and treasure.

[ar-rapidprototyping]

Dungeon Crawler TUT pt2

I start off changing the backround colour within the camera to a dingy green and quickly make a square, give it the needed components and a simple script to make it move around:

This is similar to the movement I used in my game, 'ten' but the player is able to move on the y axis as well.

I'm also setting the resolution to 1080x720 as this was an issue when exporting it to Itch.

I then spent WAY way way too much time trying to get the camera to change to the current room. This is the player movement script but with code for creating new rooms and switching the camera.

I spent around 2 and a bit hours to get the three lines of code at the bottom :(

Now I have added the raycasts that will detect if there is a room that the player is currently heading into. If not, it makes one.

Next I made it so the player is always looking at the mouse cursor.

This was harder than I thought despite having done it before.

Then I add a simple shooting script.

I made a function for the shooting code as I would like to activate this multiple times with some kind of upgrade:

And some simple bullet script stuff, if it hits the walls then it is destroyed. The function that spawns the bullet will also destroy it after 5 seconds.

I am making different rooms with different door layouts, this one doesn't have a bottom door obviously.

That little bulge where the door would be is to block the door on the room below, so that there aren't any doors that lead no where.

This is what the room below it looks like:

Its a bit like a jigsaw puzzle in a way.

I so now I need to select a random room to spawn, BUT it also has to have a door connecting to where the player is trying to enter through.

Which I do by selecting a random room each frame and depending what room it is, you can spawn it when you walk through a new door.

Although I only have 5 different rooms, the plugs on the other rooms can modify new or existing rooms to make something that looks like this from afar.

The room the player is in doesn't exist as a prefab to spawn, it was made by the room below plugging the other door.

I decided to polish the room design to make it look better, I have no need for those plugs as I thickened the walls to do the same job.

This doesn't change anything in-game, I just thought it would look nicer from the scene view.

I also made 2 more room variants so its a little more creative.

So now ive got bullets, I need enemies;

This script will detect if the player is touching an invisible triangle in front of the enemy or if they are fairly close to them. If so, the enemy will look at the player and will start shooting (I haven't added that yet). If the player gets too far away from the enemy, about half a room, they will stop shooting and wait till the player touches them again.

After adding the enemies' shooting, I decided it might be a bit tedious to work around the enemies vision mechanic. So I scraped it...

Although I kept the distance alert.

What would I do to improve upon this dungeon crawler?

I am thinking of adding more of a survival twist to my project, make it where you have limited ammo and have to scavenge for more. The player can build a base within one of the rooms and leave markers around the place so that they can find their way around the rooms.

I would also add more enemies and perhaps more room variation, just to make each room a little more diverse. And I think the addition of upgrades so the player could be an interesting concept.

[ar-rapidprototyping]

Dungeon Crawler TUT pt1

classic UE stuff to begin with

although i do make a room which is kinda neat

And with some walls

Now I will use this to spawn a new room when the player touches one of the boxes

This here changes the camera to that of the new room

And now Ive got a player in a room

However the rooms spawn, inside other rooms which isn't useful

Now I make a raycast using a macro (or line trace in UE slang) to see whether there is a floor after the door the player walks through.

Now after incorporating the macros into my spawn blueprint

Another reason I prefer Unity is that UE has a fair share of bugs in it like where i cant delete anything or where i cant split nodes.

Anyway, now after fixing some things in the floor blueprint (I had some values backwards) I can walk through the doors and a new room will spawn infront of me.

I added a sphere component to my player and made it look at the mouse

Then I added a simple enemy character and gave him this blueprint to move towards the player

Top tip do NOT enter a value larger than 1,000,000,000 as UE cant take it and will crash, okay scrap that no values larger 10,000

I added a nav mesh and this time DIDN'T make it "absolutely enormous".

Now with the nav mesh the enemy follows the player around

and this makes him deadly

Now for the players projectiles

this detects whether the projectile has hit an enemy and destroys it, otherwise it destroys itself.

Next I add a way to get score

This is what the UI looks like

And with that I am done working on this in UE, Unity time!

[ar-rapidprototyping]

Research - Brick Breakers

elgoog brick breaker

This is an average brick breaker game that is played in google's image page, where the bricks are images.

2. Peggle

Peggle is sort of a mix between a brick breaker and a plinko game as the player doesnt have a bat and relies on the ball bouncing on the bricks to clear them.

3. Idle Breakout

Idle Breakout is a brick breaker with idle elements. Like in a lot of idle games, the player has no way to control whats happening and no way to lose. Except the player gains money to spend on adding more balls or upgrading current ones to make more money.

4. Peglin

This maybe straying a bit far from the brick breaker theme, but Peglin is a cross between games like Peggle and deckbulider games such as Slay The Spire. The player has to break the bricks to deal damage to enemies and do other actions like healing themselves.

5. Breakout

Breakout is the first game of the brick breaker genre. Made by Atari and based on Pong, it has all the base features you'd see in a typical brick breaker game.

[ar-rapidprototyping]

Brick Breaker TUT pt2 electric boogaloo

Launching unity on a new computer sure does take some time...

So I start off adding some of the objects I need (walls, bat and ball) and I make the camera vertical (portrait) for a view.

Then I give the ball a simple script where it will move right of the object.

Something thats rather important is the physics material, which allows the ball to bounce automatically (without me having to code it all in).

Having a bounciness of anything below one, expect zero, will make the ball slower when it bounces; anything higher will speed it up. Keeping it at one ensures it stays the same speed.

For the bat controls, its literally just this:

So when the A key is pressed it'll move left until it gets to -8 on the x axis; and pressing the D key will do the opposite.

This is what I got so far: the ball and the bat move correctly.

Next I added the bricks to the game. They were very simple as they didn't need any new scripts, they just needed a few lines of code in the ball script:

This simply will check the tag of each object the ball hits and if it returns true, it will destroy the object that it hit.

I now need to add a bunch of these into a prefab so that I can spawn a bunch at once.

I've got three different shapes that I can spawn. Speaking of which, I made a game manager object and assigned it a new script.

This uses an array to detect how many bricks are in the scene, if there are 0 bricks; it'll spawn 1 of the 3 prefabs above.

Also another thing to note, is that GameObject and GameObject[] are two different types, the latter is used to declare arrays.

Now I'm at the same stage as the Unreal project.

Just for effects, I added a particle system to the balls, where it leaves a little trail like a fireball. This was just a case of adding and tweaking a new component within the inspector.

Whereas adding audio required a few lines of code within certain scripts. I imported 3 sounds from jsfxr (I ended up not using break2) and created variables for them like this:

The audio clips are what will be played, the audio source is where its gonna be played (which is more important in 3D). Here I set the clip in the audio source to 'explosion' and then play it.

I also used the Invoke() method, which runs a function after a certain amount of time. I used this because as the ball had the audio source, when I destroyed the ball, there would be no audio source to play the sound through.

I also added an animation for when there are no balls in play:

This was done in the game manager script as the ball cant communicate when it is destroyed. Also I made another array to check if there are no balls, as I plan on having a way of getting multiple balls. All this does is plays animation where it blocks the player's view of the screen and displays the classic "GAME OVER" text.

The player can still move the bat, but as there are no balls its pointless (although they cant see or hear the bat).

Something I forgot to add is having the ball spawn at the bat rather than having it someplace in the scene. So here, if ballOut? is false, it'll spawn the ball just above the bat and give it a random rotation so that it doesn't always go the same way. I also set the balls velocity here because it would be inconsistent before.

Just like the Unreal project I made a fakeball child above the bat that disappears when the real ball is spawned. So here there is no balls in the hierarchy:

I have added a power up that will spawn another ball at the bat when picked up, it spawns rarely from destroyed bricks and it will move downwards before it gets destroyed itself.

On the ball script, when a brick is destroyed it picks a number from 1 to 100 (or 0.01 to 1) and if that number is 5 or less, it spawns a power up where the brick was.

On the bat script if it hits the power up, spawns a ball and destroys the power up.

Another thing about arrays is that you can select them with a foreach loop:

For each ball in the balls array, it sets the speed to 14.

After experimenting with that, I decided to ditch the foreach loop and just increase the speed by 20% each level.

And then I spent around an hour trying to wrap my head around why my game manager script wouldn't reference my bat script. I was looking around both scripts trying to figure out what the problem was...

This line was in the wrong order. It couldn't reference the bat script because it was trying to figure out what this was. It's because I set the scripts AFTER the line that need the scripts.

Anyway after that I added bricks that have to be hit twice.

The only difference is the colour and that it a different tag.

This will detect what kind of brick it is, if its a normal brick it gets destroyed. Otherwise it destroys the brick and replaces it with a normal one. Making it seem like it has two lives.

What would I do to improve upon the Brick Breaker?

I would add some sort of rougelike element to it, like upgrades or some sort of abilities. I would also make the level a bit larger to fit more bricks on it and to give the player some more time between the ball hitting the bricks and it flying at them.

Obviously, I would add some more level types as well as some new bricks that could just be stronger, or could do something different like explode and clear many brick within a radius.