DEV Community: Isabel Puustelli

Complete game development blog #3: Long time no see

Isabel Puustelli — Wed, 05 Jul 2023 11:25:50 +0000

Last summer came and went, and when school year started all my personal projects screeched to a halt. Now that summer break is here again I have started to work on this project specifically with great ferocity. Such great ferocity, in fact, that I haven't had the time to do any updates! So here's a big post of all the changes I've made in the last month or so.

Visuals

I always wanted the visuals to be first and foremost simple and easy to look at. The less clutter the better. Well, I thought, what game has less visual clutter and more clarity than chess! So I opted for the characters to be represented by chess pieces. The pieces themselves don't have any differences in how they work yet. That's for the design phase. As for the color theme, I went for a monoramp palette of dark blue and purple at the dark end, and off-white at the light end.

Animations

I have done a lot of placeholder animations to make things look a little nicer. This post will already be a little long so I will keep this rant short, but a lot of systems in unity that are necessary for this project are not great. The animation system is one such example. The new animation system has been in place for ages, but the legacy animation system is still there. I'm not gonna make claims, but it feels to me like this is because the new system is still, after all this time, lacking in some things that can only be done with the legacy system. For example, if you want to do a small animation, like moving something a short distance, you're better off with the legacy system, as the new systems api doesn't support you doing this completely in code. With the old system it's gonna be one component and about 5-10 lines of code. With the new system you need to have the animator, animation clip, add the clip to the animator hierarchy, point the arrows and set the parameters and then enable the animation with a few lines of code. All for an animation that lasts a second. This leads to a frustrating duality where you're sometimes doing the animations in code, sometimes not, and remembering which is where gets annoying. Rant over. One day I'll make a post all about the cursed tile system, that made making some of these animations genuinely take days.

Aiming and shooting

This system honestly has so far come out better than expected, even though a lot of it is still placeholder. The cone represents the area in which the shot may land, and if a piece is within the area, its health bar will blink with the amount of health it might lose, were it to be hit. I'm planning on implementing more weapons with different amounts of spread. For what I'm planning though, I want to keep randomness to a minimum, so a spread like this would be very uncommon. I would like for the spread to only really be relevant if shots are taken from great distances, or the weapon is using for example buckshot rounds.

Miscellaneous

Fog of war is another system I just finished half way implementing, whatever that means. This would be another chance to spend ages complaining about unitys tilemap system but again, trying to keep things short.
Some less interesting things was that I cleaned up a lot of the scripts and made their order a lot cleaner. This is a problem that comes up when you're designing and planning the game while you're making it, but with personal projects I like to follow the mantra of "Messy code is still better than no code at all". This means that if you get bored or frustrated while planning a project, so much so that you don't get to even making it, you're doing it all wrong. You just need to get to doing it, and then fixing it up later. Since it's a personal project after all, you got all the time in the world!

Complete game development blog #2: Pathfinding and distance calculation finished

Isabel Puustelli — Sun, 17 Jul 2022 11:31:11 +0000

Sometimes it's good to be humbled and reminded that you need to take a brake and really look at what you're doing from the outside in.

So I had finished my amazing idea of not having to do the calculations for the movement distances for my characters, since I was using the A* Pathfinder and thought I could just use the distance it calculated. And it worked, but the numbers seemed off. Traveling sideways doubled the distance compared to traveling straight up. I was racking my brain on this problem for the longest time until the obvious hit me.

My game is isometric. The pathfinder is not.

This image shows how the pathfinder calculated what tiles were inside a certain distance. It looks all well and good at first glance until you realize travelling vertically you can go up 3 tiles, but horizontally only a single tile! The pathfinder doesn't know or care what perspective the plane is under it, it only knows it exists in 2d space and that it needs to go from point A to point B through a grid of dots, while avoiding any obstacles.

This is what I didn't realize I wanted. A circle existing on the isometric plane.

Luckily it wasn't a difficult fix. The pathfinder provides a list of points it goes through, so it was as simple as converting those points into tile coordinates and applying a little bit of everyone's favorite theorem from high school.
After adding all the parabolas together you get the correct distance.

PS: There probably could have been a way I could have set the grid of dots the pathfinder goes through to be isometric, but that's for someone else to figure out, this works for me.

Complete game development blog #1.5: Pathfinding

Isabel Puustelli — Fri, 10 Jun 2022 18:49:35 +0000

I was about to start implementing the movement system I talked about in my last post, but once I remembered I needed some kind of pathfinding for tiles that are around corners, I realized I could get two birds with one stone.

First things first I want to shout out someone who is a lifesaver to all 2D unity developers. Aaron Granberg made an amazing opensource project called the "A* Pathfinding Project". It's such an amazing, simple, easy to understand pathfinding solution for unity games, especially for 2D since navmesh isn't an option. I toyed around with the idea of doing A* pathfinding on my own, but making a game on you're own is enough of an undertaking in and of itself so any outside help is always nice.

So back to the shortcut idea. Since i had to implement pathfinding for obstructive objects and walls, i might as well use it for all movement. Since i was going to use the circle method, I could use the pathfinding to find out whether a tile is inside a certain sized circle or not. The simplest way to find that out, is to know if the tile is closer to the player than the circle's radius. So i simply compare the path length to the players movement range. You could say this is a bit of a twisty way to arrive at a very simple solution, but I had to make sure it's balanced in the way I wanted it, and I'm happy to say, it is. And this is what it currently looks like.

Complete game development blog #1: Movement

Isabel Puustelli — Mon, 16 May 2022 17:48:25 +0000

Some outlines that I already know about the game include the gameplay loop, which will include the strategic overview where you manage resources and soldiers, and the tactical on-the-ground gameplay. I also knew I wanted to start with making the tactical side first. And with that I started developing the character movement. This is what I initially threw together.

Which immediately imposed a design question that I was not ready to answer. Diagonal movement. Let me explain.

This is currently how the movement looks from a top down view, if a character can move 3 squares. The problem here is that diagonal movement is extremely slow. It takes twice as long to move diagonally. Let's look at a potential solution.

This is the system that for example Dungeons & Dragons uses. Have diagonal movement cost the same as horizontal and vertical. This of course makes it simpler to count movement in a tabletop setting, but flips the problem on it's head. Now diagonal movement is twice as fast as horizontal and vertical. Better in my opinion, but still rubs me the wrong way. There was one last solution I had played around with in my mind, something like a circle within which a character could move. And sure enough, I wasn't the first one to have this idea.

https://www.redblobgames.com/grids/circle-drawing/

After stumbling on this blog post by Red Blob Games, I knew this is the solution I want to go with. It too like everything, is not perfect, and leaves some design questions to be answered. Is a tile able to be walked on when the circle hits its edge, or when it's center is inside the circle? Should the radius of the circle be X amount of squares, X amount of squares + ½ square, or can it be something in between.

Regardless, I feel this is the best solution for balancing movement in all directions, and won't feel frustrating suddenly when you need to move diagonally and your legs feel like they're halved. Next, of course, comes implementation.

Git: https://github.com/PuustelliJoona/ufo-defence
LinkedIn: https://www.linkedin.com/in/joona-puustelli-aa031b23a
Dev.to: https://dev.to/puustellijoona

A complete game development blog #0: Project UFO defence

Isabel Puustelli — Sat, 14 May 2022 15:29:32 +0000

To get straight to the point, this is a hobby project idea that I have been toying around with for a little while, that I'm finally hoping to bring to fruition. I've had many a project that have fizzled out after the first few weeks, so now I'm grabbing the bull by the horns. I'll document every bit of progress on dev.to, and store it all on git to keep myself glued to the project.

The Game

So far the game has simply been called "Project UFO Defence". You guessed it, it's inspired by the original XCOM from the year 1994, "X-COM: UFO Defence". I feel It's a style of game that hasn't really been recreated. Obviously I'm a big fan of the reboot franchise, but I just feel something about the game significantly changed bringing it to 3D, something that I'm hoping to put my twist on. I haven't done much designing yet for the game. I'll get on this as soon as the base systems are in place. It'll be a lot easier to design a lot of the systems and make changes once you have a feel as to how the game looks and plays on the very foundational level.

So this is the starting point:

The graphics are all free to use recourses from sites like opengameart.org that I slapped in for testing purposes. I haven't ever worked on an isometric game before so tiling it was interesting. I'll see in the future how I'll do the sprites, I might have to try my hand in making some artwork, who knows.

Git: https://github.com/PuustelliJoona/ufo-defence
LinkedIn: https://www.linkedin.com/in/joona-puustelli-aa031b23a
Dev.to: https://dev.to/puustellijoona