City Builder Construction System

Uncategorized

City Builder Construction System

One of my dreams to create a strategy and/or city builder game.  I often work towards this goal in small bursts, learning how to create the systems necessary to make such a game work over time.  The most common system I experiment with is the actual placement of the buildings themselves, which involves raycasting to a position in the game space.

My most recent attempt at creating a building placement system was inspired by the game Majesty: The Fantasy Kingdom Sim.   In Majesty new buildings are placed with a ring of detection.  If another building is within that ring of detection the new building cannot be built and must be placed elsewhere

 Below is an example of this:

Invalid Building Placement (too close to other buildings)
Valid Building Placement (far enough away from other buildings)

Below is a video of my system.  I think it pretty accurate to the one that is used in Majesty.  Each building also uses a Scriptable object o hold specific information about each building so that designers/collaborators could easily make new buildings or change existing ones.

The placement system in the video works as follows:

The system uses a raycast to find a valid location which requires a collision with an object on the Ground layer of the game.  Once the raycast collides with a valid target, that collision point is taken and a projection of the new building is instantiated there.  The building will move around as/if the raycast changes position.

When the new building starts being projected a ring is also projected visually, however, in actuality a sphere collider is being created.  The sphere collider’s radius is equal to the ring’s radius and thus captures the same area.  The sphere collider detects for collisions of other buildings (which should be on a layer called Buildings).

If the sphere collider does not detect any other buildings in its area then the building can be placed.  The building is then deselected and the projected building becomes invisible.

If the collider detects another building in its area then the building is not placed and the player is given another opportunity to place the building.

The current scriptable object I have has a couple of parameters that makes instantiating and tweaking the buildings easier for the placement system.

Obvious fields are name, and height offset (so the building does instantiate partway into the ground), but the Placement Col variables are what set the detection ring’s size while the Col variables set the actual building’s collider.

A few more additional variables I added to the Scriptable objects is the ability to add a mesh, which allows for quick aesthetic changes to the buildings and a Material that should allow the buildings to look different once built if the I so choose.

Blog Posts Update

Uncategorized

Blog Post Update

Hello blog post readers.  I has been awhile since I posted and for that I apologize.  A lot has been happening so I’m going to try and post a little more frequently in the next week or so bring you all up to speed on what I did during my gap.

A quick announcement is that I’m starting to stream on the website Twitch!  I don’t have a confirmed schedule yet, but I’ll be alternating playing games and doing game development.

The games I’ll be playing will be a variety, probably smaller games that I enjoy (sometimes bigger games).  

For game development I’ll mostly be working in Unity at first, but will branch out into Unreal or other game engines.  Development streams should consist of programming and design, with a splash of art when I need custom assets.  Hopefully anyone curious about game development can catch a glimpse or maybe learn something from my streams.

I’ll put a link to my Twitch channel below so you can follow me if you want to see what I am doing.  I’ll be making  matching blog posts whenever I do a game dev stream explaining what I accomplished and what I want to do next.

The next bit of my blog post will be showing you what kind of blog post topics I will be posting in the week or so.

The following topics will make an appearance:

  • Majesty/CityBuilder Placement
  • Shadergraph Experiment
  • MonkeyByte Monster Hunter Recreation Pt1

These posts should be up next few days though not necessarily in this order.

That pretty much covers it for this blog post.  I will see you readers next post!

Ladder Coding/Prototype

Uncategorized

Ladder Testing/Prototype

I messed around with a first person controller and building a ladder.  The first person controller was based off a Brackeyes video and I created the ladder off of that base code.

The image to the right is the Unity Editor view of the ladder.  Its has two colliders attached to it.  One collider is used for physical interaction with the ladder such as standing on top and preventing the player from running through it, while the other collider is for detecting when the player is in range to start climbing. The larger collider is the one that detects whether the player is about to start climbing.

Right now once you climb the ladder you can’t back up off the ladder, but I think that should be simple enough to do with a small change to the ground check system that is currently implemented.

Personal Project: Sword Director Intro Post

Uncategorized

Sword Director Prototype Intro Post

Prototype Prompt

I got the idea for this prototype form watching the Castlevania show on Netflix.  I was watching Alucard fight using his sword.  I thought it was really cool how it moved around on its own with only a few directions from him.  I thought that would be a cool experience for a player.  Manually fighting while simultaneously directing another entity.

Current Progress

I worked on a rough prototype for a few days in the Unity Engine.  This is my first time using Unity’s new input system so it has been a bit of a learning experience.  Right now I have a few of the core features I want in the game.  Movement, jumping, and launching/recalling the sword are all functional.  Jumping still needs a little bit of tweaking, but it still functions as a jump.

Current Issues

My biggest issue right now is getting a system in place to allow the player to create a series of points in the level that the sword will pathfind to.  I have a some code set up that should work, but the input system that’s set up right now does not have enough bindings.  Right now the input button for marking a location for the sword’s path is a continuous hold and not a single frame.  This means a new point is added to the path every frame, which gives the player very little time to decide what direction they want the sword to travel in.

Next Steps

The next step for this project is to redo the input system bindings.  I need more options for button presses in order to test and create good control schemes.  Once the new control scheme is taken care of I can move onto making the sword pathfinding work.

Flow Fields in Unity Engine

Uncategorized

Flow Fields are a version of pathfinding that don’t construct a single path from the agent’s current location to a target location, but instead creates a path across an entire grid. Flow Fields are broken down into three parts. The first part is is the cost field. The second part is the integrations field and the third part is the titular flow field.

The Cost Field holds the values of all the tiles in the grid. Typical these are held in some sort of 2D array, map or other data structure that have a key and a value. Having a key value pair allows for easy access of values based on a tile ID or some other kind identifying value. These values will be used in the calculations in the Integration step.

The integration field is where the most pathfinding happens. Here the algorithm becomes very similar to searching algorithms like Dijkstra’s and A*. We have an open list and a closed list which are used to keep track of the grid tiles. The open list is used to keep track of which tiles we have to visit and the closed list is kept to tell which tiles we’ve already visited.

Before the Integration process starts all tile’s cost is set to a large number. My examples uses 100, but as long the number is big enough that the costs will not add up to it you should be fine. Then the endpoint tile’s cost is set to zero so that it will always be the center. Once the Integration process starts the endpoint tile is is added to the open list. The algorithm then grabs the top of the open list (the endpoint tile) and looks at its neighbors while also removing it from the list. Each neighbor tile then has the original tile’s cost and its Cost Field Cost added together to create a new cost. This can be done using the tile’s cardinal (with diagonals) neighbors or using the tile’s orthogonal(no diagonals) neighbors. If the new cost is less than the neighbor’s current cost (the large number we set it to at the beginning) then it is added to the open list if it is not on the closed list. After all the neighbors have been looked at then the original tile is added to the closed list so that we don’t look at it again. This process continues until the open list is empty signifying that there are no more tiles left.

Once the Integration is done we then go to the Flow Field process. The Flow Field then iterates through all tiles and looks at all their neighbors to find the one with the lowest cost. Once it has found the lowest cost neighbor it computes a directional vector that points from the origin of that to its lowest cost neighbor. My example stores this directional vector in the tile itself, but you could also store it in another grid of vector values so long at it is the same size as the original grid. Once the this part is done the Flow Field is complete and units can read directional vectors in order to path find to the target location.