Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

Advanced search

1380207 Posts in 65795 Topics- by 58187 Members - Latest Member: rarbgproxys

August 05, 2020, 05:57:09 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsGravity Hook [WIP] - A skill/puzzle game set in an athmospheric space setting
Pages: [1]
Author Topic: Gravity Hook [WIP] - A skill/puzzle game set in an athmospheric space setting  (Read 1830 times)
Level 0

View Profile
« on: August 22, 2019, 02:05:55 PM »

Hi Everyone!

Gravity Hook is a game that started as a Ludum Dare entry and later on I've decided to make a proper game out of.

In terms of levels the game is complete, pretty much all the levels and the mechanics are there. Now comes the most important part of development, Polish and Game Feel.
I wanted to post the devlog when I was done with the levels so you could see the drastic changes the game will go through. Hopefully it'll be exciting to all of you as it is for me.


In the year 2055, Earth is running out of energy sources. War has torn the world apart, the only hope is to find an alternative energy source. For that purpose The Global Energy Research Agency(G.E.R.A) has been founded.

For 3 years, the G.E.R.A has been investigating signals of a star which produces natural energy. On April 19, drones were sent to harvest the energy, and have been successful.

G.E.R.A has sent the first energy consuming shuttle with a crew of four, after a successful launch and 4 days of space travel the shuttle has lost contact and the crew members were declared MIA.

G.E.R.A is preparing a second shuttle.


  • Gravity Hook: The main mechanic in the game is the hook. The hook will allow you to pull yourself towards objects mostly it's going to be ship panels. But all of this will happen with zero gravity, once you pull yourself you will keep moving towards that direction, you will have to master your movement with the hook as the game will only get tougher and more complex with each level.
  • Ship Panels: A Hook in space? what is there to hook? blown up ship parts that's what! As the story progresses the shuttle will..well..get fucked. The panels will have attachable parts, Flaming parts, some panels are movable some are pushable. Anyway you will start appreciating them! (or not depending on your rage level..)  
  • Oxygen: Your enemy in space, besides the blazing meteors and extreme pressure, is oxygen. Oxygen plays an integral part as you will not only have to get from point A to point B (innovative shit), you will need to do it fast..sometimes very fast.
    Your oxygen constantly reduces and until you reach a shuttle you will have to keep an eye on it and plan your path carefully.
  • Space Shuttles: These are your only methods of surviving and traveling. There are 4 shuttle types: Start, Oxygen, Checkpoint and an Exit shuttle.
    Sometimes the shuttle is powered off and you will have to find a battery to power it up and use it.
  • Space Fun! Not really tho. During your journey you will face meteors, darkness and ammonia clouds.
  • Jetpack: Introduced later on will allow you to have extra control over your movement in space.

Screenshots + Gifs

As nobody read what I wrote above here are some images and gifs of the current state of the game:

And that's it Smiley
« Last Edit: June 15, 2020, 04:45:23 AM by GlacierEclipse » Logged
Level 0

View Profile
« Reply #1 on: August 31, 2019, 03:24:14 PM »

DevLog I - Performance / Collision

This week I have worked on performance and a little collision fix. The game was mostly tested on PC during the later stages of development, so I haven't paid too much attention to the performance as it was smooth.
And then I ran one of the heavy levels on my phone..the game barely moved, it took ~20-40 ms for one frame. Given this will be a mobile skill game I had to make it 60fps. So this week I have focused most of my time on the basics.

  • Collision: At the start of the week I did make a small collision change to the players collision with the panels, it wasn't physically correct nor was it natural and created issues with some levels in terms of movement so I had to make this little fix.


  • Optimizations: I've started with the following stats:
    Update: ~25ms
    Render: ~20ms

    • Camera culling - Don't draw entities off the screen. ~10 ms(!) on the heavy levels.
    • Grouping entities and layer order - grouped similar entities together and rendered them at the order that was defined. Render gain:  ~5 ms.
    • AABB test - Run an AABB test before running the heavier collision detection between entities. Update gain: ~10 ms
    • I haven't used a performance class or something of the like, the performance measurements up to this point were very basic, just printing the elapsed time on the big functions. I needed more detail, so I starting writing a profiler class. It worked fine until the point that I wanted to postpone the printing of the logs, and wanted it to be formatted from start to finish with the correct tab indents(Why? Shit I don't know). Which took a while to write correctly and get real time measurements. But heyy Look at this beautiful format Smiley Performance gain: ~0 ms

    • Texture Switches and draw calls - There were too many texture switches, so I grouped all the textures into one and drew only regions of the textures. Render gain:  ~7 ms
    • Particle Emitters - Updating and rendering particle emitters in the same function - meh about ~0.3ms
    • Less Function calls and inlining - I had some simple functions that were called hundreds of times in an update/render function, which did a very simple functionality like setPosition() in applyVelocity(), so I moved it to one function. Less function calls did result in a performance gain of ~1ms 

Future optimizations:
Shadow & Light - I had a system generating the shadow polygon every frame, drawing it to a separate framebuffer, blurring it and then rendering light masks for every light with alpha blending, took a lot of time on mobile ~7ms.
I'll need to rethink this and write something more mobile friendly (Maybe baking light at the start of the level and updating and drawing the shadow only for dynamic entities?)

Number of entities: 933
Num of total render calls: 17
   Time of execution of Game Scene Update is: 23.07ms
         Time of execution of Render Poly Shadows is: 3.74ms
      Time of execution of Game Scene Render Lights is: 5.33ms
         Time of execution of World render is: 6.85ms
      Time of execution of Game Scene World Render is: 7.82ms
         Time of execution of Render Lights is: 0.36ms
      Time of execution of Game Scene Render Lights is: 3.33ms
      Time of execution of World shape render is: 0.88ms
   Time of execution of Game Scene Render is: 19.02ms
Time of execution of Game scene total is: 43.01ms
Number of entities: 933
fps: 62
Num of total render calls: 6
Time of execution of Game scene total is: 8.23ms
Time of execution of All Update is: 3.97ms
Time of execution of All Render is: 4.24ms
Time of execution of Game Scene World Render is: 1.39ms
Time of execution of Game Scene Render Light masks is: 1.79ms
Time of execution of Game Scene Render Lights is: 0.37ms
Time of execution of Game Scene Shape renderer is: 0.65ms
Avg Time of execution of Game Scene Shape renderer is: 0.98ms
Avg Time of execution of All Update is: 5.24ms
Avg Time of execution of Game Scene World Render is: 1.50ms
Avg Time of execution of Game Scene Render Light masks is: 2.17ms
Avg Time of execution of Game scene total is: 10.36ms
Avg Time of execution of All Render is: 5.10ms
Avg Time of execution of Game Scene Render Lights is: 0.41ms
60 fps  Who, Me? Waaagh!
Level 0

View Profile
« Reply #2 on: October 03, 2019, 12:17:01 PM »

DevLog II - Light

This past week...uhh month.. I've worked on the lighting for the game. For the game lighting is one of the most, if not the most, important aspect of the visual style of the game.

I had some ideas for what I wanted the lighting to look like, I experimented at the very start with ray casted light but it was just too time consuming for a real time application, especially one that needs to run smoothly on mobile.
Throughout the optimizations it was clear to me that there needs to be a lot of work on making the light look beautiful and perform fast, So I had to get pretty much everything baked into the scene. There are a few dynamic entities in the game but I could handle them using real time shadows.

At first I started my research on the focus of making the light look gorgeous without
worrying about how costly it would be..and I ran into this: ZEN PHOTON and Tantalum. It blew my mind, and I immediately wanted that in my game, imagining the light to be ray traced bouncing around creating correct shadows and ambient lighting in a space environment.. Who, Me? So I set sail into that land.

This is my journey into making the final light(Really Realllllllly hopeful it is..) of my game.

Part 1 - [Not really holy shit]Zen Photon

How hard could it be? Just shoot some rays, light them up that's it..My first try was to shoot rays in a circle, check collision, get the distance, light it up appropriately:

Not really zen photon tho..
So I read about it a bit and started doing it like that technique. Shoot a really huge amount of rays in random directions, filling up a histogram and scaling it using some exposure algorithm.
My second try:




And I ran into the biggest problem with this technique..noise.
So I thought my two options were either to have a fixed amount of rays and gaussian blur it after we reached that Or shoot a really really huge number of rays until I get the smooth looking result of zen photon(which btw needs about 200-400k rays to start looking smooth) I could barely shoot more than 10 a frame, and I needed a lot of lights so I went for the blur solution:

It's way too blurry, and no matter what algorithm I tried and different weights for the gaussian the result was either too blurry or not enough blurry.
I took a step back and thought in a different direction, the line drawing algorithm. The lines were drawn without AA and I thought that could be a good solution to the noise issue, And I tried that and blur:

Still it just looks off, very off not even close to what I expected, So my last resort was to TRACE. LOTS. OF. RAYS.
This is a result after 200k rays:


This is the closest I have gotten to making it look like how I wanted it to, the cost of tracing was pretty large, which honestly wasn't a big deal because I could bake the results, only the problem was that as the levels get bigger so are the lights amount. Waiting for these levels to bake the light, and then render all those textures meaning that I had to write extra tools for that and every slight movement of one light could mean a rebake..It just seemed not worth it for the result I have gotten..And I left it.

Part 2 - Volumetric light

I think for me one of the most gorgeous examples of light in games are in INSIDE and most recently RDR2. The use of volumetric light, and fog just creates a gorgeous environment in my opinion, So I wanted just that, Volumetric lights!
I went into paint.net cranked up the zoom blur, added some clouds, added some shadow polygons and voila:

Now this looks good!
But something was missing..something felt too flat for me, we need..we need...DEPTH.

Part 3 - Normal Mapping

I remembered I saw a game that used normal mapping in a 2D game, and it looked really good, The Swapper is definitely one of the better looking games that use that technique.
Why not try it? These were my attempts:

Well this is interesting but feels a little bit out of place. So I mocked it up with volumetric lights and fog:

Now this is what I want!

Part 4 - The Finale

After a few tests in paint.net I went into Trello and broke it all down into tasks:

For the tech:
  • Material manager for the different materials in the game.
  • Create an additional layer in Tiled for the hand crafted shadow polygon that will be used for mitigating escaping light in interior levels.

Examples of the layer:

Without shadow masks

With shadow masks

For the lights:
  • Render for every light its light mask(The volumetric light texture)
  • Render the clouds with multiply blending.
  • Render the light sprites.
  • Render the dynamic shadows, only for the dynamic entities in the game.
  • Render the scene using additive blending.
  • Render the scene using additive blending.
  • Render the shadow masks which are just blurred shadow textures for every entity. I haven't used this step in my final light demo but this sometimes looks good for the right entities.
  • Render Different Emissive effects, like Lens flare.

Light Masks:



And now draw the rest of the owl:


In action:

Well this was a bit long, hopefully all the other tasks won't take that long haha.

Level 0

View Profile
« Reply #3 on: November 02, 2019, 01:39:44 PM »

DevLog III - Background / Script System

Hey another month! I am pretty sure this was supposed to be a like a week-long feature but like always with the progress of the game I finish 95% of the feature and then just refactor the code and try to make it very accessible for myself in the future.

Anyway the two most important things that happened in the game are Background/Foreground (which meant reworking the whole layer order system I had to support instancing at different layers) and a script/cut scene system.


This was implemented very fast but I had some issues with the way I set up my rendering chain:

The way the new shadow system works is there is a step after the light masks are drawn which removes the parts where the light shouldn't reach, I call this occluder masks. And this happens in a separate framebuffer.

If I draw the background before the occluder masks, the buffer overwrites everything and we have no background. If I draw the background in the buffer, the occluder masks remove parts that I don't want from the background.(image1) 
I need a way to both get the light masks occluded and have a background. And I also didn't want to have a separate framebuffer..Solution? Stencil buffer.
Background gets drawn as usual -> the occluder masks gets drawn into the stencil -> now render the lights with stencil test -> disable stencil test -> continue on.

Recently I started using RenderDoc and Nsight, which are both super cool for getting profiler info from the gpu and debugging draw calls!! (Which was something I never did in like 3,4 years that I developed in opengl haha)

Getting Nsight to work with libgdx was a breeze, just run the jar through the jre (not that jre) in Nsight and done. This was super helpful in debugging the stencil buffer, I spent like 5 minutes(TY Nsight <3) figuring out why my stencil buffer didn't work, Apparently Libgdx doesn't give you a stencil buffer in the initialization and you have to explicitly tell libgdx you want a stencil.

Yay Nsight:

Final background:

And I collected a bunch of public domain pictures from NASA and SpaceX, was fun Smiley

Script/Cutscene System

I wanted to have a system which tells an object a set of commands and makes him execute them in that order with tweens and callbacks. I stumbled upon Universal Tween Engine
Within like an hour I set up a very basic system which did exactly what I wanted it to do. I've done what I described in the Timeline the Tween Engine provided. It's really well written and easy to implement so shout out to the dev!
I wanted an external way to create these timeline so I wrote a little script file and a parser which I can load and reload on the fly, it looks like this:

// Set ship initial position
set (XY)
target (700,200)
// Pause for a second

// Move ship to 0,200 (x,y) in 1 second using bounce out ease function.
to (XY, 1.0)
target (0,200)
ease (Bounce.Out)

Layer system

Last thing, what the engine lacked for a while is a render order in an easy way, basically everything was drawn in the order with which they were added, I had some control over the order but it was for a very specific reason. I redid the whole system and now I had objects drawn into any layer I wanted and being batched to maximize performance.

So here is the final gif with the background, objects at different layers and the universal-tween-engine timeline:

Honestly these "updates" are taking way too long and it's mostly me procrastinating or over thinking or just not having the time to develop the game. I want to try a different approach to my progress. I want to create a board for every week until the end of the year and get the game as polished and as close to the final product as I can.
The plan is to release it around January but with the current pace this will take "Manifold Garden (btw Holy Shit go play it, it's phenomenal!) years" for such a simple game.

Thanks for reading!

Level 10

This avatar is so old I still have a some hair

View Profile WWW
« Reply #4 on: November 02, 2019, 02:11:59 PM »

Love reading technical stuff. That Tantalum link blew my mind! It's not exactly real time (for game purposes, for people doing architectural/animation rendering they consider that real time) but pretty cool nonetheless. But it really shines (pun not intended but welcomed) when you have refraction objects there.


Level 0

View Profile
« Reply #5 on: November 03, 2019, 05:41:49 AM »

Love reading technical stuff. That Tantalum link blew my mind! It's not exactly real time (for game purposes, for people doing architectural/animation rendering they consider that real time) but pretty cool nonetheless. But it really shines (pun not intended but welcomed) when you have refraction objects there.

Thank you! I love reading technical stuff as well (You give a lot of details and gifs in your devlog which is really fun to read)
Tantalum and Zen Photon blew my mind too, I also read the blog posts of the devs, they both know their shit haha. Really fantastic technical rendering stuff, it was really amazing that it ran in the browser.
Level 0

View Profile
« Reply #6 on: December 28, 2019, 08:26:27 AM »

DevLog IV - Dialogue + Cut scene systems

And the week has turned into a month.. Facepalm
This time I have completed one of the things I didn't want to invest a lot of time in, but turns out it requires some thought and a clean structure.


The thing with dialogues in my game is that it requires quite a few different formats:

  • 1. Text that appears at the start of some levels, some kind of "Narrator" that explains or sets the tone for what's about to happen in the level. This is a collection of lines that needs to run line by line, without the input of the player, until it reaches the end and fades into the level. This is what I call line by line text. Also when all the lines are visible at the end I want to simultaneously lerp all of their alpha to 0.
  • 2. NPC Text that runs line by line automatically in cut scene situations where the player has little to no control.
  • 3.NPC Text that runs line by line with input, the text needs to start automatically, can be skipped to the end of the sentance with a button press and waits for the player input to continue to the next line.

On the surface this is standard shit that every game has, but I wanted to incorporate the tween system I had for these types of dialogues.

The first thing I started with was the text that runs line by line automatically, this is how I define it in my script:

    textBox(x:500, y:500,lineSpacing:40, alpha:0, type:LINEBYLINE)
        text#1(string:Welcome to ES#1)
            set (Alpha);         target(0);
            to  (Alpha, 2.0);   target (1);
            set (Alpha);         target(0);
            to  (Alpha, 2.0);   target (1);
                to  (Alpha, 2.0);   target (0);
                to  (Alpha, 2.0);   target (0);

Which does this:

The second dialogue option is a direct result of the first, all I need is to define the text box for an npc and the text will run in accordance to the script timeline.

Third thing is the npc text that requires input, this was done with the same system but with a different enum for the textbox definition. In script it looks like this:

npc_text#1(string:The quick brown fox jumps over the lazy dog, charSpeed:0.2)
npc_text#2(string:Woof, charSpeed:0.2)


There were a lot of different nuances I didn't take into account when approaching this system, like smooth text, alignment, different tweens, dynamically creating this object from the script file. But this was the final hurdle I had before making all the final content for the game, so I am really happy about that! This week (really really reallllly) I'll try to complete most of the cut scenes and dialogues that are in the game.

That's it for this update, Have a good new year and Happy Holidays everyone!
Level 0

View Profile
« Reply #7 on: April 04, 2020, 11:46:11 AM »

DevLog V - Content Complete + Boss Fights

I. HAVE. TO. STOP. WRITING. A. WEEK....It has turned into 4 months!.. FacepalmFacepalmFacepalmFacepalm
Honestly I wanted to write several devlogs But I just felt it was boring work and there wasn't a lot to show.
But....the game....is.....CONTENT....FUCKING....COMPLETE*!!!!!!!!
(*Complete - Except the very final gameplay cutscene)

I've worked a lot on the writing of the dialogues, there aren't a lot but they still need to make sense and be well written. Also the cutscenes which contain these dialogues have all been improved and have a better flow inside the game. After that I've mostly invested my time into making+improving the boss fights. So I'll go through each thing I've worked on.

Improving cutscenes

There were a lot of problems with the cutscenes, mostly with the way everything would move and activate.
Initially the entities wouldn't move inside the cutscene. Everyone would just play their lines and the game would continue on. But then I needed a cut scene where the entity would say a few lines, then move to a certain position and then activate something inside the game. I started with giving fixed x,y for the end positions..but then there would be several locations, or the map layout would change. Clearly not the best approach.
So I've added support for beacons. Working with an external editor (Tiled) I've set-up several beacons and could move my entities to these beacons during cutscenes.


There were also improvements in the way I was handling textboxes, the previous system would just be, either this textbox can be skipped to the next line with an input, or you just have to wait for it. Now it supports both.(TECHNOLOGY  Shocked)

Boss Fights

Spoilers ahead if you care:

There are 4 encounters with the boss in the third chapter. Each encounter is a bit more unique and requires you to solve the "puzzle" in some kind of way.

The first behavior of the boss is chasing you and shooting. I've started with placing beacons along the path of the chase and making the boss find the closest beacon to the player and move there. Problem was the boss isn't that fast and can't keep up with the player which made the boss get stuck inside panels, meteors, glass etc.. I still didn't want to go A* on this because I wanted it to be simple and not computational heavy.

I've settled on a queue sort of solution for this, basically as the player progresses through the level
every beacon that is close to him will be put into a queue for the boss to follow. (will be limited to 5 beacons and will not add previously added beacons) works quite well for chases.

Next there are unique fights with him, the above way wouldn't work as the boss would start following the players route too much and it would look very odd. I needed a better solution..A*. There would still be beacons but the A* will now find the right path to the beacon instead of following the players path.

Now that we have the boss follow/chase/shoot we need a way to defeat him. The first fight with him is quite simple you just need to pull him towards the generator 4 times, which destroys it and allows you to further escape.

The second fight is kind of the same just with more generators but this time you have to pull him out of the shuttle and close the door.
The third and final fight is a surprise Smiley

Also here's an image from one of the boss fights levels in Tiled:

The development has entered the final and probably the most important phase, POLISH. From now on I'll be working strictly on polishing everything in the game. From the most basic thing to the most/least noticeable. I'm quite excited about the upcoming development right now..(Honestly it has been a while since I was excited about the development of the game..)
See you next time and of course stay safe!
Level 0

View Profile
« Reply #8 on: May 02, 2020, 08:30:24 AM »

DevLog VI - Gameplay UI

Hey Smiley
This month has been all about finishing and polishing in-game UI stuff.


I've decided to handle the Oxygen UI by separating it into two parts, or two canisters, and each canister will have it's own animations and tweens.
Oxygen is the first resource you have to keep a very close eye on, and the UI should definitely help you with that. There are a few things happening in terms of animations:
  • When the oxygen has been refilled both the canisters shake and flash white indicating that the oxygen is now full.
  • Once the oxygen reaches 50% only the second canister shakes and flashed red indicating that.
  • Once the oxygen reached below 40% the second canister starts shaking and flashing red picking up speed as the oxygen gets lower and lower.


Toxicity (From Amonia clouds not CS:GO games..) is the second thing that's introduced and you'll have to keep an eye on. This is pretty similiar to the oxygen animations.
  • Once the toxicity picks up we lerp the alpha to 1
  • Above 50% we start shaking the canisters and blinking red.
  • I've made the toxicity tolerance a bit higher than 100%(120%) so the UI has a little bit more time indicating you are in deep danger.
  • For the toxicity to wear off you need to wait a certain time, when that time passes we decrease the toxicity. The start of the decrease is indicated by a flash.

Jetpack + Fuel

Jetpack is a mechanic that is introduced rather late in the game, to activate it you'll need to press and hold on the player and drag it to the desired direction. This is indicated by an arrow which doesn't have too much animations except alpha lerping.
Jetpacks are powered by fuel apparently so we need to indicate that with an UI as-well. This also follows the same animations as the oxygen. Two canisters having unique animations.

I've also been busy participating in LD46, You can check my game out here: RestoPlane

Next I'll be working on particles and more animations. Seeya :D
Level 0

View Profile
« Reply #9 on: May 31, 2020, 12:29:22 PM »

DevLog VII - Gameplay Polish and Level selection screen

Yo  Coffee,
I've been pretty busy this week and had a lot of time-off on my hands (Mostly because of the current situation), so I actually got more progress in.

Hook impact

The numbre uno thing you do in the game is hitting panels with your hook, so obviously it has to feel juicy and satisfying each time a hit is registered.
I've started with a simple tween scale that scales the panel attachment to the size of the hook, which already was fun, then I've added a white flash to indicate a hit has been registered and finally particles!

Frustrated programmer blah blah blah:

After that I've tested the game on my phone and noticed a harsh drop in fps, first I thought it had to do with the way I implemented particles but then upon investigating, for a couple of days, it had to do with all the new effects, basically nothing was batched correctly and render-calls are the biggest pitfall in performance in mobile as I've noticed, so it was back to working on engine code yayyyyyyyyyyy

Also if anyone decides to make a game in LibGdx bare in mind that if your game isn't superrr simple (you know flappy bird kind of simple) strictly engine-code will take you a longg time, LibGdx is a very strong low-level framework which does provide you with some classes that wrap the low-level code, like Sprites, SpriteBatch, ParticleEffect etc.. But if you want anything that steers away just a bit from what the high-level class does you will need to rewrite/add/update a l-o-t of code. Like adding an extra vertex attribute to the spritebatch...
Honestly the thing that takes the most time during development is/was content creation (level design/dialogues) and engine code. I still <3 LibGdx tho Smiley

Ok back to cool shit.

Next I worked on the visuals of the hook, both the hook itself and the hook - line.

I rendered the hook line using dashed lines which looked awesome and also each section of the line has an individual color that indicates how close you are to the max length of the hook.
The hook itself was just a little animation which I played a bit slower so that you will see how the hook "clangs" on to the attachment. Also I lerped the angle of the hook bc it just looks cool.


This is a space game after all which means being pulled in a certain direction will also apply angular velocity on you, So I've added something that roughly looks like that, still WIP but pretty cool and adds a bit more character to the player.

Level Selection Screen

The Crème Brûlée of this Devlog is the level selection screen..ahh now it's getting to be a real game! I only need to implement a menu-screen and I can start counting the billions.

Anyway.. this took some time. First I didn't want it to feel like a generic level selection screen which just displays all the levels and you can click away.
The final idea (I implemented maybe 75% of it for now in terms of functionality) is to have each chapter have it's own unique background and music, basically once you scroll away the screen should change accordingly and the shuttles as well indicating what emotional state or story element the player goes through in that level. Nothing fancy of course in terms of gfx but something small like a broken shuttle indicating a fragile emotional state will go a long way.

This is a thing I like that some games do these days, have the menu represent the story moment you are going through. This is the first screen and introduction the player will get, so even the smallest effort besides the bare-minimum will go a long way. Honorable mentions: The Last Of Us (The broken window / music and the scrolling sfx just really sell what kind of emotion the game wants to deliver), Flower and..umm I can't recall anymore, reply or DM if you think about more games that do this.

I couldn't place all the levels in one screen to achieve that, so what I implemented was that all the levels will be placed horizontally and you will scroll through them.
Right now I've only got the bare minimum to make it function, smooth scrolling, border clamping, Chapter separators, Levels numbers, Fade to dark once you click on a level etc.. But the final touches and polish will happen later in development, or in the last polish run.

Next on the agenda is....more polish! and also adding a menu screen! Seeya Smiley
Level 0

View Profile
« Reply #10 on: June 14, 2020, 01:39:44 PM »

DevLog VIII - A ton of shit!

Hey!  Coffee,
Maybe my most productive two weeks since the first 3 months of development on this game! So I'm pretty happy about that. I'll throw a few words on motivation below but for now, THE GIFS.

Camera polish, panel impact and animations

Hooking onto panels does require you colliding with them, meaning you do it quite a lot.
So let's polish it!

First of all Dust Particles on impact:

Second of all I wanted to add a bit of a shake to the camera once you hit a panel. I was planning to refactor and polish the camera for quite some time so I took it as an opportunity to do that.


Dynamic Zoom in/out, based on velocity: ( Had some issue with this because of camera/lighting calculations culling but got it sorted )

Targeting further than the player based on velocity:

And finally subtle screen shake in the direction of the hit!

Also I've added an animation to the shuttle door, drew the normal map for each frame so the door looks ok with lighting during animation.

But one thing I stumbled with this is that the shuttle gets drawn behind the player, and because the door is part of the same sprite then the door appears behind the player. Solution was easy just animate the door separately.
But here's a little catch, If I animate the door separately I'll need to dynamically sort it during the closing frame, no bueno in terms of performance. So what I did was I kept the shuttles door in the animation until the closing frame, and left it in that frame for the following frames, then I animated the door in a separate sprite and I play them both in sync! Worked really well.

Restart Screen

Add to the things that should've been added ages ago is the restart screen!

Had some nasty bug with that that I hunted for 3 days on/off, eventually it was a memory overwrite problem, one line removed and boom 3 days to the trash...But it was satisfying finding and squashing the mofo! anywho..

Save System

This....THIS IS A REAL FUCKING GAME NOW. It can save....holy shit.
Jokes aside this was honestly superr easy to implement, thanks to LibGDX Json classes and Preferences this was implemented quite quick. 
Not much to show but trust me this shit loads and saves really good, so here's a GIF of the encryption keys per level and how many you collected overall. Plus Locked levels are faded out.

Lighting rework

Man this was annoying me for quite some time. Ever since my lighting blog shit had only gone downhill, I've removed shit to test performance and didn't turn it on after and just kinda forgot about a lot of lighting things, normal maps were all weird...Overall I was just was focused on other stuff and didn't pay attention to how everything was slowly breaking..life huh?..So I've decided I'll dive in and see what I can pull from the depths:

Shadows are now better, more performance friendly, and they fade in and out without hiding the game.

New normal maps for the panels/shuttles etc.., still need to go over all the other stuff.

New lighting parameters for some levels: 

But now get this, I was using a Paint.net plugin for the zoom blur effect on the lights, when I started using it, it provided with fantastic results but it summed all the pixel colors in the ray dir, meaning it would average white pixels with dark ones creating a darkened image on the edges. What I needed was only the lighting part( The transparency in this case) to blend with my image. When I made the maps I said no prob I'll fix it later it's probably something easy to do..well no..I tried for like 5 hours but just couldn't get to a nice result. But then it hit me, I remembered the guy posting the source code of the plugin, I went on the forums, copy pasta + 2~hrs research on how to make a paint.net plugin and voila I had an image with only the transparency!




Quick note on motivation: I've stumbled onto a video of the creator of The First Tree, where he talked about how he finished his game even when he hated it. It was exactly where I was, he even talks about how a project stops being fun super quickly..honestly that's the most amazing part about solo indie devs, the motivation and determination to keep going and finishing a game is admirable.

Basically what I really liked in the video is the idea of not having a 0% day, this isn't a new concept by any means but it was something that just slips away over time. I started making excuses to myself after work, "I'll get it done tomorrow" which all rolls into the weekend and halts the progress of the game. So for the last two weeks I've decided to not have a 0% day, I wanted to at least have something small done every day, even ~2hrs a day are a lot when you focus on small tasks.

Link to the video:

Next on the agenda is....more polish! And also adding a menu screen! Seeya Smiley heyy..I feel a deja vu..
Level 0

View Profile
« Reply #11 on: June 26, 2020, 02:58:31 PM »

Hey! Sent you a personal message but thought I'd reply here too in case you missed it. I make ambient music and would love to help you with the soundtrack for this game. I really like the atmosphere of the screenshots I've seen so far and would love to add a musical element, here's an example of my work: https://soundcloud.com/user-815871901/cult-of-world-drowned
Level 0

View Profile
« Reply #12 on: June 27, 2020, 03:59:03 PM »

DevLog IX - Not A ton of shit!

Productivity continues...sort of.. even though I was busy playing some brilliant games + work stress + personal
shit..but I just have to finish this game.

I'll keep the blogs shorter, GIFS are worth like.. a lot more words  Shrug

Visuals Improvements

I've worked a lot on making the fire feel like part of the world, so animations on the fire + particles got the job done.

Player also has gotten a long overdue rework, this is only pass 1 but animations + normal maps are in place.

Polishing and mechanical fixes

There are now oxygen areas, which you can be in them without losing oxygen. This is for some tutorial levels and cutscene moments which happen inside the shuttles.
UI prompts are in for when the game requires a player interaction to continue the dialogue.
Also animated a door that opens once a certain cut scene is done.

Last thing were an addition to the save system, in the game there are some blocked levels that require encryption keys, basically collectibles which you find in the game. So I've finally added encryption key locks and opening them.

Next on the agenda is...Polish polish polish...polish..polish..polish..polish..polish..polish..

Hey! Sent you a personal message but thought I'd reply here too in case you missed it. I make ambient music and would love to help you with the soundtrack for this game. I really like the atmosphere of the screenshots I've seen so far and would love to add a musical element, here's an example of my work: https://soundcloud.com/user-815871901/cult-of-world-drowned
Thank you very much for showing interest in the game! I really enjoyed listening to your work, it was amazing. Let's talk in DMs Smiley

Level 0

View Profile
« Reply #13 on: August 01, 2020, 12:04:40 PM »

DevLog X - Chapter 1, Polished AF

I've decided it's time to start getting chapter 1 playable+polished, I wanted to get as close as possible to the quality level I want to ship the game with. (hahaha quality level in a Mobile game tf is wrong with me..)
Atmosphere has always been important to me but polish kind always was on the sidelines, for me it was all about mechanics/functionality first polish later, As I've started to realize it shouldn't be the case for my future projects.

Mechanics do come first but polish right after, the hook impact should've been worked on immediately after I implemented it, tested and liked it. I think that's my biggest lesson from this project...and working with existing flexible engines....and work with an artist...

Anyway I've been really busy and have made a lot of progress on the polish of chapter 1..which also applies to like 75% of chapters 2 and 3. ROLL THE GIFS.

Visuals Improvements

*All* the shuttles in the game have proper animations and fitting visuals:

Player has gotten more visual improvements as well as all the other NPCs:

Hook attachments and fire attachments are now blended differently to show that there is a hook attachment there:

Glass visuals and glass breaking are in, looks pretty sexy eh?

Meteors Visuals + normal mapped material:

Encryption key visuals + animations:

Gameplay Tweaks

My friend has been helping me with QA for the game, and he noted how he didn't expect the fire attachments hurting you when you didn't hit them, which made a lot of sense. This made a big difference in the difficulty and now it's a bit more enjoyable to play levels with fire, as you are blaming yourself more than the game Smiley

Another thing that was bothering me were the battery mechanics, I am pretty sure I haven't talked about them all but basically some shuttles in the game will require a battery to power so it becomes a little escort mission with the battery, thing is beforehand the only way you could manipulate the battery was by pulling it with the hook, which made sense mechanically as this is one of the few ways you interact with the world. But this started to bother me because most of the time the challenge is to control yourself and now you are adding another element of difficult controls so you need to manipulate two entities, and one is difficult enough.

At first I've switched the mechanic so when you get close to the battery it will auto-attach to you and you can now focus on the primary challenges of the game. But a lot of the levels were designed to pull the battery from a distance and not you getting close to it. I started reworking some levels but then I thought why not just do both, You can pull the battery if you want to and once it gets close it will auto-attach and you can continue playing..it worked! So this is now the final battery pulling mechanic:

UI + More Visual Improvements

Restart Button, it's ugly but it works!

Ok I've finally got a main menu in! It ain't much but it's finally in and functionalish..woohoo

Another thing I wanted to do for a while is a level end score scene, the game is mostly a puzzle/story based game but its also really fun getting thought the level as fast as possible, so this adds additional replay value to levels.

And the last thing I worked on for quite a while, mostly because of my OCD, is a transition screen. Basically I wanted a smooth transition between some levels. There are still a few pop-ins that I am not really happy with but overall its good enough. Take a look.

Next on the agenda is...Polish polish polish...polish..polish..polish..polish..polish..polish..

Oh and getting chapter 2 fully polished!
Pages: [1]
Jump to:  

Theme orange-lt created by panic