Erronis Games

https://www.youtube.com/watch?v=MsawTaSUusY

One Gun

Recently, I put a lot of focus into the gun. The game is named after it, so it damn better be iconic! Or at least recognizeable, I don't dare to compete with the likes of the Portal Gun. Also, I went to an interview for an internship at a large gaming company. I'll see how it went in two weeks time, but in the meantime, instead of counterproductively waiting, I plan to get at least some upgrades done, both mechanically and artistically. And, as always, a more detailed breakdown on the video in the rest of the post!

New gun HUD

My friend recently sent me a video (be advised, in Polish) saying "hey, maybe it could be of use". And as it turns out – it was. The video was talking about where the player looks during a game, how putting a diegetic UI in the center of focus (think: Isaac Clarke's suit in Dead Space) is a good design, since people look at the middle of the screen regardless, how peripheral vision is imprecise, et cetera. So I decided to implement those ideas, and put the most important parts of the HUD onto the gun. It's near the center of the screen, it's in focus, and if you want more precise data you can always look at the bigger bars at the bottom of the screen.

New weapon sounds & projectiles

The sound needed the biggest overhaul. So far, the gun sound was the default sound that comes with Unreal's default FPS template. Not a good long-term solution. The new sound also better fits my vision of what the weapon should be and what it should feel like. It's not a plasma cannon that sends projectiles that break sound barrier twice over. It's a fancy grenade launcher, and the new sound better gives that feeling away. As for the projectiles, their new shape is somewhat of a byproduct. I intended there to be an energy sphere inside a metal cage, but... Yeah, the whole energy sphere deal didn't quite work out. So I just applied the previous projectile material to the cage itself and left it at that. It's 100% a subject to change. I created new explosion particles too. Not as big, not as flashy, and don;t look like a party popper. I'm still not pleased with them, though. And with my particle making skills in their entirety, to be honest. Last change to the projectiles was new trail. The previous one was using the same texture the explosion was, so it also looked like the projectile was leaving a trail of ketchup&mustard-coloured confetti behind. New trail uses a different material, and it looks much smoother, however it's still not perfect. It's choppy. And if I try to make it any smoother,, I fear the performance hit will be significant. Nothing that cannot be solved, though!

New skybox

Not really a "new skybox", but rather "a skybox". The original scene had a default blue sky skybox, so I removed it, and was working with no skybox at all. But I'd like the levels to have at least some windows, so I had to make a replacement. Thankfully, I found Spacescape, an amazing, if a bit coarse, program that allows the user to create space skyboxes, with galaxies, stars, supernovae, all that good stuff. The current skybox is a slightly modified version of the one that comes default with Spacescape, but one day I'l make my own. With blackjack and hookers.

New gun design

https://gfycat.com/CloseChillyLeafcutterant

In my eyes, the highlight of this update. 100% original model and 100% original textures, created by yours truly. Finally a worthy replacement to the default Unreal asset. Does it look kinda plain? Perhaps. It should. The upgrades you collect are what will make it pop! You know how crazy Isaac can look in TBOI, and that's the goal. Just with a gun instead. So probably there won't be any tonsil stones or rag dolls. Or will there..?

Afterword

Life happens. And it hits hobbyist one-man teams especially hard.

But I'm back, and with a vengeance! New assets are coming! Upgrade system is all figured out! OneGun is slowly chugging along! In this post, I bring you a short video that demonstrates more or less what you can expect from weapon upgrades.

https://www.youtube.com/watch?v=BGsqZBR623A

Of course what you see is multiples of the same upgrade. It won;t work like that in the final game, I assure you. There will be much more than just two different upgrades, and you won't be able to find one upgrade multiple times.

Read more to see what's coming next!

What's next

I got new walls pretty much done, I just need to figure out the best way to implement semi-randomized textures, so no two panes look exactly the same. I tried it with all wall panes having the same texture. It didn't look good, believe me.

Next in line is new floor system. The glowy, circutry-ish texture will be hidden beneath tiles. Some of them – at random – will be loose and will have physics enabled. I only need to find the less laggy way of filling entire rooms with said tiles, automatically. I don't really want to spend hours placing floors tile by tile, room by room.

Then – weapon, character arms, and at least some upgrades. The weapon and character arms are all stock Unreal assets. And as such, they need to be replaced sooner or later.

Enemies...

Let's not talk about enemies yet. I'll need to read p on AI implementation in Unreal first, to be able to tell you how far with it I'm willing to go.

Afterword

All in all, everything's on the right track. A slow one, but a right one nonetheless. Expect more updates sometime soonish.

Well, it's been a while

Both since my last post, and since I originally uploaded the video. There's been some issues, not directly related to the game. First, my previous web hosting provider decided, that it's acceptable to have Error 500 thrown in my face for three days in a row, so I had to migrate the site, the DNS, all that jazz to a new provider. Thankfully, it seems to do the job just fine. Also, we were assigned group projects on my uni. And as it is common with group projects, it quickly turned into a solo project. That's why I've been kinda distracted trying to get everything to work correctly. But regardless, let's get to talking about the video! I've tried a new format, with added text, to explain what exactly are you looking at. Let me know how you like it. You can also notice some framerate issues here and there, and it's the fault of me running the game on the same process I'm running the editor. On a Phenom II X4 840. I assure you, that when you run the game standalone, it's butter-smooth.

Functional loading screen

Basically, exactly what it says. It's a loading screen. It tells you what exactly is being loaded, how many tries it took to load it, and a total elapsed time of loading. Currently, the loading times are at ≈11s, and they shouldn't get any higher, due to the way the spawing algorithm is made. Which is, in my opinion, acceptable. But do feel free to leave your feedback as well!

New HUD

Looks a little bit more refined, in my opinion, than the previous hud with boxy, blocky bars. The goal was to have the health bar move on an arc, as the shape would suggest, but to do that I needed a very precise gradient on that arc. And what do you know, Photoshop doesn't allow creating gradients that follow a path. My only option would be to create a linear gradient and bend it manually. However, this method doesn't give the precision I need, and would lead to the cut-off edge

being wavy, and a non-uniform progress of the bar. Still, something to overcome. Hopefully. Also, added a list of pickups you currently have to be in the bottom-left corner, and changed the font of all the text on the UI, to look  more computer-ish.

Diegetic weapon HUD

Not much to say about it, honestly. It was there already. The only change I made, was adding maximum ammo as well, and changing the font.

Loot chests

Same old, same old. Although I would like to make new models and textures for them sometime in the future. They look fine right now, IMHO, but not as fine and finished as they could. Their physics are hella wonky too. I'd like to fix that.

Doors

They close behind you when you enter the room, and open when you clear it. Couldn't be simpler. I also put glass in them, that becomes translucent only as you approach it. It's a nice effect I managed to create, and expect me to overuse it. There's a problem with that, however, since – as you'll be able to observe later – what you see through the glass is distorted. And not in a good, cool-looking way. Some objects simply become displaced when seen through it. I hope to fix it soon.

Minimap

Yes, it is wonky. No, it doesn't have the correct rotation. It will, though. It has to. Also, it's just a a picture that a camera hanging above the player captures, chroma-keyed to be translucent. I'm currently thinking of a better solution.

Shop

Just a green, glowing ball. It's just a placeholder, because I needed to see if it's even spawning. It is. In the future, it'll be a place where you can exchange your credits for other consumables, or maybe even buy upgrades. We'll see how it goes.

Treasure room

One per floor, will spawn a guaranteed item or upgrade. It does sound kinda generic, so I'll try to spice it up a little. Perhaps hidden compartments you can open with keys, that would hide chests or more upgrades? Perhaps giving you multiple items to choose from? We'll see.

Boss room

Red Cone can;t hurt you, but it also can't be killed. I kid, I kid. The bosses will be better, than a glowing red cone. They'll also give you an item when you bea them, and will open a path to the next floor.

Afterword

Or so it seems right now.

Ah, procedural generation, Oh how I love you, and how I loathe you. It’s a great solution ensuring that no two playthroughs will be the same. It’s a method that allows potentially infinite amount of different levels without the hassle of making as many by hand.

But right now I oh so wish I went with handmade levels instead.

Here’s all the iterations I went rhough, why they didn’t work, and what do I intend to do about it.

1. Raycast-based generation on a grid, using streaming levels as rooms

The idea seemed simple at first. To have each room spawn an actor at each doorway, and have them raycast in cardinal directions looking for obstructions. Then to have them spawn a suitable room based on where the ubstructions are, so no two rooms spawn ontop of eachother.

What went wrong

The raycasting is too expensive to be used like that. It caused a significant lag while generating the level. The raycasts, also, sometimes didn’t register hits, or registered them improperly, which resulted in one room spawning in the same space another room was already occupying. It was a mess.

2. Array-based generation on a grid, using streaming levels as rooms

An iteration on the previous idea. To have the locations that are already occupied saved in an array, so an actor that spawns a room can instantly check whether or not a position at 4000,8000,0 is free. No raycasting, all math and logic.

What went wrong

Setting up itself was a pain. Unreal Engine likes to de-estimate (is that a word?) angle and position values. So when I wanted something to be at an 180° angle, the engine was making it 179.9999972°. In theory, a difference that doesn;t make a difference. In practice, it makes an actor check if 4001,7999,0 is free. It is. But 4000,8000,0 isn’t.

In the end, however, it wasn’t this method’s undoing. I got it sorted out by using IntVectors and a custom function library I had to create.

So what went wrong?

The rooms sometimes refused to spawn. I was sending interface messages “spawn boss”, “spawn treasure”, “spawn shop”, but in the end only the treasure would spawn. Or the boss and the shop. Or any combination of these three.

According to people I’ve been talking to, the fault lies in using streaming levels, or more precisely – level instances being used as rooms. Apparently level instances aren’t supposed to be working as instances.

Go figure.

Besides that, this method would create issues with navigation volumes, and hence – AI pathfinding.

What went right

The levels that did spawn, were spawning correctly. Without any doorways opened to the void, without spawning on top of eachother, without doorways spawning into a solid wall of another room.

The generation was also reasonably fast, and didn’t lag the game as much as raycasting did.

3A. Array-based generation on a grid, using actors as rooms

Again, an iteration on the previous method. One of two methods I am trying to make work and refine right now.

Yes, I’m working on two methods in paralell. Thanks to that, I hope to avoid burnout, and maybe have two methods to choose from.

The only difference from the previous method, is that the rooms are created as actors, not as levels. In theory, it should get rid of the issues with spawning, as well as those with navigation volumes.

Problems

This method isn’t without fault, however. The actor editor isn’t really suited for creating levels, and it’s rather awkward to set it all up. Every room will take much, much more time than if I were to set them up as levels.

Besides that, this method requires me to use only dynamic lighting, since baking lights on actors is impossible. What that means, is potentially massive performance issues.

To add insult to injury, Unreal doesn’t cull those lights in such a setup. That means, even the lights on the other side of the map would be still taking up your GPU power. I’ll need to create some custom culling mechanic to avoid that.

Chances

If done right, the generation time will be near-instant. This setup will also allow me to manipulate the rooms in many more ways.

3B. Collision-based randomly scattered generation, using actors as rooms

An iteration on 3A method. The rooms are still set up as actors, with all the drawbacks it poses. However the rooms are not being generated one next to another, in a snake-like pattern (if snakes had branches), but instead, the rooms are scattered around an area, and corridors connecting them are being generated later.

Problems

All the problems method 3A had, unfortunately. Besides that, modifying the algorithm so that it generates only rooms with doorways facing inwards on edges of the spawning area, and coming up with a way of connecting rooms in a cohesive and sane manner.

Chances

As 3A, plus it would maybe make the level more interesting? Hard to tell. Methods 3A and 3B are basically “Binding of Isaac method” and “Enter the Gungeon method”.

Afterword

We’ve got ourselves a new website!

Well, I did, truth be told. I’m a one man studio after all. But speaking in plural does sound more professional, doesn’t it?

The Tumblr blog will still be there, of course, I have no intention of getting rid of it. Everything will simply be cross-posted between those two. This website, with me having access to its code, to every single little feature, is much more elastic and can be expanded upon. Which may be needed, were I to add a download for some early versions of the game, or other things like that.

That’s really it for this post. No major breakthroughs on the front of OneGun itself. I may have an idea on how to make the room spawning actually work, but I’ll need to run some math on that first.

See you in the next update!

This one is more of an update, really.

First of all, I finally managed to fix the issue with chests not opening. Turns out it was an issue with a random integer being randomized with every check on the algorithm, so when it was checking “is it 0? Is it 1? Is it 2?” the result could be “false” with each pass. Thankfully changing that if tree for a switch fixed the issue.

You might’ve noticed some changes to the UI as well. The previous setup was just a placeholder, now I’m really putting it together. Dodge bar on the bottom, not obstructing the view too much, ammo count and reload indicator on the gun itself for that immersive diegetic UI elements, health and shield bars are next for a revamp.

You might’ve also noticed the menu I called at one point. This one will display all the stats and items you have, as well as your weapon and all its attachments. Hopefully in a 3D interactable form, but... Unreal’s UMG is a bitch when it comes to putting anything 3D in there. So I’ll probably have to bruteforce it and make something like a tiny miniature gun with a tiny miniature UI be displayed in the world, in front of player’s camera. Oh well, what can you do.

This update I’m especially proud of the floor, though. How it lights up wherever the player goes. Truly a thing of beauty. To achieve that, I had to use some outdated screenshot from UDK, found in some obscure place, and contents of a NormalFromHeightmap function I had to gut. Whoever thought making it take only TextureObject and not TextureSample... I’ve no idea what were they thinking.

But, hey, it’s the end result that matters.

The level generation is... Progressing. The rooms spawn where they should now, but the only issue is that they seem to ignore part of the spawning algorithm. The part that prevents them from spawning on top of eachother.

Plans for immediate future include: fixing level generation, new material for walls, full revamp of the UI, and maybe starting to work on gun customization.

Today with less content and more plans. I thought it’s still worth noting both the progress and the plans, ad futuram rei memoriam.

Today no gifs, just me talking about short-term goals for OneGun (this name really did stick, didn’t it?)

Battling current issues

I still, for the love of me, can’t get the practice targets to reset on a push of a button. I know how to do it, it did work if it was just set on a timer in the target’s actor itself, but when it needs to be activated via external means? Not looking so hot.

Also, I’m trying to make a beam of a variable length as one of environmental hazards. In one of the previous posts you could even see it. It was initially achieved using a cylinder with no collisions, that detected when a player is overlapping it.

The problem with that solution was that the beam would have to have a static length and could not be blocked by, say, a crate. That’s why I opted for a raycasting method instead. And it works.

What doesn’t, is the particle beam effect, that passes through walls. I need to find a way to stop it at a location of the raycast’s hit.

Last but not least, I noticed that even when the health variable has a range of 0-100, being healed for 10 points when having 99 health will put you at 109 in total. Which should not happen. I need to find a way to fix it as well.

What’s coming in an unspecified future

First thing’s first, an actual, moving, attacking enemy. Maybe a futuristic Roomba with spikes for now, but something that actually moves, even if erratically, and can be destroyed.

Besides that, exploding barrels would be nice. I made one that shatters (it was shown in the last post), but I can’t get the damage dealing to work. Haven’t put much thought into it yet, though, so I’m willing to bet the solution is extremely obvious.

And maybe some better looking particle effects. They are a bane of my existence.

There are more things that need attention, for example connecting rooms in a randomized pattern to make a level, the gun customization system, or enemies with an actual AI. But I’d like to keep it simple for now. We’ll get to the more elaborate systems eventually.

Afterword

Not much has been done this week. To be honest, I almost forgot to post about anything that was done. Juggling game development and college isn’t easy, and it is taking its toll. Don’t do it, kids.

I managed to implement two little features, however.

Destructible Meshes

You shoot something, this something blows up and falls apart. That’s about it. I still need to tinker with physics settings a bit a lot, but it’s there and it’s working. More or less.

The barrel needs proper inner walls, as well as it has to damage the player. Some actual explosion effects would also be nice.

Beam Hazard

Just a simple beam, you may think. And you would be right. But it’s nice to have it.

The beam itself passes through objects, as you can see, but the damage dealt doesn’t. It’s all a matter of playing with the particle emitter, and somehow limiting its range. Can be done. Probably.

If you were to ever want to create such a beam yourself, remember one thing: raycasts happen from world location to world location. They’re not relative to the actor, they’re absolute in the world.

Afterword

I’m no longer entirely sure whether or not Devnote Fridays will remain a regular thing. I wanted them to be, I really did, but I thought about it and... I don’t think there’d be any point in making posts titled “I’ve done nothing thos week!”.

That’s why, from now on, Devnote Fridays will be happening if there’s something to actually show. I think. I don’t know.

Today a little bit earlier. That’s because I finished what I could, and what’s left is simply too time-consuming for me to start now. Making games until the first rays of sun start shining through the window? Not always the best idea.

Target Practice

Nothing terribly special, just simple targets to practice your aim. They react to hits, they have hit zones (headshots and bodyshots), and were created so I can have something to test any enemy-related mechanics without making actual enemies yet.

So far they only fall over, but a button supposed to reset them was created. Except it doesn’t work. And somehow interferes with the next feature I’ll talk about in this post, causing it to not react to player’s input. I may have an idea how to solve it, though.

The whole “doesn’t even reset what it’s supposed to reset” part, however? No idea. Yet.

Next step (after getting the reset to work) will probably be triggering some events when all targets are down. That’ll be a base for a mechanic of clearing rooms to progress.

Health Mote Spawner

Probably more of a test room/tutorial thing, than an actual in-game mechanic, but it can be easily customized. Buying health for coins, perhaps? A rare chance for the spawner to spawn in a secret area? We’ll see.

So far it does what it’s supposed to do. I had some issues making the “press E to interact” prompt face the player at all times, but I managed.

And now I’ll be abusing this newly acquired technology.

Expect prompts and popups following you everywhere.

Afterword

Come this Monday, academic year begins. My third semester in IT college. While it does give me opportunity to learn, and possibly create better things more efficiently with the acquired knowledge, it will be a significant hit on the amount of time I can spare for OneGun, no doubt.

There may come Devnote Fridays, when there are no gifs to show.

There may come ones where there is no text to write either.

It’s 4:38 in the morning here, but damn it was worth it. It just feels so good when you finally get the thing that wasn’t working to work. When you implement a feature without having to look at 17 tutorials on Youtube. When you feel like you’re making progress - both in the project and as a developer.

Here’s this week’s summary in development of OneGun. Still not sure about the final name, by the way.

Fire rate limits, using up ammo & reloading

For the longest time I was wondering whether the game should have limited ammo and have you rely on ammo pickups,or just have no limits allowing you to shoot endlessly. Eventually, I decided to go in the middle - your ammo isn’t limited, but you do have to reload. That will make balancing high-damage combinations easier.

Also, reloading, with its own, fancy meter. No, not really that fancy. The entire UI is a placeholder at this point. But it works. And that’s what truly counts.

And don’t look at that jiggling buzzsaw. It’s supposed to spin. It doesn’t, though. For reasons unknown. Beauty of developing a game, ladies and gentlemen - you fix one things, another one stops working.

Health pickups & a working HP gauge

Basically, this. Health pickups are now a thing, pretty fancy looking too, if you ask me. That means you’re no longer doomed to fail when you’re at 10 health, facing a room full of buzzsaws. They will be dropping from enemies and stuff, I may even add some fancy jiggling animation to them.

And, yes, the HP gauge that was a source of my misery finally works! And the error was the most stupid thing imaginable!

Who would’ve thought, that in Unreal Engine 1 = 100%, not 100 = 100%!

I’m not the only one who made that mistake, right..?

Right..?

Afterword

This week’s been rather tough, but it’s only going to get tougher. Especially when September ends and college starts. Even less free time to work on the project! Woohoo!

Update on a lack of an update

Basically, this. Not much has been done this week, at least not much that could be shown in a GIF or a screenshot. It’s been mostly me fixing messy Blueprints of already existing systems and trying to make my programmer’s art a little less programmer-like.

And me fighting with That One UI Bar That Just Won’t Show What It’s Told To Show.

I’ll be honest with you, I was uncertain whether I’ll have something to show today or not. Some of the things that now work work, even though I have no idea why, and some things don’t work, and I also have no idea why. Besides, smoothing faces in Blender screwed me over. Always export your *.fbx files as binary, with exported face normals. Just so you know.

But I do have something after all. Two and a half somethings, depending how you look at it.

Damage dealt to player

Yep, player can be damaged now. All damage taken is displayed in the console so far, but I’ll implement some better way when the time comes. Also, death screen. Not really. Just a widget that’s being created when health value reaches 0. But it looks cool.

I had to make HP a float instead of an integer, since ProgressBar widget doesn’t take integers. That lead to what you can see, health going into negative. It’s an easy fix, though, I just somehow overlooked it. Will be fixed Monday, probably.

Damage dealt by environmental hazards

You might’ve thought those two are the same, but you’d be wrong. Player receiving damage and responding to it is completely different from anything dealing damage to player.

In any case, there’s a template for some stationary, or maybe even moving environmental hazards that damage you when you touch them, so that’s done and waiting to be reused. Whew.

Still can;t figure out what the hell’s wrong with the cannonballs you can kinda see at the beginning. They act all kinds of weird, and I’ll probably remake them from scratch at this point.

Damage being displayed

The reason I had to make health variable into a float instead of a simple integer. And bane of my existence at the same time.

I’ve tried three different methods of displaying the HP of player on the bar. One of them was a step-by-step recreation of an official Unreal Engine tutorial.

It still doesn’t work, doesn’t show the HP you have until it reaches 0.

Oh well.

Afterwords

And here’s the first devnote post, after first week of the game being in development (I’m saying “the game” because I’m, honestly, still uncertain about the final name.

I’ll try posing every Friday from now on, even if I have nothing exceptional to report. I think it’s a good way to keep myself in check, as well as to let you know that neither me on the project is dead.

Some may say it’s too early for devnotes, but me, personally, I like the idea of documenting the game from day one. Plus I’ll try to talk through some technical details here, so if you’ll ever have similar problems with your projects you can see how I tried to solve them.

But let’s get to some of the features are now complete!

Dodging & Dodge Cooldown Meter

Hoo boy, was this one a bitch to implement... First I had issues with the character not moving at all due to friction, so I increased the launch speed to ludicrous amounts and it worked.

Too well, one may say. Were you to jump and dodge at the same time, you’d slam into a wall at Mach 10. The easiest way to fix it? Disable dodging while mid-air.

That didn’t solve the issue of being able to launch yourself from a ledge, or even a crate, though. What did the trick, was adding a timer which, when countdown of few milliseconds is over, runs a branch that divides the velocity values by 10 and adds some downwards velocity.

Thanks to that I was able to restore dodging while in air.

Shooting and projectile template

The essence of the game is being able to upgrade your gun to act in various... Interesting ways. To shoot bouncing projectiles, flaming bullets, explosives, and whatever my imagination brings.

I implemented an example projectile, how one of the combinations may look. It glows, it leaves a trail, it bounces, it explodes.

Explosion particles spawning wasn’t a breeze to make, let me tell you that much. The event that should run a graph when projectile stops didn’t work, in the slightest. Particle emitter, once spawned on hit, couldn’t be despawned...

What fixed the issue with not being able to despawn an emitter was taking a projectile lifespan time and feeding it to a delay node between an EventBeginPlay event and spawning a new actor on the last known location of the projectile.

Yes, spawning a new actor that had a particle emitter with explosion particles and a light attached to it. And it also had a self-destruction mechanism after a millisecond or two.

Huge shoutout to people from Game Developers League Discord server. I wouldn’t have been able to solve some of those issues without them.

Afterword

Coming next week (hopefully) player health and environmental hazards. Don't want to make any promises, but that looks like a sensible goal.

After much procrastination, countless trials (and errors), experimenting with various genres and ideas I present you my first project that is going public.

Codename so far is OneGun.

You have one gun, but countless upgrades to it you can find. Swap stocks, receivers, barrels, attachments and whatnot. Get various projectile effects - bouncing, explosions, fire damage, AoE aura... You name it!