[1] Spacewar Release [2/2]

This week I learned of my inability to determine the amount of time needed to complete a workload. Specifically, it occurred to me on Wednesday, as I was just finishing up the last main feature before win condition handling. I'd been thinking on Friday how I could have completed the game in the same week as I started, and my mind was quickly drawn to Monday. I can't really blame myself for thinking that, as only having 3/4 the amount of full days to work sounds like a major setback. Seeing as how it took me three days to complete just the gameplay features this week, it seems silly now to think that I could've made the finished product given that one extra day. Though the work often bled into other days, I'll say for the sake of convenience that the goal was to implement 1-2 features a day.

Which goes about as follows:

1. Both ships being able to sprint, with a working meter to display it

Controls pop up for a few seconds after initially starting the game

2. Both ships having a cooldown on bullets, preventing spray 'n' pray

3. A sound effect that increases based on distance to sun

A bar at the top of the screen that swings left or right depending on score

Music that fades in on game start, which also attenuates based on distance to sun

4. Implementing win handling, along with win counters next to each player's bars

For Monday, the plan was to start filling in those bar containers with the bars themselves.

I chose the sprint bars, because I figured that the logic behind it would be simpler than the anti-spam bar. I wanted these bars to change color based on the sprint's actual value, so the formula for the bar's rgb color goes: floor((255-255*sprint)+0.5),floor((255*sprint)+0.5),0

Shortly after, I made the bar's size change according to the sprint value, too.

When the time came to actually test both of these, I noticed something:

(The top two things, left and right, are the bar's rgb value, and the sprint value respectively)

The bar is seemingly stretches from its middle outward, rather than from the bottom upward

Upon asking, this was apparently due to where I set the sprite's origin, so here it is fixed:

The next step was to actually make the ships move, or else the rest of the feature would remain pointless. So then I added separate particle effects for the sprint, along with new acceleration and speed caps for the sprint itself:

(Top values are now the ship's speeds)

Next up was to create the anti-spam feature. Its behavior is unlike the sprint, in that not only does the size scaling go backwards, going up as you shoot, but turns to white and disallows shooting altogether once a threshold is met until it resets:

A few years ago, NASA released "sounds of the sun", which is apparently Doppler imager data processed into an audio form:

I thought it sounded cool, and I wanted to have it play whenever you got close to the sun, but when I implemented it, It didn't seem to have the kick I wanted, so I applied an eq, compressor, and messed with a vst plugin to create this:

Nice and crispy. (a friend of mine had to ffmpeg the audio of these two because wix doesn't support native audio embeds for some reason)

Now, to implement it, I made the volume of the track in db to equal 25-distance/2:

Third on the list, is the scorebar and music.

Given that the score is a single number, which gets negated or added to when their respective player scores a point, I could simply make a sprite with 7 frames that updates according to a score of -3 -> 3. The win condition would trip at either -3 or 3.

This method was chosen over an analogue (for lack of better word) implementation, because I saw that the frame of the bar was 66 pixels across, and with a 3 pixel border, that can be easily divided into 7 steps, with 10 pixels of difference each step.

That, and the music with attenuating volume are shown in the following video:

The video also shows that the frame selected is a product of clamp(score+3,0,6).

The last thing to make this an actual game, is a win condition.

Upon a win condition, some text is supposed to pop up, with it being either cyan or magenta depending on who actually won.

I actually had some issues regarding asynchronous happenings in Construct, because a value wasn't updating before it was supposed to be used, so at some point I just wrapped that value update into a function that I could call before the value was actually used.

Which leads to the current version of the (what I can now call) game:

What I'll refer to as version 3, is now live on my itch.io page:

https://polybay.itch.io/spacewar-clone

Originally, the win text was supposed to bounce around with a fade effect like the engine particles, but that proved too difficult to do given my current knowledge of Construct.

Following the post on itch and as I was typing this, I sent the link to a friend of mine.

After playtesting, he told me a few potential things that could be added/changed:

• Make the sun noise slightly louder, to hear the true wobbliness of the sun

• Make bullet ricochets based on a vector created by the bullet's position and the center of the sun

• Make ships into bumpercars, with similar collision behavior to the bullet ricochets

To end this, here's a basic visualization of the hypothetical overhauled collision behavior:

(The object's path is shown in cyan)