Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Reaction 2D space platformer

A topic by moarvespenegas created Dec 09, 2020 Views: 329 Replies: 2
Viewing posts 1 to 3
(2 edits) (+1)

Reaction is a physics and momentum based 2D "platformer" where you control a ship trying to make it through a derelict space station. 


Try it out here on itch. I made windows and mac builds available but I can't verify if the mac build works. If you experience any issues or if you would like a build for another OS please let me know.

I have been working on this game for 2 years now and have finally decided to do a devlog on it that it's coming close to completion. The core idea behind the game was to make 2D spaceship simulator with realistic controls and momentum. Something that portrays newtons laws on a free floating object and has the player fully control it's motion. 

Originally the idea was to make an open world, metroidvania like game where you explore a large open space station and upgrade your ship while doing it. I planned on introducing small timed challenge sections that you unlock when you get new abilities to introduce players to how they worked. I realized this was too ambitious since I planned to do everything myself and so I scaled back the scope and the final game turned to just be the challenge section strung together into a linear play experience. 

First I created small sections that I linked together but with the scope of the game growing as I wanted to add more features and story these sections were grouped together and got named checkpoints and were then placed within overall packages that I called levels. Levels came with an introduction cinematic where I could dump some explanations of game mechanics or exposition as well as the checkpoints that made them up.  At first the individual checkpoints had victory screens at the end and introductory titles that appeared at the start but I decided that interrupted flow too much and instead had one checkpoint simply switch into the next as you beat it. Now the checkpoints served as entry points into the levels and smoothly continued until the level was cleared at which point the cinematic of the next level would play and the game would end up back at the level select screen.


Checkpoints still retained their old functionality as discrete game levels and still have stats tied to them to track player achievements but now feel as just sections of a greater whole in game.

In future posts I hope to talk about challenges I faced with art, level design, and other areas as well as game updates.

First update for the game.  

This update will not have any large features which are not yet ready. It will just have some bug fixes as well as some control and interface adjustments. Most notably:  

- Added backwards thrusters allowing the ship to accelerate in a backwards direction

- Reworked the radar screen to center on the ship as well as being larger with a smaller frame

- Added an optional restart button that pops up when you run out of fuel

- Removed all gate locks based on orientation

- Cut 2 more checkpoints from level 1 as well as 2 checkpoints from level 2

- Various UI and control bug fixes

Radar Comparison

These changes are part of issues and game design problems that I actually want to talk about at some length so I will be addressing them and how these changes came to be in future devlogs. 

Art and Design Impacts

The art style for the game was generally decided from the start. I wanted to design and draw the art myself and I'm not very familiar with 3D modeling so the art had to be done in 2D.  

I tried some different approaches based on what I knew the gameplay would be - flying around a ship in zero G. I tried to make it a strict top-down perspective but I did not like how it turned out looking. (An example of the wall I tried to make with this.)

I switched to an isometric perspective in order to better show depth and liked this a lot better but it would come back to limit the game. The main issue with using 2D sprites to show isometric perspective, or any really, is that you can't rotate anything. To rotate an object the sprite would have to be completely redrawn. I have not even close enough time to redraw everything from 12+ perspectives so the outcome was that the camera angle became fixed. This made navigating the ship initially harder until the user got used to the controls but there was no real alternative except to switch to a top down perspective and I decided against it.  The original design for the ship looked like this.

 

Controlling the ship was confusing though because the camera did not rotate and it was easy to mix up left and right when the ship was not facing upwards. I thought the issue might be tied to how symmetrical the ship was with even the front and back being very slightly different. My first attempt at a solution was to make the right and left sides visually distinct which I did by making them distinct colors as well as adding some marking. (Also shown the original design for the exit gate which was also drawn from a top down perspective.)

This seemed to help and so the next design for the ship made sure it was asymmetric with each of the four sides of the ship being visually distinct. This helped orient the ship while it was rotating in space.

Of course the ship itself has to be able to rotate as well as anything free floating that it interacts with. To make this work I compromised by having any free floating object, like the ship, be drawn from a top-down perspective and so could be rotated freely.

Other assets were drawn in true isometric perspective and due to the symmetrical nature it was easy to rotate by 90 degrees by flipping after rotation, although some things like cast shadow and shading had to be redone. Still there were issues with some objects that had to interact with the ship, such as the new exit gates. Up to three different "heights" could be necessary per object, where the height is the order in the layer that the sprite is rendered in. To give the illusion of depth some areas had to be behind the ship while others were in front and this order could even change based on what was happening. For instance the hatch doors lower part had to be below the ship however as the doors were closing on top of the ship they needed to become higher than it. This was also true for interactable barriers that needed to be above and below the ship depending on where the ship was.

Drawing the assets was in many ways a serious challenge but it was one I enjoyed tackling and I look forward to making more 2D games using the lessons I have learned from this one.