next »

[Chocolate Pinecone]

https://www.rocketshipmentgame.com/

Rocket Shipment is on Steam!
There is also a Gamejolt and an Itch page where the game is available.

I made this game from scratch. This devlog starts off at the very (ugly) early beginning of development

Synopsis

• Name: Rocket Shipment
• Genre: Retro 2D space lander/platformer
• Platform: PC (Windows / Linux)

Description
Rocket Shipment is a fresh take on the old space classics like Lunar Lander, Crazy Gravity, Solar Jetman and Gravity Force to name a few.

Fly, grapple, puzzle and refuel all while exploring caverns and fighting gravity in this physics based delivery game.

If the main levels are not tough enough for you, make your own with the in-game level designer.

Features

• Explore caverns
• Grapple stuff
• Play lots of levels
• Deal with dangerous alien technologies
• Make your own levels with the level designer

Status and technical stuff
At the moment I am developing a demo/vertical slice and am planning to release that Q2 2020.
This game is being developed in C++, using SFML as a base.
I am building a custom engine around this game with the purpose of being able to reuse it later for simple 2D games with collision and physics.

Devlog posts

• Level editor - Basic version implemented
• Level editor - Save button added
• Small GUI update
• Basic GUI screen functionality
• Level editor - Loading levels
• Level editor - Saving levels
• UI screen managing
• New UI screen and close button graphics
• Small improvements
• Overhaul of physics system
• Refactoring to use Verlet and rigidbodies
• Improved Rigidbodies
• Implemented friction
• Crate madness
• Working on new tile collider generator
• Automatic tile generator
• First shot at a title graphic
• Crate grappling
• Cable physics
• Fixed cable length and other improvements
• Cable shooting
• Start menu with localization
• Options, options, options
• Resolutions
• Let there be music!
• Basic options screen done
• Level designer and other updates
• Playtesting your levels
• Under the hood stuff
• Flags and errors
• Crate detection and optimisation
• Sound, Music and Cable control
• Configurable controls
• UI navigation
• Level selection
• How I improved my game aestethic
• Multiplatform support and player feedback
• Death and Revival
• Lives and refuelling
• Linux build and scoring
• Wall blasters
• Breakable crates
• Pre-alpha demo release!
• First weeks of pre-alpha demo release
• New trailer and a little polish
• Finally some well needed polish
• Improving player experience
• First big feature since demo release: Gates!
• Revamping the level editor and cable elasticity
• Last changes for the Steam Game Festival
• Configurable gate speeds
• Drones and locked gates
• Release date has been set!

Extra info
I'm working on this project in my free time, which means updates are sporadic. I will update this blog and all my other channels(gamejolt, itchio, indieDB, twitter, reddit) whenever I have something to share.

Feel free to comment on anything you see, or if you simply want to say hi .[/list]

[Chocolate Pinecone]

Now I can create levels on the fly!
The goal of this editor is to be able to create levels and immediately test them.
I still need to build a save and load function and need to fix the game getting slow when adding too many tiles.

Still it's very nice to now be able to easily change the environment.

[filbs111]

Very nice. I played a lot of Gravity Force 2 back in the day.

[Chocolate Pinecone]

Very nice. I played a lot of Gravity Force 2 back in the day.

Thanks! I'm not sure which version I played, but I remember it was a lot of fun!
This game must have the same feel as that game did for me back then!

[Chocolate Pinecone]

I added a save button to the editor. This way I can save my current level to disk. I already have a system in place to read the file and generate the level out of it.

While creating this, I found out that I had to somehow determine the starting point of the player in the level.
I could make a function to always pin this point to a specific type of landing pad, but I figured it would be much easier and editor friendly to just add a special starting tile.
I still need to add this tile to the editor catalog, but it is already being generated from reading a level file.

Next on the to-do list is a Load button with a pop up window to choose a level.

[Chocolate Pinecone]

Ok, so this change is taking a bit long. One change led to another and now I've been busy creating a basic GUI screen system that can be re-used through the game.
I want the load button to activate a screen where I can choose a level from a list. This list is created out of the found level files.
I'm also setting up a style class to store all the style settings, such as selection color, exit-button size, etc.

As expected, these relatively simple changes take a lot of time because I'm creating engine parts for anything that is re-usable for future games.
In the future the editor should be seperate from playing game levels, but for testing it's very handy having everything combined in one scene.

I'm considering to have the in-game levels hardcoded in the game instead of having them as seperate level files. This way, they cannot be tampered with by players. Otherwise they might rig the levels to be easier or something.

So far the update! I'll keep you guys informed.

[Chocolate Pinecone]

I've now implemented a basic re-usable system for creating, displaying and closing screens/dialogs.

This basic system will be used for the "load level" functionality I'm working on right now.
The general implementation enables me to easily create a screen with a functional close button.

The next step is to populate this screen with a list of levels to choose from.
For this I can re-use the system I made for displaying the tiles in the tile editor. I do need to create custom blocks of text (with maybe an image?) to display the level information that will be listed.

This is how the very basic version looks:

[Chocolate Pinecone]

So it's been a while.

The load level screen is coming along nicely. For now it only shows 2 possible levels to choose from, but the levels that are shown are actually fetched from the game folder and clicking will actually load the chosen level. The base of this screen is built, but needs to be extended.

I'm building all these UI parts in a reusable way. For example, the "load level" screen is using a GUI element called "Screen". This component is solely responsible for a screen-like background and a functional "close" button. It can also provide screen coordinates for other GUI components to use.
The list of levels is made using the "SelectionTable" element. This element is also used by the tile selector in the level editor screen. It is solely responsible for showing textures or other GUI elements in an organised way (with a predefined nr of columns).

For now this "SelectionTable" is programmed in such a way it will always fit it's contents in the defined bounds, resizing its contents if necessary.
I want to extend this element with an ability to enable scrolling, which would cause it to only limit itself to the defined nr of columns.

But before I dive into that, I will create a "save level" screen, which will have a (still to be created) input field and a save button.
The name of the level to be saved can be typed in the input field.

I have to see I really like being in control of everything in the engine! Even though it takes pretty long to get things done...

[Chocolate Pinecone]

I've worked on a text input that is now working nicely.
As you can see I implemented it in a save screen which now saves the current level on disk with the entered name.

Now to update the loading screen with the newest level data...

I also thought about how to implement a system to ensure only 1 GUI screen is active at a time. I don't want to be able to open 10 different screens on top of one another.
Currently the GUI screens are set up in a way where sub dialogs or other GUI elements are drawn depending on their parent screen.
So I'm thinking if I implement a rule where always 1 base screen can be active, then I won't disable myself of having subdialogs on top of base screens, which is good.

I'm really happy with the progress so far! Just a little more work and then the basic level editor is done! That will really speed up level making.
I'm still doubting on what to pick up after this part. Maybe replacing some placeholder UI graphics...

[Chocolate Pinecone]

Managing screens... Something I've taken for granted ever since I knew how to control a computer.

When my save and load screens were overlapping, I wanted to make sure only 1 would respond to clicks. So I came up with a screen manager class that takes care of these issues.

The class provides the following functionality:
- Newly opened screens will be rendered in front of other managed screen
- Possibility of having only 1 screen active at a time, deactivating any other managed screens (indicated with a slightly darker tone)
- Possibility of having all managed screens opened or closed when 1 of them is opened or closed
- Possibility of having 1 screen visible at a time. As soon as a new screen is opened, the others are closed.

I still want to add functionality to activate screens when they are clicked on, but I will leave this out because I don't really need it for now. I must repress the urge to scope creep

I think I will now focus on making a basic level and program some game mechanics, a.k.a. the fun stuff!

[Chocolate Pinecone]

I was getting sick of using that 1 graphic for buttons, screens, options, etc. So I finally made a new graphic.
I made a pretty simple screen graphic and a close button.

I'm not sure if this will be the definitive design, but it definitely already looks hella better than it did before!

[Chocolate Pinecone]

Just a small update.
I've been working on quite a few things. Unfortunately they are not really visible changes, so I decided to not post about them directly.

A small visual change is the new button texture:


Some work i have done the past weeks:
- Improved implementation of spritesheets
- Implemented type sorting of tiles. Now the tile editor can be sorted by soil, platform and special tiles
- Implemented random tile generator that will use a random texture for the selected tile when placed. When I drag a line of bottom soil tiles, it will not place only that single texture in the whole row.
- Added functionality to WASD buttons instead of only using the arrow buttons
- Fixed padding bugs
- Improved functionality for GUI parent-child relationships
- Implemented screen title headers

All in all still a good amount of work now that I look back.
I'm currently working on a scrolling functionality for tables such as the tile editor. Right now I have the code in place for masking out the elements that are (partially) outside the table bounds when user has not scrolled.
Still a long way to go, but after this change I will have made a solid step towards more complex GUI in the game.

[Chocolate Pinecone]

I now implemented basic scrolling!

This really boosts what I can do with UI now. I still need to implement scrolling boundaries and maybe a scrollbar, but this already really exites me.

In this GIF you can also see a few other improvements I made such as the tile type buttons, the new button texture and a screen header title.

Next up, start menu!

[Chocolate Pinecone]

So the physics system I built until now has been pretty much Euler based.
It does almost all I wanted it to do, but the rotational collision response is not what it needs to be and the system is not the fastest.
It's also full of "new" ideas I had back then that are a bit vague and not executed that well. Now that I'm coming to a point where actual gameplay is getting into sight, I want the physics to be clean in place before I start designing levels and gameplay. This means an overhaul of the current physics system and the implementation of something clean and simple.

I've chosen to implement the Verlet way of handling physics. I've started to make changes already, but because the physics are tightly coupled to collision detection and handling, the latter is now broken.
I expect this to take quite some effort and time to implement, but the reward will be worth it. More so because I want to re-use the engine for later games.

[Chocolate Pinecone]

It may not seem that special cause it all looks the same, but I have upgraded my badly coded collider code and have now set up all basics for moving colliders by their points.

Previously I moved my colliders based on the rotation and position of my sprite. This meant that when a corner collides with something, I have to calculated the exact new rotation and position of the sprite, which is a big pain... The new system makes this easier, since I only have to move the seperate collider point that is colliding, which will turn the collider automatically.
A sync function will then afterwards sync the sprite to the current collider position and rotation.

I still have to finish implementing the collision detection and resolution, but here you can already see the systems rotation and acceleration from user input, calculated through Verlet.

[Chocolate Pinecone]

Verlet is implemented. The collision detection and resolution is going pretty well, but I still have some annoying bugs to iron out.

For example, when the ship lays on its side on tiles and is sliding off the last tile in the row, it sometimes falls partially through the tile and then launches itself shortly after...

I also still need to implement friction. But I already have an idea how to do that.

I find the whole collision detection and resolution paired with the rigidbody behaviour the most complicated yet. It's a real challenge to program this from scratch, but I am still very happy I'm doing it.
When the game is done I know I have overcome a lot of complicated issues and have really progressed a lot as programmer.

[Chocolate Pinecone]

The physics are working pretty well now. I've replaced my previous collision detection with a functionality following the seperating axis theorum. This is a breeze to understand codewise and also works a lot more stable than the "check if lines cross" type of approach I had programmed earlier.

As you can see I've implemented friction as well. Once you understand the vector math used in SAT, this is also a pretty straightforward thing to implement (I might post a "how to" on some site if people want me to).

I'm stoked to start testing some stuff with this renewed physics system I implemented. Right now I'm building crates that can be hooked and pulled for transfer later in the game. As soon as I have some working in the game, I can start playing around with them colliding into eachother.

[Chocolate Pinecone]

I'm getting more and more tired of all these problems with physics.

Since the collider for my crate is a bit complicated, the physics system is protesting. I'm probably either forced to throw the complete physics system out and use box2D, or make physics colliders simpler.

What also doesn't help is that my tiles are exactly the same size as my crates, which makes the collision detection hard if everything on grid is exactly lining up and points exactly overlapping other points this way.

Struggles, struggles...

[Chocolate Pinecone]

Left you see the old system which uses a seperate collider for every tile. Right you see the result of the new WIP tile collider generator that generates a single collider for a group of tiles.

With physics issues driving me nuts, I found that colliders that end exactly on borders of other colliders can really mess things up. Having a single big collider for tile groups would solve this issue and also provide a process time boost because not every single tile needs to be checked for collision every frame.

I still needs to test the system thoroughly, but it already works for some simple shapes.
I'll try to explain the inner workings as simply as possible. The algorithm takes a few steps:

1. Organize the tiles of a tile group from top to bottom and left to right.
2. Start at the top left tile and check if (and where) there are adjacent tiles (above, below, left or right)
3. Store the top left point of the first tile as first collider point.
4. Go to the adjacent tile following a clockwise direction (In case of the top left tile this should be the adjacent right tile. If there is no right tile, go to the below tile).
5. Based on the previous tile that was handled and the adjacent tiles of the current new tile, save the correct collider point and move clockwise to the new tile.
6. Loop the previous step until the algorithm ended up at the top left tile again.

All outer collider points should be found this way, and a collider polygon can easily be constructed.

In my case a extension of the algorithm is needed to split the resulting collider in convex subshapes to be able to use the seperating axis theorum for collision detection.


I hope to share some nice crate physics gifs when this is done.

[Chocolate Pinecone]

The tile collider generator is almost working perfectly! I've implemented the colliders to be updated whenever I add or remove a tile.

This proved a challenge because some tile removals must result in a tile collider splitting up in 2 seperate ones and the other way around some added tiles will join 2 colliders together. I'm very proud to have pulled this off with algorithms and ideas that I came up with myself.

There are still some ochestrations of tiles that show bugs in the collider generator, so I'm thoroughly testing all kinds of formations to tackle these.

I'm very happy with the result so far!