#Tilemap Set

[fmp2rubix1786]

Tile Map/Tile Set.

This is a video, showcasing a playtest of me playing my game with added artwork of the tile map and tile set.

[prokopetz]

Folks tend to talk about fidelity in retro game visual design in terms of adhering to the limitations of particular consoles, but I think keeping in mind where they weren't limited is at least as important. When a console could do something that previous console generations – or its current competitors – couldn't, its developers tended to want to show that off, and while these effects are often thoroughly unremarkable to contemporary audiences, they're a big part of each console's distinctive "feel". For example, the NES only had one tilemap plane, but it could decide whether to render sprites behind or in front of it on a per-sprite basis, so you get a lot of games with complicated set-piece levels where the player character walks behind a foreground object. The Super Nintendo, conversely, could do multiple independently scrolling tilemaps for not a lot of resoruces, so Super Nintendo games that are trying to wow players with their visuals love themselves some multi-plane parallax. This sort of "hey, look what we can do" showboating is just as essential to a console's visual identity as having the right number of entries in your colour table.

[parallels-omorimod]

parallels - an omori mod

based on the fic of the same name by FruitDragon and Biggie Cheese

Mod Synopsis:

Set four days after the events of the true ending, when another tragedy strikes. The demo/the beginning of the mod (target release in February) is the prologue. In the prologue, you play as Hero, who had gone back to his post-Mari’s-death ways of grieving after Sunny’s confession, but doesn’t want to be like that anymore because he knows how that ends. So he wakes up and gets out of bed and plans to go to the hospital where Basil and Sunny still are to apologize to them for how he reacted. He looks for Kel to go with him, since Kel might also want to visit.

But Kel is nowhere to be found.

Contributor Applications

Contributor applications are open! We are looking for artists, NPC writers, programmers, tilemap makers, tileset makers, musicians... a lot, really! Feel free to apply! If you apply, join the Discord server as well.

Discord Link

You don't need to apply to join the server, though! The link is below.

[omeletcat]

ALLRIGHT i made another little timelapse!!! this is honestly very nice, idk if this will perform better then just posting the results but since it is a tilemap and not like.. a full drawing this gives off more the time i have spend on this art!

Anyway basicalyy a tilemap is a set of tiles that i can place around to make a map for my game, but the problem is that it needs to be compatible with all the other sides and stuff, so i gotta try rly hard to make sure it looks good on every side, against every other tile so it won't be fucky when i am finished!

[sketchysphinx]

Yesterday godot exploded my mind with it's tilemaps, they're op. You can store information inside them (values, dictionaries collisions and etc) and call it via script, it even can add simple physics to the chosen tiles, I made a 2d conveyor belt with just tapping settings, no code at all. All I did is went to the tileset settings and created a physics layer, which gave me possibility to enable collisions and just draw colliders inside a tileset instead of adding them manually (the tileset I made is super specific in shapes), it also had values for speed on both X and Y axys.

I wonder what else godot has, it's like exploring a cave with treasures everywhere 👀

[nitrosodiumrapidproto]

Proposal for my new Project

Having now made all three of the “tutorial” games, I have been able to make an educated decision on which will be the most interesting and rewarding to develop. I have chosen the dungeon crawler, as I believe it has the best potential and ability to be innovated on. The infinite runner is something I have done before for Sweat Pursuit, and the block breaker is a very rudimentary concept gameplay-wise and something I am not interested in. Meanwhile, the dungeon crawler is immediately a multifaceted idea with elements of exploration, combat, and strategy interwoven. A lot can be added to this basic framework, including more complex health and ammo systems, AI for the enemies, and interesting level design and emergent gameplay in terms of problem-solving and combat puzzles. The top-down perspective is also something I have not yet really tried, which will require new artistic solutions to make assets for.

The current name for the project is “Accursed Crucible”. It will take place in a fantasy setting; specifically, within the titular Crucible, which is an ancient forge overrun with fell creatures. You play as a lowly dwarf armed with the Hammer of Heaven, a holy weapon that can banish the evil and purify the Crucible. Lore-wise I have some basic ideas; that the Hammer was created in the Crucible and is naturally drawn back to the place from which its metal was first poured. Forging its own destiny, as it were. The artstyle and sprites will likely be 16-bit, since smaller sprites take less time to draw, but I don’t want to make them too simplistic. This should allow a level of detail to be retained roughly on the level of a Terraria or RPGmaker NPC. The enemies will be typically evil fantasy creatures: orcs, undead, liches, and similar things. Lore-wise they have taken over the Crucible to forge their own holy weapon and wreak havoc with it, and of course the powers of heaven cannot abide that, so they have sent you as a sort of dwarven messiah. The combat will be as simple as it was in the dungeon crawler tutorial – move away from enemies while shooting your hammer’s projectiles at them. Strategy will be added by having to manage your own ammo; staying alive and out of danger while finding more. This then incentivises exploration when it would have otherwise been unnecessary beyond finding the exit.

I plan to go back to basics when it comes to the art assets for this game. I will use Photoshop for both character sprites (i.e. the dwarf and the enemies) and also for the tilemap. In-game most things will be paper flipbooks, as they were in my first project, Toxic Waters. Then Unreal is the obvious choice for development; though other things are available like Unity or Roblox, I see no benefit to using them for this, especially when my original dungeon crawler code is on Unreal anyhow. There will not be any new techniques this time, I think.

Here is a MSCW (Moscow) analysis of the project:

Must Have - Some nice spritework, health + ammo system, multiple enemy types

Should Have - Notes with lore, high score system, locked doors

Could Have - Chests with randomly generated loot, immersive-sim elements such as choosing to bash down a door at the cost of ammo, using a rare lockpick to open it, or searching around for the key

Won't Have - Multiple weapons, arena-locks

This week, I plan to lay the groundwork for the project, which is mostly gameplay. Health and ammo, enemy detection, more enemy types, ammo and health pickups, et cetera. If I have time, I will make sprites for everything, including the tilemap. How I will make the map I am still not sure - maybe a tilemap pointed upward with collision boxes to bulk out the walls?

[saladsquid]

Ant Empire Rising: Food System, Environments, and Ants!

The first AER Tumblr post! These will be large progress updates that show off what I've been working on for the game as of late.

If you missed it, check out my previous post, or the TIGForum devlog for more information about what Ant Empire Rising is. In short, it's my indie ant-themed RTS video game. Passion project!

Today, I wanted to reveal the current food system, PLUS the newly revamped art of the field map Hills & Pits and some previous work on the ants themselves. Lets get into it!

Food System

Let's start with a treat; the food system! In the game, food is the main currency and you need it to make more ants and sustain the colony as a whole.

There are two main components to the system; the Queen Hunger bar, representative of the ant queen's own survival, and the Food Storage bar, representative of how much food you have. There is a maximum amount of food one can have, which is dependent on your colony's population. The more ants you have, the higher the maximum is.

Over time, the Queen Hunger bar drains. If the Queen Hunger bar is at 0, the colony dies and you lose. How to keep this from happening? Collect food! The hunger bar increases when you have food, slowly taking from the stores to fill itself. When your food stores are at 0, the bar starts draining.

It's a simple system, but with the right balancing, it can be a challenging one. I'm still working on getting the right balance for how quickly the bar drains, among the other variables, like max hunger and how much you get at the start (right now, it's half).

Queen bar in red, food bar in green

So, in essence, you NEED food for survival. How do you get it?

Collect it from the map! Currently, there is only one food type to collect; seeds. They spawn infrequently across set points around the map, plus there is plenty of seeds to collect at the start of the game. There's also a fun new feature called randomized food; the food that spawns at the start is randomized instead of set.

There are different types of seeds to collect. Right now, there are three types: wheat seeds, sunflower seeds, and milkweed seeds. There will probably be more in the future.

Wheat seeds currently give the least food. BTW, to collect food, you just need your ants to collide with it!

Better Biomes

The first, and currently only, map in the game has gotten a bit of a revamp! Hills & Pits, set in a Mongolian field in the middle of nowhere, though it looks more like a desert, USED to look like this:

There's nothing really wrong with this look tbh; you get used to it. It's a simple design that can still offer a lot of variety in playstyle. However, it's not necessarily cut out for what it's supposed to be, which is why I gave it a remaster with some new art that I personally think looks a bit better:

Hills & Pits 2.0!! It's still a bit janky, of course, but that's to be expected.

The land is no longer shaped like a square but has a more dynamic outlining; there are gravel patches around the map with unique assets; pebbles and tiny bushes are scattered as small props.

Plus, the new map uses a better system than the old one: tilemaps. They were implemented into GDevelop (AER's game engine) a while ago, but up until a few days ago I had just been using classic sprites. Tilemaps makes things a LOT easier though, and because of that I can finish up on maps much faster now.

All told, it's a better implementation for the long run.

Ants & UI

The Ant HUD in-game has changed a bit from it's last appearance:

Old vs New

The new version is a lot better, for a couple reasons; firstly, I managed to shrink it, which was a pain to deal with but made it less obstructive during gameplay. Second, there is now space for two more additional castes, one that can go above ground and another that stays below ground (like the queen).

And of course, it's just better looking, at least in my opinion.

In case you're wondering, each 'aa' is a text box that can robustly change depending on what I need it to say. From left to right, they are: "Z", "X", "Queen" "Worker" "Soldier" "1" "2" "3".

Z and X are hotkeys for zooming in/out and 1, 2, 3 are hotkeys for waypoints. They'll probably be replaced by something else in the future but it was the easiest way to communicate these things in this early of development.

Next Up: The General Stuff

So with those new features and whatnot, my next plans are fairly simple; I want to finish development on black garden ants (the first ant species) and add customizable hotkeys.

For BGA, they need a lot of work on their animations in-game and adding their stats. For hotkeys, it's mainly so I can remove them from the Ant HUD and put more practical features there.

I also technically need to finish Hills & Pits but that won't happen for another week or two. After that, I'll move on to enemy creatures, technical stuff, and then the first demo of the game!

See you all around in the future,

-saladsquid

[cyberninjax3648-studios]

Some CyberSouls editing

I decided to get working on CyberSouls, because of it's stronger connection to FIREWALL. I noticed that the most of the art, excluding UI and character sprites, didn't look as good as it should be. Also, utilizing my original decision to make jumping small and realistic, I erased the original map and began placing it down with the idea of a kind of metroidvanian concept, but some places are reachable only because of better jumping or wall-running.

You may remember seeing some of the CyberSouls project from my post on experimental projects. If you haven't, well, CyberSouls is to become a horror platformer and being the spiritual prequel to FIREWALL: Cyber Defense. In fact, it is based in the building seen in the BACE Scene. It utilizes on-character UI, darkness and realistic jumping. Although also includes unrealistic wall-climbing.

I decided to start with the tilemaps, making it so that the tiles are each individual and don't depend on each other to make the map look good:

Also decided to get rid of the font and gender settings. The font was taken away because it was redundant and would get confusing. The gender setting was taken away in favor of making the protagonist, Alex Harlen, a more solidified character over simply a player character.

Also we needed room for SFX setting anyway.

Well that's all I got for now. God bless y'all.

[f0rt1e]

Devlog #1 | Major functions prototyping

Today, I'm excited to share a closer look at the nuts and bolts of my indie game development journey—specifically focusing on two pivotal aspects: building and pathfinding. As I've been piecing together my medieval city builder, figuring out the best ways for players to construct their cities and navigate them has been both a challenge and a revelation. In this post, I'll walk you through the different approaches I considered for these key game mechanics, the reasoning behind my choices, and how these decisions are shaping the game's development. Let's dive into the foundations of building systems and the intricacies of pathfinding algorithms!

Pathfinding 

Right from the start, I envisioned peasants as the backbone of my game. They're the ones who get things done—building structures, transporting goods, and tackling tasks like woodcutting and farming. I also knew I wanted a user-friendly road system; something as simple as drag, click, and voila—a road appears. My goal was to design the pathfinding in such a way that, when calculating routes, the peasants would prefer paths with road tiles over those with grass tiles. Fortunately, Godot offers some great features like pathfinding and the A* algorithm, which are perfect for this.

I opted for the pathfinding capabilities provided by navigation agents and navigation servers in Godot 4. This system allows for straightforward designation of tiles as walkable or non-walkable. Additionally, it supports the use of navigation obstacles for path avoidance strategies. While Godot offers an extensive toolkit for navigation, it can be challenging when dealing with objects that have collision shapes. This required some intricate coding on my part, involving setting up areas and collisions, creating polygons, and then integrating everything by baking the polygons and areas into a single region that communicates with a server. Fortunately, this approach worked seamlessly, perfectly accommodating the mix of tile obstacles and node-based obstacles present in my game.

Pathfinding with Navigation Agent and Navigation Server alongside with custom solutions to find a road tiles

The real challenge cropped up when I started fine-tuning the path calculations. As you might recall, my goal was for the peasants to prefer roads over any other type of terrain. Unfortunately, I discovered that Godot pathfinding didn’t have built-in functionality to assign different weights to the tiles, which was crucial for my needs. To work around this, I developed a custom solution: I implemented raycasting to dynamically assess the area around the peasant every time they moved. This system checked the six surrounding tiles, prioritizing the road tiles for movement and recalculating the path repeatedly until the peasant reached their destination.

Although this method seemed promising, it was riddled with bugs. It failed to function correctly when moving from the negative Y to positive Y direction, occasionally missed the final destination, and sometimes caused the peasant to loop unnecessarily. Overall, I was quite disappointed with how it turned out.

With A* pathfinding works smoothly - it calculates the path using the roads and considers objects as obstacles

I then switched to another strategy—using the A* algorithm. A* facilitates grid-based movement without actually needing to implement a physical grid. All I had to do was overlay the tilemap and specify which tiles were navigable and which weren’t—similar to what I tried with navigation agents, but this method was far simpler and required significantly less coding. Once I integrated A*, things started to fall into place beautifully. I could easily set obstacles and assign weights to different tiles, influencing movement costs. Now, my peasants automatically prefer roads over any other terrain.

The only snag I hit with A* was dealing with objects that had collision shapes, making them impassable. To handle this, I needed to calculate the space each object occupied, convert that into an array of tile positions, and mark each tile in that array as non-walkable. With these adjustments, A* now functions precisely as I envisioned.

Building

When it came time to decide on a building system, I was torn between a grid-based setup and a freeplacing system. Without a clear preference for the pros and cons of each, I opted for the freeplacing approach simply because it seemed straightforward.

Implementing this system was relatively smooth. I added a few buttons, sketched some designs, and incorporated a handful of aesthetic enhancements like building ghosts for preview, Z sorting for layer management, and obstacle checks to prevent overlap. The mechanics were basic: select a scene, node, or tile, grab the mouse coordinates, and drop the new object right where the cursor is located.

Freeplacing system allows you to put building wherever you want

I didn’t stop there, though. I integrated collision shapes to keep objects from overlapping, devised a road system for constructing pathways, and even developed a feature that snaps buildings to the nearest road if one is nearby, enhancing the building experience.

Road system has a temporary road color. It works only in 4 direction between point A and B - but it's enough at this point

However, over time, I noticed some issues with this freeplacing method, particularly with area checking and pathfinding. It became clear that I needed a more structured approach, prompting me to start transitioning to a grid-based system. This change is still underway, and I’ll share more about it in future updates.

On the bright side, the building system I’ve set up is highly flexible and scalable, thanks to custom resources similar to Unity’s ScriptableObjects. This allows me to easily create a variety of buildings by simply generating new resources from the established custom resource template.

Current system allows to put roads and few types of building, also checking the overlapping

Overall, I was somewhat pleased with how the freeplacing system turned out, but I couldn't shake the feeling that its initial design was a bit off. It ended up being more complicated than necessary, with several superfluous features that only served to clutter the code and lead to a slew of errors. I'm still on the fence about which system is truly better, but considering my future plans and the direction I want to take the game, I'm leaning more towards adopting a grid-based system. It seems like it will better align with my upcoming needs.

Future plans

In my upcoming posts, I’ll dive into some key features I've been prototyping, such as work placement, assigning tasks to peasants, the basic mechanics of their first jobs, and some initial interface designs.

As I mentioned before, I’m currently overhauling the building system. It’s a substantial update, so it's taking a bit of time, but I'm optimistic about sharing some positive updates with you soon. Once the new building system is in place, I plan to introduce additional workplaces to demonstrate how different systems interact. For example, a woodcutter will chop down trees, transport the logs to a hut, and then another worker will take these logs to a sawmill to process them into planks and firewood. This will showcase a linear progression of materials within the game.

Thanks for reading - and do not hesitate to ask any questions if you have some. See you soon!

[bobapplesimblr]

Devlog #4 - Visuals!!

Hello friends! :D I've been doing a lot of sprite work and visual work behind the scenes, and I thought it was about time to share it with you all.

Before I go ahead and share the images, please keep in mind a lot can still change, and it's possible that a year or so down the line the game visuals will get a rework as my pixel art skills grow.

SO!

The first thing I really worked on was an image for the start menu, something to have behind the options, and I ended up with this:

Now, if you read my previous post you'd know I'll be changing Game Engines soon, so although I did have the main menu set up and mostly functioning this way in GDevelop, I'll likely have to rework it for Godot.

However! This became the base for *most* of my colors moving forward, though they are actively getting changed and swapped out deppending on how they work in certain contexts and applications.

-----

After that I decided to try my hand at making a quick and dirty map layout for the main area, and that's when I started losing the plot a little bit...

I started trying to rework the story I had, cause honestly, I didn't really HAVE much of a story. However, I didn't like any of the ideas I came up with, not entirely, and it lead to an entire day of frustration.

I ended up with a map like this, with grand ideas of having horror elements, many more fighting areas inside certain buildings, etc. But I likely will not use it anymore.

That being said, this is still my art, so please don't take it and use it without permission just because I won't be using it myself.

-----

After all this I took a break from reworking the story. I took a break from the project entirely, writing down a few notes here and there of little scenes I wanted, little dialogue details or mechanics that came to mind. It was nice to take this break, and I think it was very needed, but I cannot be kept from a passion project for too long.

Today I decided to change game engines for 1 main reason: Tilemaps (and procedural generation)

GDevelop, as far as I know, does not have the tilemap tools I wanted to use for this project, but Godot does, and in preperation to transfer over my project I decided to try working on some quick, and possibly temporary, tilemaps. And it was so fun!!!

I had so much fun booting up Aseprite and working on this. I'll have to import them into Tiled and later into Godot, but I am having so much fun working on these, even if the color palette isn't what I expected at first. Still, I'm very excited to make more and begin building environments with this.

-----

And that's about it for now! At least all I can remember off the top of my head right now.

If you haven't heard yet, I have a new Patreon so I can try and stay funded during this process! I trust that I won't be in trouble without funding, but all and any support is appreciated, always!

Thank you so much for reading, and have a wonderful day!!!

[hydralisk98]

LibreVast, my newest toybox 2D+3D workflow Quake-clone in town, devlog #0

More aesthetic references...

Loosely based onto this previous concepts...

Yes, I intend to make such a "Layered Z-axis 2D-to-3D workflow" copyleft first person "toybox" at my pace starting after next Monday, taking elements from Qodot (4), "BUILD2", "Red Eclipse" and "Aleph One" (the mainline open source Marathon port) legacies as to craft a new curiosity-driven experiences akin to a modular mashup between the puzzlers of "Narbacular Drop / PUNT / Portal / F-STOP / Frame" and the creative programmer havens of "Quadrilateral Cowboy / Zachtronics' / Hypnospace Outlaw".

And I do plan to have a thesis of a hyperlinked overworld multi-planar editor (Using one top-down overhead pane layers that interact with each other a bit like the OpenTTD / RollerCoasterTycoon-like 4D Golf editor I saw online here) following the 4x area rule (Great for converting to hexagonal and square-based tilemaps towards my Civ5CE + FreeCiv set & the SC4 + TS2 combo for example) that might take advantage of several new innovations I saw as of late. (EVALDRAW, N-dimensional Rotors, six great code snippets for Verlet Integration, Spatial Hashing, Contraint Solving... )

But until I get back home, the progression will most likely be halted much before my return. So until Monday September 18th or its very next day, take care of yourselves and farewell!

[asspull3x]

System Showcase

The Asspull IIIx is like if you mashed a Super NES, a Megadrive/Genesis, and the general design concept of an old micro computer together, flavored with MSX.

What does that mean?

It means you get a video game system that takes cartridges, but it also takes diskettes and hard drives.

Also, all of its parts have silly names, inspired by the Amiga.

Lalanne

Lalanne is the code name for the A3X's motherboard as a whole. It comes with fifteen expansion card slots (the sixteenth is Fonda, described below), a 128 KiB BIOS ROM and 4 MiB of work RAM. Cartridge games can be just under 16 MiB in size, leaving some space in the memory map for the BIOS and any battery-backed cartridge RAM.

Fonda

Fonda is the I/O controller. It is one of only two devices that's hardwired onto the Lalanne motherboard. On the one hand Fonda handles inputs from the keyboard, mouse, and controller ports. On the other, Fonda handles the MPU-401, OPL-3, and PCM audio systems.

Austin

Austin is the video processor. It features four different screen modes and up to 256 colors:

Text mode, with 40 or 80 columns and any of 25, 30, 50, or 60 lines, in 16 colors. It's really not unlike on a PC.

Bitmap mode with 4 bits per pixel, linear, with 200, 240, 400, or 480 lines of 320 or 640 pixels each, in 16 colors.

Bitmap mode with the same resolutions as the other one, but in 8 bits per pixel, so 256 colors.

A tilemap based mode. It has four maps of 64×64 tiles each. Each tile is your standard 8×8 pixels in size. The 256 color palette is split into 16 lines and each tile can pick from those. Tiles can be flipped both ways. All four layers have the same functionality, including pixel-level scrolling, additive and subtractive blending, and windowing. The only limitation is that you can only use 320×240 resolution.

On top of all that, all screen modes have full sprite support. There are 256 possible sprite objects, each with their own 16 colors chosen from a separate 256 color palette. Each sprite can be flipped both ways, blended both ways, positioned much anywhere, appear behind any layer, and be 8×8, 8×16, 16×8, 16×16, 16×32, 32×16, or 32×32 pixels in size.

All of this powered by 512 KiB of video RAM, subdivided into maps (text, bitmap, or tilemap), tile graphics, color palettes, font graphics, and sprite object attributes.

Simmons

Simmons is the disk controller. More can be attached as expansion cards, but one comes preinstalled. Each allows two more external disk drives to be attached, but the built-in one only has one port — the other is attached to an internal diskette drive. Each Simmons has two sets of 512 bytes of internal RAM to cache any sectors for reading and writing, available to the main system. The BIOS offers full support for FAT12, FAT16, and FAT32 volumes.

Smith

Smith is the A3X's line printer. A simple dot matrix device with an 80 character line buffer, not counting the control codes that allow it to print in bold type and underlined.

Little

Little is the A3X's gamepad. It has four action buttons, two shoulder triggers, start and select buttons, and a D-pad. The Anthony variant adds an analog stick.

Crawford

The keyboard! It has no numeric keypad, and yet the BIOS' line input routine support alt-number codes.

Kennedy

Kennedy is just a regular old mouse. This is somehow not some failed Resident Evil joke.

[gdscript-official]

I'm gonna be honest, setting up tilemap terrains (auto tiling) makes my brain explode

[km-independent-project]

Endless Runner

In Unreal, Create a new actor called parenttile. This will be the main tile that will be used to spawn other tiles ahead of the player.

In this actor, add a new component, this will be a PaperTileMap.

Then make the Tile Map in details your main one.

Now go into your viewport for the actor and make sure you can see it.

Once everything looks good, we want to create a collision box as well.

We also want to create an arrow, I will name this SpawnPoint

Once made, put the collision box to the far right side of the tilemap at the very edge and scale it up on the correct layer of your tilemap, making sure the player will hit the collision box along the path. We will be using this collision box as a trigger for more tilemaps to spawn ahead of the player.

If you do run into issues with the spawning, you can use a print string to make sure the collision box collides with the player. When you reach the collision box, if the player is actually hitting it, it should say 'Hello'.

Now, we want 3 tilemaps to spawn ahead of time so the game appears seamless, which will be necessary for player immersion. To do this, we will go into our Game Mode.

In here, on the My Blueprints dropdown, create a new function, this will be used to make the new tiles spawn and to set new spawn points for them.

Now, create a new Component and make it a Transform type, I named this NextSpawnPoint.

Now, create a SpawnActor and make the thing being spawned the Parenttile we made earlier.

We will also want to make the tiles behind the player disappear, to do this, we will use a Delay.

[lakeofnakamura]

Postmortem

In this game I really wanted to focus on the theme of ninjas and how that would influence the gameplay. First, I thought about what sort of pace a platformer based around a ninja would have and what sort of movement physics the player would have. I wanted the player to move quickly and be able to change directions quickly with relatively strong jump gravity and fast wall jumps. Discovering the grid system was also extremely helpful for level building and saved a lot of time. I added some basic enemies and the ability to throw shuriken and jump on enemies. I initially had ideas about other features such as a grappling hook or a cutscene for the ending but I didn’t have enough time to implement those things.

It was a very interesting experience making a game with GDevelop. Using the events system instead of writing lines of code was a lot more simple but felt harder to organise. It also took a while to figure out how to use expressions with GDevelop. The pre-built behaviour packs provided by GDevelop were extremely useful and saved a lot of time since I didn’t have to code collisions with platforms, dashing and wall jumping. However, the values provided to adjust those behaviours were not always clear and required a lot of trial and error to achieve what was desired.

If I were to make some changes to the game, I would make it more forgiving such as adding coyote time and reducing the size of hitboxes for spikes and enemies. Going back to the concept of the magic circle, I would also dial down the puzzle aspect of the game and focus more on platforming/combat since it was quite confusing and isn’t as conducive to the theme of ninjas. A minor point would be changing the visuals for the player. The colour scheme of the game is overall a bit darker since the setting is a cave, however the player sprite doesn’t really fit in both in colour and art style. Next time I would use a more realistic sprite with darker colours. I would also change the dash key to something more universally accessible such as left shift.

If I could start over, I wouldn’t approach it very differently. I am quite happy with how I went through the development of this game. I defined the goal and scope of this project early on and built the prototype accordingly. Although I also had ideas for other features, I quickly realised I wouldn’t have time for them and never actually attempted to develop them. The only thing I would do differently is not worry about the visuals so much as mentioned in chapter 8 of the book. Initially I spent a sizeable amount of time looking at sprites for the player such as ones that had many different animations but cost money. I also experimented with the tilemap feature since I didn’t want the terrain to just be one tile. However, I then realised that neither of those aspects affected gameplay so I settled for what is seen in the final prototype.

[finalmajorprojectyear2kv]

Reflection - Past Projects [Year 1]

2D Platformer - Unnamed

What went well :

I'm really proud of the art work in this game, mainly the character model.

The two levels were all designed fully by me and contained secrets, the the player could find, that would grant a reward.

What didn't :

The movement feels slippery, not snappy, which can make the platforming frustrating.

I didn't enjoy developing for 2D as I feel that it is very limiting.

There wasn't much to the project, it felt very empty and didn't have a good gameplay loop or replayability.

Evaluation

Overall, I feel that this project had hit the targets of what I had to set out to do. Looking back I feel that the art was the most fun thing about making a game for 2D, but I didn't actually enjoy the development side of the project which is what my specialism is this year.

If I could continue this project I would take the movement mechanics further, making them feel more fluid and snappy like Celeste or Super Meat Boy, as well as the accompanying artwork for it. However, this project did teach my all about tilemaps, sets, sprite sheets and general 2D game development.

First Person Music Game - Zombeat

What went well :

The level was designed by me, and even had it's own lighting.

The models were all original and made by me in MagicaVoxel.

What didn't :

The car's movement felt too flowy and realistic and not arcade-like and snappy, the same issue that the 2D platformer had.

The abilities felt shallow and rushed, the idea was really cool though.

Playtester's rarely found the shop in my level, meaning they missed most the content.

Evaluation

Overall, I feel that the end result of this project fell short of my original idea and lacked any depth in it's various mechanics. Looking back I feel that learning the particles effects for this game was probably the most fun thing about it, as I didn't really enjoy 3D modelling or developing the systems that were present in my game.

If I could continue this project I would overhaul and rework the abilties, and the accompanying HUD and shop UI elements as I feel these were the most lacking. However, this project taught me how to implement sounds, particle effects and develop 3D games.

Arcade [MARS] Project - Unnamed

What went well :

The game has a stylised art style, low poly, that I really like.

I really like the unique take on third person that the camera has, especially how it is framed by the tree.

The level has lots of details that makes it feel like a busier city, even if the building colours are a little repetitive.

What didn't :

There was no larger gameplay loop, meaning players had no desire to continue playing.

The game was too easy, the player barely had to move where they were aiming.

There was a lack of variety of enemies.

The music and sound effects felt very obnoxious and loud, not accurately reflecting the game.

Evaluation

Overall, I think the end product had met the baseline of my intial idea but it lacked polish in many areas that would've made the game hit those key points. I really enjoyed designing the level for this game, especially with the unique framed camera perspective, however the level is a little bit too much of the same colour. Also, I had loads of difficulties with the character models I used which really cut down on my limited time for this project.

If I could continue this project now I would completely re-do the whole target and point scoring system to add more depth and challenge, also adding in more audio queues. However, this game did teach me about how to effectively design a 3D level.

Final Major Project [FMP] - Tiny Town

What went well :

The background level really frames the playable area well, using the river and the thicker forest to the bottom left to surround it.

The post processing effects add to the stylised art work, making it feel more toy-like.

The UI animations, specifically for the destroy & switch mode borders, look very nice.

There is a good selection of place-ables, with different varieties for each.

The game had a small tutorial to tell players how to play and what to do.

The background music and sound effects fit very well with the theme of the game.

What didn't :

Having to go into a different mode to switch the style of the buildings was slow and tedious.

Nothing happens in the city ; the buildings you place have no purpose.

Your city isn't saved.

I don't like the UI style, it is too rounded and small.

Evaluation

Overall, the end product is barely anything like my initial idea because I deviated the project in the direction that playtesters, and myself, found the most fun to do. I also updated the scope of my projects by doing consistent progress reviews, leading to a game which had less, but better, features.

I really enjoyed designing the forest surrounding the playable area, which I found quite unexpected, as well as understanding and expanding upon the tutorial I followed for a grid based building system. However, looking back on my project I don't really like the style of UI I went with as it's all too round.

If I could continue this project now I would overhaul the grid based building system so that it has more functionality allowing for additional features to be added, which couldn't with the old system. However, I did learn a lot about Unreal's different camera perspectives, line traces and UI.