May 31st 2025

Moving forward these blogs hopefully won't be so long winded, I've titled off the sections so you can jump to the paragraph that interests you most if you're not interested in all the details. This is a breakdown of a period of development of an indie game, prototyping, failing and then iterating and finally the first dev blog for Scraps of the Sea.

So with that said... Let's start with a Fail!
 

FAILED PROTOTYPES

Where do I start... literally. If you've ever made a game before you may have asked yourself this as well. Often times developers say the hardest part of making a game is actually finishing it. I can understand this as the thought process is that most developers give up after the development starts to get hard or they've written their code into a corner and can't fix the rats nest or solve a hard technical problem, but I think there's also an early hurdle. I think the middle point is actually the easiest, at that point you are cooking. The start can seem daunting, there's so much work ahead of you, Where do you even start? what tasks should be priority and what are all the dependencies? Do I tackle the technical concerns early on so I don't get to the end and give up then? Do I focus on the prototype to prove out the fun of the game? 

I've iterated on a few prototypes the last couple of years and have quickly been bored from the gameplay. This is one of the last prototypes I had worked on, it was the first path I took under the codename SotS which still stood for the same game name I have now of Scraps of the Sea. You were stranded on an island and had to pick up shells which acted as currency and you when then purchase upgrades like a bucket shovel eventually getting a metal detector finding scraps of parts under the sand you would use to build robots that would automate all of these tasks for you moving forward. I spent a lot of time over engineering the architecture ahead of time, planning, ensuring that the game was all modular and decoupled and slowly implemented it.... and when I showed it to people, family, friends, it was clear they weren't enthusiastic about it. The, "Yeah I get it came in pretty quickly".

I never made it to the robot building and programming part of it which i think would be the interesting part of this... but I could also already see the negative reviews that would follow of it being too slow and boring I spent time making gameplay quicker, features unlocked quicker and eventually I realized I just wasn't going to be happy with this. 

The inspiration for this game was to eventually have this also be a co-op experience with up to 4 players. I wanted to make a game that my entire family could play together and enjoy. These are rare as my wife has very specific tastes in games and then combining what my son and I enjoy and it becomes a very narrow gameplay experience. 

Takeaways:

• I overengineered from the start before proving out the fun overcompensating for the lack of planning architecturally for IBB.
• I learned I really don't like working with tilemaps and sprites and animating them.
  • I don't mind doing 2D art, but animating 2D art isn't something I enjoy doing.
• As a positive. A lot of the modular developments I made for this are so decoupled that I could re-use the utilitary code I made.
  • Logging Systems, Save systems, Event Systems and Localization Systems, base networking systems and Steam Management can all be reused moving forward.
• I need to make something that I'm specifically passionate about and not a compromise on what will make everyone happy.

INSPIRATION

My main focus had been building off my previous games genre of having an idle game that had a bit more active gameplay mechanics. As a bit of background, the main genres I play are Tactical RPG's, JRPGS, Idle/incremental, FPS, and fighting games. I've played chess since I was about 7 and my favourite games have been Final Fantasy Tactics, the Disgaea Series, Shining Force etc. Recently I've gotten back into chess as my go-to distraction on my phone via chess.com... I'm not great I'll admit, but I love the game, the strategy and planning etc. 

 

In College as my final capstone project (20 years ago) I created a networked cross platform (Linux / Windows) Tactical RPG base with a single penguin with a flat board. It didn't fully work in the end, but I was still proud of where I got with it as I learned about rendering, networking, cross platform dev etc. It was a very valuable project and something I've always wanted to go back to... and here we are.

The Game Themes at least have been consistent. I still plan to have robots on an island and programming and scrap finding as the main theme and gameplay... but that's about where it ends in similarity. I've now switched to a 3D Tactical RPG and kept the title Scraps of the Sea.
 

PLANNING

I started by creating a high level plan this time. Design wise and task breakdown. I know this won't be fully comprehensive of all tasks, but it gives me a high level overview to plan from. There's always going to be hiccups you cannot plan for, there's always going to be those tasks you assume are easier than expected. That's development. But I can plan a bit  base off this knowledge. I created a Design Document which covers the high level story points, Gameplay mechanics, Music and sound expectations and art styles. It has a list of assets I'll need to create and the coding components I'll need to implement. This document is large and I won't share the contents here but it's roughly 20 pages already and it's high level. 

Additionally I preplanned some of the architectural design requirements and how the gameplay will be managed. I made some decisions towards the design to remain in scope and not get too overwhelmed, but I'm committed to a long term project here that I don't foresee being completed in 2025. Playable yes, In fact I'm hoping to have a playable prototype of the battle system by the end of June, however this is without much of the remaining processes and systems that will be required. I can share my current expected planning and this will be fun to run back over in the end to see how far I was off.

Planned Stages:

• End of May - Base Island Generation and Turn mechanics implements
• End of June - Battle working as expected with AI opponent, basic in battle UI elements and menus, able to complete an entire battle
• End of July - Basic Main Menu, Map, Party Management, Inventory management screens without anims and ugly art, base dialogue system for story
• End of August - Customization and Programming of Robots with skills, Shops, Quests
• End of September - Some main level designs created and accessible
• End of October - Save System for data
• End of November - Animations for robots
• End of December - Menu Art, music, sounds and Animations
• End of January - Pirate Battles
• End of February - Boss Battle 1
• End of March - Early Closed Alpha Testing and Feedback
• End of April - Networked Battle
• End of May - Match-Making
• End of June - Ranking System, More Levels Added, More Enemies, More Story, More Bosses
• End of July - Bug fixing, Optimizations, Polish, Polish, Polish
• Start of August - Early Access Steam Release

will this list help keep me accountable? Who knows... But I'll try to at the very least do more incremental blog posts moving forward so you can follow along as the game is developed.

DEVELOPMENTS SO FAR:

 I've managed to make some key foundational implementations in the first month or so of working on this new version of Scraps of the Sea:

• Base terrain generation
  • Island Shaders
    • mapping out highlighted tiles
    • ability to assign textures per tile
    • Waves on shore effect in shader
  • Waves shader
• Gameplay 
  • Initial placement area for characters
  • Base core gameplay mechanics of turns, movement and attack
  • Base Stat Classes and Character Class 
• Stylization:
  • Created models for a basic robot, 2 types of rocks and a palm tree
  • Toon shader for character and items in world
  • Random world placed static objects like rocks and palm trees
  • Fix for toon shader to display the characters when hidden behind larger objects.
• Camera movements:
  • Input Manager
  • Camera Panning and raising.

I'll expand on each here and some of the considerations and difficulties I may have faced.

THE BOARD: ISLANDS

Making the islands base board took a bit of iteration. I started out with just a plane and was changing elevations rendered through the vertex shader of a custom shader. This did work, but wasn't smooth and I was doing manipulations and calculations every pass through my shader which seemed like a waste. Instead I moved the generation of the mesh entirely to the C# side in a Board script. Here I generate a new mesh by looping through the amount of tiles I wanted and then just generating a random height within the min/max range I want islands to be. This took some playing around with to get a middle ground that looked okay.

Next step was to then smooth out the heights so it wasn't so random. To do this I again loop through all the tiles and check all the sides of the tiles to smooth out or find the median value to ensure I'm not going from a height of 0 to a height of 4 in the next tile. The middle ground is then assigned to the tiles smoothing out based on averages.

Then, using this tile height information I generate vertices, 1 vertices per tile. But you may be saying there are 4 vertices per tile because a tile is square and it becomes two triangles. Yes, to begin with I start with a single vertices per tile in the bottom left assigned the height. As we keep looping through each tile, this will result eventually in a board with 4 squares as the vertices will be shared between tiles. At the same time I am also populating the UV data locations which I will get into after.

I then made two triangles for every square worth tiles. This process was just iterating on the vertices generated and saying which ones are used for each of the two triangles. This means that each vertex (except for the first and last ones) would be shared between tiles and the island would be smooth

That was it and I had a generated mesh with verts, triangle data, UV's and normals. Turns out I didn't need to do anything for normals and meshes have an ability built within to RecalculateNormals so that was a nice easy step. I wish I had taken a picture of it at this point in time, but blogging didn't cross my mind until later, but it was a blob of sand as you'll see in pics moving forward and there was no lighting, but I could see heights on the contours and levels so I was happy with it at that point and moving the camera around I could verify the heights looked good.

BASE GAMEPLAY

I presently have the ability to show the initial placement squares and select tiles to place which first highlights in yellow and then places on second click. You can place 5 character and the enemy team will randomly place 5 in the opposite side of the map. Presently turns are forced, with it grabbing the next active character and based on time and their speed and then forcing them into a movement phase, this will highlight the board in blue and then on click of a blue tile move the character to that new location. This checks for obstacles and other characters. You cannot move through other characters and obstacles. Your robots have a rechargeable solar powered battery and this dictates what you can do on your turn, when your battery reaches 100% it's your turn, every bot charges based on their speed stat. All stats are just randomly generated at the start right now.

Depending on how far you choose to move, it will consume more battery, if you move the full extent, your turn is over. If you move half way, you have enough energy to attack. It is then forced into the attack phase. This is just for development and eventually you will have full control of the phases of how you spend your charge. You can attack more than once and not move, you can move slightly attack then move again, entirely up to you on your turn. This I think is a bit different than most other tactical RPG's and something I'm looking forward to seeing if it causes exploits or issues or just new strategies.

Presently it will loop through move first then attack then move etc etc until all your energy is drained, eventually you will have the option to end turn early and in fact you will want to as I plan to have a burnout for draining down to 0% which is not good. 

Once your turn is over it automatically finds the next closest bot to have a turn based on their energy level and time and it speeds forward to that updating all other bots on the time that has passed so they gain that amount of energy as well.

This just keeps looping right now of move attack move attack end turn next bot.

I don't have the attack processing doing damage or reducing health and so they just loop forever with no bots dying and no winner. Hopefully later today that will be in place.

STYLIZING

At this point with some core functionality in place I wanted to get some obstructions in place for the characters. As the map was going to be completely smooth, I wanted the pathways to be determined by obstructions placed on the map. These will be things like rocks, palm trees, bushes, Huts, planks, barrels etc. To begin with I started looking at free assets online for this and even loaded them into the project but quickly became frustrated with the style not matching what I wanted or it not working well together and the concern that grabbing pieces from different artists will eventually lead to a disconnect in the style so I bit the bullet and dove into modelling with Blender... I've done this in the past, way back in school when I was a student and occasionally in small projects I'd abandon over the years but never made a whole lot. I've always written off 3D as being too out of scope for one person but I'm glad I changed my mind. I like the palm trees and rocks I've created so far. I'm going for a low poly look which plays to my level of skill for 3D. My Palm tree model I made I decided to separate the trunk from the leaves in the end and lost the final leaves blender file, but the left shows how the leaves started.

Rocks were really easy for the most part with semi random extruding and rounding. It wasn't overly difficult. The bots... well they are just a cylinder for now tapering at the top, the bots are just placeholder for now as I eventually want them to be component based models for each body part. You'll be able to collect scraps to create new robot weapons, bases, bodies etc in the future. I'm sure this will be a challenge.

I went to work then loading them into unity, making materials for them and wanted to keep with a low poly chunky style so I created a toon shader to apply to these models and the characters. I'm quite happy with the chunkyness that was created and also applied it to the main island. This allowed me to see better the lighting on the island and where the hills and base points were. I really started to like the look and feel that was coming out of this. I didn't like how my water was just a blue plane sitting against the island so I started to look at waves and how I could emulate the shore of an island going in and out. I started making a shader for the water itself and using sin waves to emulate waves but it never looked good against the island as the water had no context of where the island was... I stepped away and did some thinking and thought what if I extended the tiles beyond the play area and used the outer two most tiles of the island shader to simulate the waves going in and out. I used a noise texture I created in paint that just had a surround of the island which greyscale faded out. I then in the shader use the sin wave and grab the colour on the noise to simulate the water going in and out and add a white outline at the location of the active selected value. It's sort of like a dissolve shader but oscillating in and out. Note the image is sped up since I wanted to reduce frames uploading the gif here (it's about 4x slower)

You'll also notice in the gif above that you can see the red characters through the trees. A pain point for me in the past with Tactical RPG's has always been obstructions of the view of important things like characters or drops. I wanted them to stand out so I wrote an option into the toon shader with a new pass that renders in vertical lines every 2 pixels the obstructing objects colour with the characters colour so they aren't completely hidden. I have the characters colour alpha blended as well. You'll also noted I used the sin wave in the island shader to also fluctuate the movement / attack highlights on the tiles to make them pop a slight bit more.

I just want to note about the placement of static objects like the palm trees and rocks. For now, this is a bit of a messy implementation of semi randomness but I was inspired by a blackjack card counting video I watched using a weighted system for counting. Essentially any 10 value card gives +1 any card 2-6 gives -1. I used a similar concept here where each item spawned has a weight and it keeps track of the weight as it loops through all tiles so when it spawns a larger object like a 2 tile rock or the palm tree it increases the weight value which it uses to determine if it should spawn or not. Each tile it passes without a spawn it subtracts 1 each time it spawns an object it add +20 or so depending on the type of object. This has mostly worked well.... but I have seen 1/100 instance of crazy spawning still so I'll need some further steps to the algorithm with an A* check to ensure pathways aren't blocked from team to team.

CAMERA MOVEMENT:

At this point I could see the value in camera movement, to rotate around the board/island and get different perspectives. I started by implementing the 4 standard rotation camera locations around the board and made a script to pan between them. I needed to use the new input handler but learned this pretty quickly and implemented an input manager to wrap it in case I need my own specific handling for it. I tied the q and e keys to rotation left to right for camera locations. I then also wanted the mouse wheel to "zoom" in and out, in reality it's more moving up and down and not in and out but again I grabbed the mouse scroll from the input manager and mapped out a way to get the value which gives +-1 and then tied it to the height of the camera min maxing to clamp the possibilities and panning to the new height. This made it pretty flexible to manage and see everything on the board.

NEXT STEPS:

1. Complete the basic battle attack processing and have units die.
2. Experience calculations, levelling up units
3. Add terrain diversity by setting dirt and grass tiles as well
4. Allow users to specify facing direction at end of turn and rotate bot towards that.
5. HUD and menus for the battle
6. Enemy AI Logic processing

 That's it for now... Steam Page coming this summer to wishlist.

If you are interested in the games development, please hop in the discord located here for the latest updates:

 

Join the Discord