#ffsjam

CHECK IT OUT HERE.

Welcome back, Princesses!

It's your second year in St. Goals and you've all done a remarkable job last year. In fact, some of you managed more than ten Villaintines, a grand feat! I hope you all have the same performance this year too!

Now, before we start this year and I let you go to your assigned Villaintines, let's all state the Princess Code:

I, state your name, would uphold the school's mission to clear the world of evil. By giving love to those scorned and turning those monsters into angels. I will be a representative of Peace, Love, and Tranquility...

The Princess knew the code by heart. She is one of the many in St. Goals who wants to help turn a Villain's life around by showing them that someone out there can try to understand them. That there's someone who just wants to be their friend and show them love.

Also, she failed last year's assignment so this year might just be her chance to achieve something... in apparently, just five days. In which she finds out that everything is just based on stereotypes and her beliefs are not exactly as good as she thinks it is.

Stereotypes: the Villains and Princesses' edition

One Ending but with two variations

Choices that don't heavily influence the story, they are there for a variety of responses. it only matters if you want to be possible lovers in the future.

Story-oriented

Extras section!

Playable in Windows, Mac, and Linux

Cute Character Sprites (?)

Sob stories (?)

Monochrome Backgrounds

A protagonist who tells bad jokes and pick-up lines

A tsundere side character

A dog who hates your very presence

A fanboy who asks for signatures in lanterns

And many more...

The Princess (alias-able: instead of a name, you give her an alias!)

'Don't worry, I'll make your life colorful if you let me.'

A cheerful girl who thinks a lot. After failing last year, and being nagged by her Father day in day out, she wanted to do her best this year.

Attributes:

can sometimes call herself 'The Princess of Bad Timings'

tells bad jokes and pick-up lines

cheerful but might lowkey self-depreciate

The Villain (his name can appear early in the game or at the end)

'It seems unable to take a hint.'

Attributes:

passive

refers to everything as 'It'

stuck in the emo phase

you can probably steal from his house

Credits

After the last post I’ve been working on the mechanic that gives name to the project: Landing. It took me some time to get it right, but finally it is implemented!

Here is how it works:

After a collision of the ship against the planet is detected, the game checks if the speed of the ship is higher than the maximum value that it should have while landing, and if its higher than that, the ship is destroyed.

Now, if the ship’s speed is lower than this maximum value, the ship lands and is not destroyed. This means:

Until now, the ship was in it’s state 1, “Flying”:

Only in this state, the ship is affected by gravity, can be accelerated forward and rotated by the player and can be considered or not as a “collidable” object. (A collision can be detected against the planet or not).

Now the ship transitions to state 2, “Landing”:

In this state, the length and the angle of the line that goes from the center of the planet (The center of the screen) to the center of the ship are calculated, and the ship is moved to an specific distance from the center of the planet. I did this because in my first experiments with landing, the ship always ended being more or less “inside” of the planet after a collision, depending on the speed that the ship had when the collision happened. Now I make sure that the ship is always at the exact same distance from the center of the planet, independently of any variable. The speed of translation and the speed of rotation are made 0 and we…

Go to state 3, “Rotating”:

This part took me some time to complete. After the ship lands, it should be at a certain angle, depending on the point on the surface where it landed, so the ship is always “pointing” outwards the planet.

The problem is that the landings wont always be perfect. I could punish the player and destroy the ship if it lands at a weird angle, but I thought that doing that would make the game unnecessarily frustrating. I decided that the ship should slowly rotate to its right position.

The rotation itself wasn’t the difficult part, but making the program being able to decide if the rotation should be clockwise or anti-clockwise, depending on which one would take less time to complete, took me some time and effort.

After a while, I came up with this:

We have that:

self.rotation is the angle of rotation of the ship.

self.angleC is the angle of the line that goes from the center of the planet (The center of the screen) to the center of the ship.

yS is the “y” coordinate of the center of the ship, relative to the center of the planet.

And the reference system:

Notice how the positive values of “y” are under the “x” axis.

In the quadrants I and II the angles take positive values (From 0 to Pi, right to left), and in quadrants III and IV, negative values (From -Pi to 0, left to right).

Well, after observation of all the different possible positions of the angles in all the different quadrants, I discovered that:

If the ship’s “yS” is positive, we have that if the difference self.rotation – self.angleC is negative (self.angleC > self.rotation) AND the absolute value of that same difference is less than pi (One angle is not more than 180 degrees away from the other), the rotation should be Clockwise.

If the ship’s “yS” is negative, we have that if self.rotation – self.angleC is now positive (self.rotation >  self.angleC) AND the absolute value of that same difference is less than pi, the rotation should be ANTI-Clockwise.

With this information I wrote the algorithm:

 elseif self.state == 3 then--IF IN ROTATING STATE.    local angleSSubC = self.rotation - self.angleC    local maxDif = pi / 32    --If there is too much difference between angles.    if math.abs(angleSSubC) > maxDif then        --Determine if ship should rotate clockwise or anti-clockwise:      if yS >= 0 then        if angleSSubC < 0 and math.abs(angleSSubC) < pi then          self:rotate(dt, 3) --Clockwise        else          self:rotate(dt, -3) --Anti-Clockwise        end      else        if angleSSubC > 0 and math.abs(angleSSubC) < pi then          self:rotate(dt, -3) --Anti-Clockwise        else          self:rotate(dt, 3) --Clockwise        end      end    else --If the ship is already in the correct angle.      self.state = 4 --TO TAKING-OFF STATE.    end

"self:rotate(...)” will be called until the absolute value of the difference “self.rotation - self.angleC” is smaller than the maximum difference of “pi / 32″. After the rotation is done, the game switches to the...

State 4, “Taking-off”:

Here the ship just waits for input. If the player presses the “accelerate” key, the ship becomes “non-collidable” (A collision against the planet wont be detected) and goes back to state 1, where it accelerates (As long as the player keeps pressing the button associated to the acceleration) its way out of the surface of the planet and becomes “collidable” again when it stops being in contact with it.

Well, I hope some of this made sense for you. Now, I am working on the sound effect “engine”.

During the last few days I’ve been implementing more complex collisions, cooler explosions, and the ability to shoot highly destructive lasers.

For the collisions, I wanted different behaviors for different cases:

Planet vs Anything:

If something collides against the planet, it is destroyed an in its place an explosion is created.

In the final game, if the collision is against an asteroid, the player will lose some points, because his job was to defend the planet and he let millions of its inhabitants die. If the collision is against the ship, the player will lose a life.

Asteroids vs Asteroids:

For this type, I programmed elastic collisions. This means, that the total kinetic energy (The sum of the energies that the objects have due to their motion) and the total momentum (The sum of the products of the mass and velocity of each object) that the two Spacial Rocks have before the collision, must be the same after the collision. This means, that the asteroids will bounce off each other as if they were balls on a pool table.

Asteroids vs Space Dust:

The “Space Dust” are the little particles that you see flying around the screen. They serve an aesthetic purpose, and nothing more. These particles are created when:

Each game starts. They are supposed to represent very little, insignificant rocks that are just going around the planet.

The player gives impulse to the ship to move it forward or rotate it.

An explosion is created.

And when they get in contact with an asteroid, they are simply eliminated. My idea is that they just become part of the asteroid.

Asteroid vs Ship:

The ship is destroyed, an explosion is created, and the player loses a life. This is more of a perfectly inelastic collision, where the colliding objects are bound together, instead of bouncing off each other, and kinetic energy is lost. Imagine that the pieces of the ships get stuck into the asteroid. The same could be said about the Space Dust: They get into the asteroid, and after the collision they both keep moving with the same speed and direction. Perfectly Inelastic Collision.

Asteroid vs Laser:

Again, I use elastic collisions. When the laser hits a rock, the program first calculates the new velocities for the asteroid and the laser, as if they were to bounce off each other (Again: Like balls on a pool table). But instead, the laser is eliminated and the rock is destroyed, and an explosion and two smaller rocks (These two smaller rocks each have half of the total surface of the original, bigger rock) are created, and the new velocity that was calculated for the big asteroid is given to them, so after the impact, the big asteroid not only becomes two smaller asteroids, but also they change directions realistically. And, yes, I know that technically this should not be an elastic collision, because after an explosion energy is lost from the system, but for what I want, this is working perfectly.

With the Finally Finish Something Jam 2019 coming to a close, I'm proud to say that Worker #11812 is officially released for web and desktop platforms! This game simulates the grueling 10-hour shifts experienced by the lowly workers from the 1927 film Metropolis.

a little preview