MagiMas [Lexaloffle Blog Feed]

Swing It!

Sun, 30 Aug 2020 15:27:08 UTC

Controls:
Z/C to jump and let go of the rope
X/V to attach the rope (only works if the connecting line is white, otherwise you're too far away)
Left/Right to swing on the rope (and run on the ground)

To disable music, press X/V on the title screen.

Update 01.09.2020:

Uploaded a new version, now with two game modes and three difficulty settings for each mode. Highscores are saved individually for each mode and difficulty combination.

Game Modes:

Normal

The failure line is locked to the score line and always a fixed distance away. The harder the difficutly, the closer the failure line to the score line

Speed

The failure line moves upwards every frame. The harder the difficulty, the faster the movement.

Original Post

Hey everyone,
I started this cart nearly a year ago but finally had the time to bring it to a state where you could actually call it a publishable game with a start screen, high score (including saving the high score between sessions), music and sfx.
Originally, I just wanted to try to get a good physics code working for rope swinging for some hypothetical sidescroller but then turned the test into a small arcade game.
The highscore saves the highest point you reached, you lose if you fall below the striped yellow line. The screen loops around in the x-direction, so you can exit on one side and enter on the other. The anchor points are randomly generated each time you start a new game.

PicOrbit

Thu, 19 Sep 2019 18:58:24 UTC

PicOrbit 1.0b

by MagiMas

[Click to Play]

You are the god of this planet, unfortunately your powers are limited to the control of gravity in this patch of the galaxy. Do everything in your might to keep the planet at temperatures that can sustain organic life. To guide you, the habitable zone of each system is shown in green on the playing field.

Remark: the solar systems are auto-generated from the seed given at the start of the game. I tried to make it so all generated solar systems have a good starting position, but if you encounter a particularly bad system just restart with a different seed.
Also: After hitting start in the menu, the game may take a while to actually start. The calculation of the habitable zone is not very optimized and takes a while, so just be patient, there's nothing wrong with your browser. ;)

Controls

in-game:
up/down - Zoom in/out
left/right - increase/decrease force of gravity
x - turn gravity on/off

menu:
up/down - change active menu items
left/right - change value of active item
x - press button

Post

Hey everyone, a few days ago I posted here in the WIP section a basic gravity simulation. At that point I wasn't sure if I'd progress much further on that, but since I'm on holiday at the moment, I actually got the time to sit down and turn it into an actual small game.

The goal is simple: keep the planet at temperatures where organic lifeforms can thrive for as long as possible. If your planet gets too cold or too hot, you fail and the game will tell you how long your planet survived.
To give orientation, the habitable zone of the solar system (where you essentially receive as much power as you're emitting and thus your temperature should stay stable) is calculated dynamically at the beginning of each game and plotted via green points. Keep the planet outside of the habitable zone and your planet will slowly cool down, keep the planet too close to the stars and it will heat up.

There are two main UI elements:

The slider in the bottom indicates the current strength of gravity via the red indicator. Left means low gravitational constant, right means high gravitational constant. It also doubles as an indicator whether gravity is active at all or not (gravity can be toggled via x), if the planet reacts to gravity then there is a blue background, if not then not.
The "thermometer" in the bottom right indicates the current temperature of the planet. If it goes all the way to the bottom, or all the way to the top, you lose. To the left of the thermometer, there's a second scale that shows your current heat up/ cooldown rate. If the red indicator is at the green position, you're essentially keeping your current temperature, if it goes below, you're cooling down and if it goes above you're heating up.

Additionally, the planet itself also kinda acts as a UI element, as it will change color based on how cold/hot it is.

In case you're curious: the "ideal temperature" in green is within the code calculated as 300 Kelvin (approx 27°C, no idea how many Fahrenheits, sorry), you lose if the planet gets hotter then 375 Kelvin (102°C, so basically the point where the water on the planet would boil away) or colder then 225 Kelvin (-48°C, no real reason why exactly at this temperature, I just wanted it to be symmetrical on both sides).

Gravity Simulation

Sun, 15 Sep 2019 21:40:05 UTC

Gravity Simulation 0.25

by MagiMas

[Click to Play]

Controls

up arrow/down arrow: zoom in/zoom out
left arrow: show/hide debug information
z: multiply gravity by 10
x: turn off gravitational influence on player

Post

So, this is my second post. This time I'm posting some WIP of a gravity simulation I'm writing.
I'm not sure if this will ever turn into a game, maybe I'll just keep it as a "toy".

If you read "The Three Body Problem" by Cixin Liu and ever wondered how the trisolaran solar system worked, then take a look at the orbit of the planet in this simulation and imagine what it would be like, living on this planet. ;)

This cartridge implements a gravity simulation using a kind of modified newtonian gravity to make the simulation more stable for a simple toy like this.
Right now, the cart starts in "debug" mode and draws the field lines of the gravitational field as well as the current field line at the player position and the current acceleration of the player onto the screen. If you press left arrow, this debug layer is hidden.

The simulation coordinates and the drawing coordinates are decoupled via a global scaling factor. This makes it easy to implement a zoom function just by changing the scaling factor.

If you're interested in seeing different situations, you can easily add more gravitational bodies by calling 'create_body(x_position, y_position, mass, color)' in the _init function. The cart will automatically add this new body to all calculations.

The simulation

Okay, so there's a lot to talk about here, so I'll split this one up into subsections

Gravity Algorithm

I'm using the velocity Verlet algorithm to compute the gravitational acceleration that acts on the player. The advantage of using velocity Verlet is, that it is a symplectic solver. This means that energy, momentum and angular momentum are actual conserved quantities like in real life even over long simulation times. That's an advantage over the simple Euler methods as well as over more complex Runge Kutta methods, making the whole simulation much more stable.

I am however only applying this gravity to the player character, the other stellar bodies are fixed in place and are not updated using this algorithm. It would be easy to implement a full n-body simulation, but for stability and simplicity, I opted to make only the player a dynamic body.

Modified Newtonian Gravity

You might be familiar with Newtons law of gravity. If you're not then just know that according to Newton the gravitational force between two objects is proportional to the distance squared of the two bodies. So if x is the distance, then the force/acceleration will go with 1/x^2.
The "problem" for a toy model like I'm programming here is, that for small distances x<<1 this force/acceleration becomes huge. At that point you're not only running into floating point errors, you're also bound to get a very unstable system where the player planet will be slung out of the "solar system" because the force was so big. To get any kind of stable system, you would have to really carefully tweak the starting parameters of the simulation.

In real life this "problem" is solved because everything on unstable orbits got either slung into the sun or out of the solar system, so now only planets with stable orbits remain. In the simulation I really don't want anyone to wait around for billions of years to find some stable orbits.

So how do you make the simulation more stable while mostly adhering to Newtons law of gravity? The answer is simple: replace the 1/x^2 Newtonian gravity with a modified 1/(b+x^2) with a small b (if you know a bit of math: the shape of this function is the shape of a Cauchy-Lorentz distribution curve). If x is much bigger then b, then this is approximately the same as 1/x^2 but for very small x this b prevents the force from becoming too big (as the biggest possible value for the force is 1/b for x=0).

Field Lines

In analogy to field lines in electromagnetism, I decided to draw gravitational field lines to depict the gravitational force. This is trivial to do, every celestial body added to the simulation also adds 16 points along it's surface as origins for field lines. At those points the direction of the gravitational field is checked, a scaled unit vector along the same direction is drawn with a line command and at the end of said drawn line, the field is check again etc.pp.

To save on resources, this calculation is only done whenever a new celestial body is added. The field lines are static afterwards, so no need to calculate them each frame.

I also thought about representing the gravitational field via equipotential lines, but the computational expense to solve the implicit function would be much bigger, so I decided against it.

Race 1.0

Sun, 15 Sep 2019 18:03:40 UTC

Race 1.0

by MagiMas

[Click to Play]

how to play

Use z to accelerate and the arrow keys to turn.

Post

Hey everyone,
this is my first post here, so hopefully I'm doing everything correct.

I discovered PICO-8 around two weeks ago and was intrigued by its design philosophy. As someone who is only interested in Game development as a hobby, I love that basically all tools needed for developing a small game.

So I've been playing around with the program for the last two weeks and decided that the best way to learn how to use PICO-8 (and Lua, as I never used that language before) was to develop a small game.

The result is this small racing game against the time (as I don't have any idea how to write an AI for a racing game) with two tracks. The gameplay is nothing to write home about but I'm still quite fond of the end result.

In principle it's pretty easy to add more tracks, just "draw" them on the map screen with the sprites. However, I didn't bother to write a code that automates the finish-line or the creation of checkpoints along the track, so those have to be set in code.

Some small things I personally find neat:

Animated audience

Upon loading a track, the game checks for any audience sprites set in the map editor and replaces them with animated audience objects.
The animated audience will slowly bob up and down if the player is far away and will bob up and down fast and throw confetti if the player is close by. The confetti is done using a simple particle system, randomly spawning in particles with a random velocity and a fixed acceleration along the y-direction to make the particles "fall to the ground".
The distance to the player is checked using a modified Euclidean norm (basically n(x,y) = sqrt(x^2 + (a*y)^2) with 0<a<1) that deemphasizes the distance in y-direction. As long as the audience is mostly setup along a horizontal line along parts of the track that go along x-direction this means that the audience only reacts to the player as he's/she's driving past them but the player doesn't have to be super close to the curb in y-direction.

"Destructible" barriers

When the game detects a collision with one of the barrier sprites, the corresponding sprites are are replaced by "broken" versions of the object.

Tire tracks

I used the particle system to draw tire tracks behind the car. Unfortunately handling the tire tracks this way it was too much of a drain on the performance to have them permanent.