Jeremy Winch

That's right! I'm starting a new project, based entirely upon personal interest that will most certainly negatively impact my GPA. This new function is creating a procedurally generated Unity Tile Map using Wave Function Collapse methodology. I aim to use this marvelous piece of software in other systems later in my career, so understanding the fundamentals now is vital.

My obsession began after becoming hooked on the 4X (eXplore, exPand, eXploit, eXterminate) mobile game, The Battle of Polytopia. This cute little war simulator is essentially a more digestible Civilization game. Most relevant, is the game's core feature of replay-ability by using a new procedurally generated map each game (see below). Each player's tribe has a unique set of influences that alter the frequency of each tile type. This creates a connection to their land, and makes venturing past the familiar natural land formations a daunting experience as unknown threats lie within the fog of war.

Polytopia map generation has 2 core tile types at play - land and sea. The above picture demonstrates the relationship they share: where land and sea are orthogonally adjacent, a coastal sea (light blue) tile is used. Within this outer hierarchy are many more layers of rules that will alter resource spawns in an attempt at a fair player experience.

These colorful maps are all the result of the Wave Function Collapse formula, which is what I hope to imitate.

My current progress is what inspired this blog post. A clear and detailed Unity tutorial by Sunny Valley Studio is teaching me the first few steps of this algorithm. Using episode 12 of the tutorial, I have created an algorithm to recognise distinct tiles in a map. From this stage, relationship patterns of each tile will be analyzed to help create an entirely new tile map.

The algorithm has indexed and returned the tiles as the center of the grid, starting from the bottom left: [5, 6, 6] [3, 0, 5] [0, 1, 2] As shown, the pair of 'path ends' and 'forest' tiles have the same index. The outer edge of numbers are predictions based on the inner tiles. This will be useful in later episodes, I'm told.

The updated One Page design is a significant improvement. It follows design philosophy set by the example One Page. Clear indications of this include detailed sections for each item, varying font styles per item, labelled pictures, and suitable whitespace. It was created over the course of 4 hours using image editing software Krita for the background and level designs, and Microsoft Publisher was used to layout and create content. I have sufficient experience in these programs from other units, so the process was smooth. The most difficult aspect was finding a useable photograph for the gameplay image. Playing the game is a challenging task in itself - playing the game to create a specific set of circumstances that displayed all of the needed content was a nightmare. This is shown in the previous two posts, as I was unable to create a video showcasing the full game because I would die pre-completion every time. The game is fully functional of course, I just couldn't prove it through 1 gameplay session.

This mess of a document is my One Page design document. It focuses heavily on the Player mechanics, as this is where the majority of my focus during development was. This led to ambiguity in other areas such as win conditions and gameplay loop. It appeared the marker was not a fan of my visual communication skills either, as the phrase "bad fonts, small text, nothing stands out, pictures blend in with the background ... really unappealing" genuinely appears in my feedback. To be 100% honest, this was expected. My time management was stretched too thin from incompetent group members in a different unit, resulting in me only being able to spend 12 hours on this. The low marks received for this assignment were balanced by more marks from the other unit.

Upload has been mostly completed now. The development highlighted the importance of planning ahead, and using plug-ins to improve designs. Firstly, the Track made of a gold outline and filled with translucent grey, was overall a big success. It is made of tiling sections, such as straights, curves, and various intersections. The sprites made in Krita took a lot of time, despite their simple visage, due to the need to ensure everything aligned properly. The few gaps in the track are precision errors in GDevelop, not an error caused with the sprite. As the track is made of many straight lines, this allowed for the edges to have tangible hitboxes. Should the player hit them, they will bounce off in the opposite direction. This combined the limitations of my Krita art capabilities, as well as GDevelop's hitbox configuration, and resulted in a coherent design.

The trail plug-in (known as Animate Shadow Clones) provided excellent for my purposes. My original fears that I would need to script each box to follow one-another were quickly assuaged when I understood the potential this brought. In fact, it can also be seen in the Assessment 3 game, GrappleMania!.

Being creative with the Tiled Sprite background also brought forth the Matrix inspired black and green scrolling code. It can be rather disorientating when moving at the same speed, but I personally feel that this adds character to the game.

The Boost pads also acted exactly as I wished. Their increase in speed, combined with the Camera Zoom Out (lerp) gives the player a rewarding feeling for taking them. It is also satisfying to watch the trail spread behind the player as it simulates a rudimentary physics system.

GrappleMania!'s content updates have been coming smoothly. A cute main menu has been made that leads to individual games. This was made using the help of a tutorial by Wishforge Games.

New UI such as a health bar and speedometer were also created. They update based upon the Players current health (as a percentage of max health) and the Players speed.

This video shows the extra features, such as the health bar interactions with missiles and health pickups. The trail produces smoke once the health is below a threshold percentage, and the speedometer accurately displays the players current speed.

The chosen game for assessment 3 is Grapplemania!

Things to make the Gem run fun: (these are divided between group members

Things to avoid (Remove Health)

Asteroid objects

Shootable (power-up)

Jetpack Joyride missiles

Anti-air explosion 

Power-Ups

Shoot asteroids

Invulnerability (bounce off walls)

Score multiplier

Health-pickups (rare)

Mini-plane

Maxi-plane (not good)

Massive speed up (not good)

Different Maps

“Plus” Shape

“S” Shape

“4-side” of a dice

Robot Face

New UI

Warning signs

Health Bar

Change plane UI (or add smokey trail)

Speedometer

Trail

Death Screen

Victory Screen (if campaign)

Game Modes

Arcade

Random map

Collect gems til death

Campaign

Set map order

Collect set number of gems

Sounds

Hazards

Losing a life

Shooting

Pickup Powerup

Gem collecting

Screens

How-to-Play

Menu screen

Reading's Used: None Things to change about the development process:

GDevelop has a comprehensive package library used to speed up development of generic games. Using the Platformer library this time was very useful for quick progress, though it didn't teach me much. Whether this is relevant or not will not be known until I need to make a platformer game without the use of the library.

Otherwise, the sprites were inconsistent between objects - the initial post can be seen to use low-pixel count images, compared to the later ones. This is a result of poor planning AND my skills developing. In the future, the scale of all pixel art images should be consistent, as well as use a standard colour palette.

First sprite made - low pixel count

Reading used to help the design process: - Brainstorming tips (Page 172) - Mechanics inspiration (Page 8)

The grapple mechanic was inspired by the 1989 Batman's batmobile, in which the vehicle uses a grappling hook to make a tighter turn. This mechanic has also been seen in the mobile game Slingshot Racers.

The total time spent developing the mechanic was probably 12 hours in total - not including the art or game design. This long development time resulted in the final game changing from an endless running simulator, similar to Temple Run or Subway Surfers, into a standard and simple gem collecting clone. I was disappointed to see this become a necessity, but compromise is an evil part of this business.

This video briefly explains how the trail works for the character of Upload.

Elements created:

Movement: - A/D keys turn Left/Right - Trail follows frame amount behind player - Speeding up lengthens trail Boost: - Temporary speed increase - Lerps back to normal

Main sprites created: - Character - Background - Boost

Elevator Pitch

Players are a data packet that needs to race to the memory before the connection ends. They must navigate through a tube with branching – though linear – routes. Speed boosts in the form of directed wires may help against the ever-increasing glitches to avoid.

Art Style:

Drawing upon themes from The Matrix and other Computer Science Fiction, this art style is to be vector based, with a strong focus on binary digits. The colours will be neon, bright, and contrast sharply against the black background. A digital trail of binary will indicate the path of the player through the levels.

Mood Board:

Control Diagram:

Display of movement mechanic of my Asteroid's game Grapplenauts! The right mouse button sets the pivot point for the ship, holding it will move the ship. Importantly, the ship arc size will change depending on the distance to the pivot, giving players control over how tight a turn may be. Stats in the top left: 1. Mouse coordinates 2. Mouse distance to ship 3. Angle between mouse and ship