Window Resizing

Hello! It's been quite a while since the last update, but I am pleased to announce that a new update has finally arrived. This update doesn't do anything for the actual gameplay, but it still does make playing the game much better. This is because the window is no longer locked into a 500x500 window! You can now resize this to be as large or small as your screen, and it should work. Keep reading to see how I did this.

RELATIVE COORDINATES

It isn't the most complicated idea, it just involved changing the coordinates for drawing roads, cars, etc to be changed to be relative to the size of the window rather than hard coded in. Intially, I was working in a 500x500 pixel window, which was convienent for my specific setup. As such, I would then use coordinates specific to this setup. For example, drawing a square in the middle would have the coordinates be 250,250 in the code. This worked fine during the initial testing phase and for my computer. However, not everyone has the same computer, and even when I tried playing the game on my laptop that has a higher resolution screen, the window was much smaller than ideal.

I had actually thought of this when originally coding the base, as instead of using direct numbers like 500 and 250 for coordinates, I had made SCRWIDTH and SCRHEIGHT variables which held these numbers, and wrote a decent amount of coordinates as SCRWIDTH/2, SCRHEIGHT/2 and others like it. However, these variables were made to be constant, and could only be changed manually before running the game each time, which meant they did not change on a resize event. This made them practically useless.

To fix up this issue, I had to keep track in real time whenever a resize event occurred, and then adjust those variables accordingly. Luckily, SFML has this exact event trigger, and I just set it up so whenever that event happened, it ran a whole bunch of code that just adjusted all the sizes and positions of objects to be in line with the new window. However, to get these adjustments, I ended up inevitably having to do some math. Essentially, everything I had done was based on a 500x500 grid, so I just had to make each hard coded number a percentage of 500, then take that percentage of the new window size. I initially did this the hard way, and pulled out a physical calculator and coded those numbers in, but that was not sustainable and very slow. I later realized that I could just make a function to do it for me, and that made everything much easier. As you can resize not only the width of the window but also the height, I made two functions, one for resizing both sides. These functions were pretty simple, and just took in a coordinate that was for a 500x500 grid:

float Car::getWidthResize(float num) {
     return SCRWIDTH*(num/500); 
}
float Car::getHeightResize(float num) {
     return SCRHEIGHT*(num/500); 
}

These very simple functions made everything easier, and SCRWIDTH and SCRHEIGHT would automatically adjust depending on the size of the window.

In theory, after a bit of manual labor, and replacing every hard coded number with the correct resize function, everything should be fine and working.

This proved to not be the case.

SIDEBARS, REAL WIDTH VS. GAMEPLAY WIDTH, AND SCREEN START

Using pure percentages and relative coordinates would work completely fine-if everyone's computer was a square. As my original window was 500x500, every coordinate and number was based off the fact that the gameplay area was a square, and the whole area was playable. However, as I assume your computer is not square, this proved to be an issue when playing in maximized window mode. I needed to figure out what to do with this new aspect ratio.

I decided to keep the playable area square, and base it off of the height of the window. This made it so if the width of the window is longer than the height, there would be "sidebars" of unplayable area. This is because almost every computer out there, if not every computer, is wider than it is tall. However, this does mean that if you strech the window tall, the game will break. However, I am thinking about just adding a text saying don't do this and make the game unplayable until it is back to correct sizing.

Adding these sidebars of unplayable area proposed a new challenge: What to do with the blank space. I decided I should probably add some graphics like a BTD game, and took the time to actually draw out a design on my computer with a pencil. This was actually really fun, as I had never done any type of art design before. After having this idea, I then moved to Canva and made it look nicer. Eventually, while it isn't super professional, it does look pretty decent, even if I didn't get the ratio completely right and it looks a bit squished. I can fix this is a later update though. Anyway, I had the drawings, and just made a box outlining each side of the playable area, the "sidebars," and then used my pictures as the box's textures. it's not perfect, but I do think it works pretty well.

Another issue that arised with the addition of sidebars was the fact that new cars spawning offscreen would not be spawning in a "negative" x-coordinate, and instead would be spawning behind the sidebar. This required me to have to make a variable which held the x-coordinate where the left sidebar ended and the gameplay area began. This required a "real_width" variable, which was the actual width of the entire window, along with a SCRWIDTH variable which held the width of the playable area. This wasn't too complicated, was actually pretty simple and just took time to think about the way the window would look. With all of this, my resize function, which would be run everytime a resize event occured, consisted of the following code:

void Car::setWindowSize(std::pair<float, float> window, float rw) {
     SCRWIDTH = window.first;
     SCRHEIGHT = window.second;
     real_width = rw;
     scr_start = (real_width - SCRWIDTH)/2.0;
     ...
}

(Now I know I used a pair for the window variables and this is completely useless, but initially those were the only variables and I thought it looked cool.)

This function kept all the variables relating car positioning and window size up to date.

Alright, surely that's all that was needed, right? It doesn't have to be a square anymore, cars are resized and adjusted relatively, there are new graphics on the extra side area, what could be wrong?

Everything.

GAMEPLAY CONVERSION

The way I made difficulty work in the game was by making the timing of score decrease and vehicle speed be very, very specific so it wasn't too easy or completely impossible. When sizing the cars up, I sized up their speed and acceleration, as now there were more pixels that needed to be covered. However, upon testing, I realized that for some reason the cars, when in maximized mode, were moving slower. It was making the score decrease way too fast. This was not good, as I was very confused as to why this was happening. I eventually just decided to accept it and work on a conversion rate.

To find this conversion rate, I had to find exactly how much slower they were going, and the size of the screen I was using relative to the 500x500 grid. So, I opened the stopwatch on my computer, got one car just driving in a straight line, and just timed how fast it took for the car to go from its spawn to the light. I did this test over and over until I got a general idea when it was in the original 500x500 grid, and then did it again in the maximized view. What I found was the car moved 25% slower in maximized than in its original size. So, I now had to make an equation relating these values. I kept track of the size of the maximized square, and it ended up being 1009x1009, which meant it was right about twice as big as a the original square. So, when the window was twice as big, speed needed to increase by 25%. Assuming a linear relationship, as I did not feel like testing sizes in between (I can do this later if I find it to be an issue), I made a variable containing the speed conversion factor with the following line of code:

float SP_CONV_FACTOR = 0.25 * (SCRWIDTH/500) + 0.75;

After getting this factor, I then adjusted the max speed of the cars:

MAX_SPEED = getWidthResize(0.5) * OS_CONV_FACTOR * SP_CONV_FACTOR;

(OS_CONV_FACTOR is used to adjust between working in Linux and Windows)

Upon testing, this was not perfect, as it was still slightly slower in maximized view, but it was much closer together (0.1 seconds or less to go from spawn to light) and was playable.

FINAL CHANGES

After all of these additions, the gameplay itself was all working. Cars resized, driving speed was consistent, and sidebars were added. Now, it was all quality of life improvements and changing text font size and position. This was prettty simple, but still involved a massive block of code that just ran every time a resize event occurred and resized the roads and text. Title screen text was also made to be always readable, no matter which way you resize the window as well.

Overall, this was a pretty small update in terms of gameplay, as theoredically nothing would change from a user perspective on gameplay. But a lot when into getting this working on the backend, and I am very glad to be able to play in fullscreen, as it does look much nicer.

There are a few issues, like the turning cars are not exactly in line with the straight cars after turning, and as said earlier the absence of vertical sidebars, but other than that it is all working pretty smoothly.

Oh, I also changed the theme song to be much less annoying and to be some phonk I found randomly on my computer. I think it goes pretty hard and fits the theme pretty well. (You may still hear the OG theme music sometimes...)

Thanks for reading. I wrote a lot, and most of it was very simple, but I do enjoy talking about the game. Hope you enjoy playing! More updates to come.

... Does anyone else jump in their seat whenever they crash? Or just lose in general? I may have to turn the volumes down...

- dvn