Dev Log // Fun Times With Github Copilot, GPT and Solitaire

So I had this idea to build Solitaire using as much AI as I could. This was after reading a quote from an engineer in a github article who said that he tried to use Copilot to build the entire app. I found that concept interesting.

I started using Copilot in October and at first found it fascinating. The way it could almost read my mind and provide me the exact code I was about to type makes me feel like I'm in the future.

I started off by having ChatGPT generate the class declarations for the game (but specifically no code). I would then paste these declarations into Visual Studio as comments and wait for Copilot to generate the code based on the comment. Then, I would create the functions, place my cursor in the blank function and wait for it to generate that code as well.

It quickly got old and tedious. The code was not great. Copilot struggled on the more intricate parts of the game where classes started to really intertwine with each other and it would start making up variables or functions (even with all the relevant files open as tabs). It also struggled to create the graphical side of things, often suggesting code for SDL instead of SFML.

But most importantly; I had no idea what was going on. At all times, I felt like an engineer who had been hired to finish the game as the previous one who implemented everything had left abruptly. The further I got into the making the game, the harder it became to debug.

I ended up scrapping that version of the game and instead took the class declarations provided by GPT and started implementing them myself. I had a clear goal of what the finished game would look like and what I wanted to accomplish in each submit.

This is the way to use Copilot. I've never completed a game so quickly. When you know what you want to write and Copilot suggests it for you (or something very similar), it can shave hours off dev time. And that's not a hyperbole. The key though, is knowing what Copilot is suggesting you. If you can't read C++ or you're relying on it to know what it's suggesting is the right code for that particular section then you will quickly be led astray.

It's not the silver bullet, but it's pretty damn close and I highly recommend adding Copilot to your toolbelt.

As for Solitaire, I'm very happy to have finally created my version of it. It's one of those classic games I've dreamed of implementing since I started programming.

I used ChatGPT and Dall-e 3 to create the initial card designs and then edited them in PhotoShop to create a full deck spritesheet.

My favourite part of the whole process was figuring out how to do the classic "win animation" where the cards bounce down from the top of the screen, leaving a trail of the card behind them. This was the hardest part of the game and even GPT 4 couldn't help. Eventually, I asked some of the rendering wizards at work and they said the original solitaire used the mechanic of simply not clearing the screen after drawing so the previous frame was still there. This took some doing to get working in SFML as it has things in place to update the buffers anyway, even if you don't call explicitly call window.clear().

I ended up creating my own buffers when displaying the win animation, so only one buffer was ever drawn to and not cleared. Then that buffer would be turned into a render texture and displayed on the screen.

This was also my first time using the command pattern to implement the undo feature. 

And that's my adventure with AI and Solitaire! It's pretty much got everything that I wanted to implement; undo, right click add to foundation, drag and drop single and multiple, selected card highlight and a status bar.

Github: https://github.com/l-paz91/SolitaireSFML

What's wrong with it? A lot of hardcoded values. Good luck changing those card sizes or resizing the window and still expecting it to work...

Dev Diary // Adventures with Tetris (C++ Console Window & FLTK)

A colleague introduced me to the YouTube channel javidx9 the other day with the video:

Code-It-Yourself! Tetris - Programming From Scratch (Quick and Simple C++)

I sat down after a gym session one dreary monday night and the 36 minute video took me about 90 minutes but javid had delivered and there was Tetris in the console window in about 300 lines of code. I also really enjoyed the little maths trick he employed to rotate the tetromino pieces. I found the video to be a bit rushed in places and some things cut out so I had to refer to the github repo quite a bit. Some things also went unexplained and me from a few years ago would be quite confused but on the whole; a solid tutorial.

Tetris was on my list of games to clone as it's a classic, easy-ish to implement and rife for tinkering. And tinkered with that initial small program I have.

Console Window

Here is the repo for my "all-in-main" version that I wrote whilst following along with the video. It's not exactly as his code but close enough:

https://github.com/l-paz91/Tetris/tree/main/Console%20Window

++Console Window

I then set about taking this apart and creating a more generic Tetris that could eventually be run using any library. This one still runs in the console window but the input options, rendering, tetromino mechanics have been abstracted to work regardless of what library you're using....in theory.

https://github.com/l-paz91/Tetris/tree/main/Console%20Window%20Modified

FLTK

This is a small lightweight API  that I was introduced to whilst working my way through Principles & Practice. I actually really like it due to it's simplicity and Windows 95 looking graphics. This was the first test to see how portable I'd made my code in the previous exercise.

I started off modifying the wrapper code given in the book Programming: Principles & Practice by Bjarne Stroustrup. I've been meaning to do this for a while; it's not a perfect wrapper but it makes iteration in FLTK a bit faster.

Here's the repo:

https://github.com/l-paz91/TetrisFLTK/tree/main/TetrisFLTK

With that done, I then found a free Tetris block png off the internet:

https://www.kindpng.com/imgv/iwmJJhT_tetris-blocks-png-transparent-png/

I used GIMP to change the hue of it to create 6 other colours.

I then created a simple window with a quit button.

Now I needed to find a way to display the Tetris Board on the window. At this point I already had all of the code needed from the console versions so I created a grey block and wherever '#' is drawn, I told it to draw a grey block instead.

Next was to draw the current piece. This required some tweaking but after some trial and error I managed to get it working without having to expressly tell the individual blocks to draw to make up the shapes (it used the text created in the console versions).

I then started copying over all the update logic to move and rotate the pieces. I was extremely surprised that this "just worked". FLTK does have it's own Keyboard event handling system however, the default windows one worked just fine with it so I stuck to that instead of changing it.

To create the "game loop", I used FLTK's timing system and registered a "tick" function with it. The tick function updates the Tetris board then redraws it. The tick function also handles updating the game tick counter to regulate tetromino speeds and locking them in place:

Please ignore the flickering; FLTK and my screen recorder don't get along.

The only thing left after all this was to print out the score:

And with that I got bored and got the itch to do something else. I will come back to this though as I'd like to do it in SFML next, add sounds and such. I was happy I managed to get a "game" of sorts working in FLTK though as that library is not built for games....and it really shows. It was fun creating helper classes though. I'd like to know why it's flickering so much once the screen gets really full. I think it'd be a good task to delve into Visual Studios performance profiling and debugging options.

EDIT 25/07/2023

I fixed the screen flickering:

https://lptcp.blogspot.com/2023/07/dev-diary-fltk-tetris-part-2.html

LP's 12 Months of Games // Alien Invaders Part 2 [C++ & SFML]

Completed Independently

In part 1, I got a basic game loop going and you could shoot invaders as they descended upon you. In part 2 there's now shields, sounds and a flying saucer!

It's almost there but there's still some bugs and finishing touches such as:

• Background music. The famous "dun dun dun dun" has not been implemented as I haven't managed to recreate the sounds to a satisfactory standard and increasing the step as you destroy invaders is a task in itself as I'm not a sound engineer person.
• The arcade style surrounding and background as well as the CRT shader. A colleague showed me a different way to implement the disintegration effect using shaders so I'll be implementing that as well as messing around with some other shader effects.
• 2 Player mode
• Demo mode
• Taito Cop Easter Egg
• Different Invader shots. Right now they're all just using 1 shot and will fire every couple of seconds or so. That needs changing.
• The flying saucer is every 3 seconds which isn't correct. I haven't figured out from the assembly yet though what the actual timing mechanic is for it to appear.
• The Credit Inserted and Start Game animations haven't been created.
• The states don't really play with each other nicely
• Bugs

I'm shocked that the original developer managed to create this game in a year but not just the game; he also built the hardware that the game ran on. This is a level of engineering that I can only dream of reaching. 

Result:

It doesn't look like much but I'm quite proud of myself for sticking to a project and getting it to a somewhat finished state. That in itself is an achievement for me. I am feeling a bit burnt out on SFML though having done 5 back-to-back projects with it and I'm looking forward to a bit of Unreal and Blueprints for the next project.

This is far from over though. I have a new project now to recreate Space Invaders with as many APIs as I can. Making it that first time though is the kicker; now it's almost out of the way, I can focus on refining the code and then re-implementing it using other libraries.

Code:

https://github.com/l-paz91/AlienInvaders2/tree/main/AlienInvaders2

The code is quite honestly, awful in places lol. But I don't care. I think that's one of the hardest lessons I've learnt whilst doing this exercise; just do it and worry about how shit your code is when it's done. I do enjoy refactoring and optimising but they don't help you get a project finished.

LP's 12 Months of Games // Alien Invaders Part 1 [C++ & SFML]

Completed Independently

So the final game of "Beginning C++ Games Programming" by John Horton was a clone of "Space Invaders". I skimmed the first chapter of the project and he starts talking about Entity component systems, Factory class designs etc and I just completely zoned out and decided to make it myself. 

This took me a while as Back 4 Blood added an offline mode and there's nothing quite like hitting zombies with a baseball bat. Also the Witcher season 2 and Lost In Space season 3.

So anyway, I kept getting annoyed with myself whilst making this game; I was trying to make the code as beautiful as possible right off the bat; which is impossible unless your Bjarne or Scott Meyers or something. I asked many colleagues how they would go about implementing Space Invaders and amusingly, the more senior the engineer the more the answer became "just do it all in main, who cares?"

So, I've written some terribly hacky code that only gets worse as time goes on but I have a game! This is labelled part 1 because it's not finished however, there is a title screen, a game and a game over. It saves the high score between runs and loops after game over so it is a game...regardless of how finished.

I'm quite into the task now and the shields are ready to be implemented, as are the sounds. Then the flying saucer needs some attention as do the shot exploding animations but then I'll have a full Space Invaders clone!

I've given myself a few little extras that involve creating a CRT shader and making it look as though you're playing the game on an arcade machine.

Result:

I'm extremely happy with what I've done so far. I'm really trying my best to make it look and feel exactly like the original. I'm going so far as implementing the same bugs using this site which comments all the assembly:

https://www.computerarcheology.com/Arcade/SpaceInvaders/

There are some issues which you may have already noticed; my game over text isn't displaying and the high score isn't updating. That will be fixed next but the code is in place.

I just really wanted to get something uploaded for this month and I've already learnt so much from attempting to do this by myself. I'm glad I ignored the book as this game is deceptively hard but a great place to start when making a complete game from scratch for the first time.

I almost gave up a couple weeks ago as I find it difficult to find the motivation to finish things. I have about 70 started projects but I thought to myself, the whole point of this challenge is to get better at making games and I won't get better if I don't at least try! So I managed to scrape the code together enough to call it a "game".

It also made me realise that I hate UI programming with a burning passion.

Code:

https://github.com/l-paz91/AlienInvaders2/tree/main/AlienInvaders2

C++ & SFML // Creating The Disintegrating Shields in Space invaders

Whilst making a clone of Space Invaders, I got to the point where I had to make the shields. They are interesting as only parts of them get destroyed when hit by bullets:

The damage done to the shields is based on the type of bullet and where they hit. It reminds me of the old Worms and Lemmings games that have disintegrating terrain due to explosions.

The player's shot and 2 of the invader shots deal the same type of damage. However the "plunger" looking invader shot is the most powerful and deals more damage. Therefore, having the shields as sprites make no sense as you can't manipulate the pixels in a sprite, so I started looking into ways to draw and modify pixels in SFML as well as do per-pixel collisions.

I eventually came across this post:

https://en.sfml-dev.org/forums/index.php?topic=23869.0

This seems super long winded for what I want as it copies the image from the gpu into an array of pixels, then you modify those pixels and then send that array back to the texture. But it's also the closest to how the original game implements the shields (in a way).

I then found this after googling "sfml array of pixels":

https://www.sfml-dev.org/tutorials/2.1/graphics-vertex-array.php

I was able to write a program that can draw individual pixels to the screen:

https://github.com/l-paz91/SFML/blob/main/Drawing%20Individual%20Pixels/main.cpp

This is more along the lines of what I wanted, as I could now simply create a vector of vertices in the shape of the shield. SFML already provides this type called VertexArray which can be passed directly to a RenderWindow's draw call.

Here's a simple program I wrote that uses a VertexArray to create a rectangle with a gradient fill:

https://github.com/l-paz91/SFML/tree/main/Drawing%20Multiple%20Pixels%20To%20The%20Screen

In my version, the shields are 66x48 pixels, with each vertex needing 4 uint8's of data (RGBA), so that means I need to supply 12,672 uint8's and I don't really want to type that out. So I had to start looking for a way to read in that data from something. SFML does not provide a way to convert textures or images to VertexArrays. I can get the pixel colour data by using the first method and copying the texture to an image but that doesn't provide pixel positions (which a vertex wants). So I wrote a method to combine the two. 

It creates a temporary texture, copies the texture to an image then loops through every pixel, pushing back a new Vertex after all 4 pieces of the pixel have been collected. The positions are calculated using an offset from the top left hand corner. So after 66 vertices have been pushed back, the y co-ord is shifted down 1 pixel. However there is still a glaring problem with this method; I have 4 arrays containing 3168 elements.

So I went back to the drawing board and found this post:

https://en.sfml-dev.org/forums/index.php?topic=7427.0

Using the code from Laurent (the developer of SFML) I managed to write a program that creates a "mask" from a png and uses that to turn pixels transparent:

https://github.com/l-paz91/SFML/tree/main/Using%20A%20PNG%20Image%20As%20A%20Mask

Armed with this knowledge I then set about creating a cannon that fires lasers at the doge image to destroy it:

The next issue to solve was the per-pixel collisions as the laser was still colliding with the bounding box of the sprite. I hackily solved this by writing a very simple collision check:

https://github.com/l-paz91/SFML/tree/main/Sprite%20Disintegration

First, it only does a per-pixel check if the laser has collided with the bounding box of doge. Then, it checks to see if 3 spots on the laser have hit solid pixels. If they're all transparent then the laser can pass through.

This isn't perfect, but it's good enough.

LP's 12 Months of Games // Basic Pong [C++ & SFML]

Completed Via Tutorial 

This is the second project taught in "Beginning C++ Games Programming" by John Horton. The two chapters mainly focused on teaching classes and multiple files so the actual pong game was lacking.

Finished Result:

The "bat" is far to quick and moves off the sides. The ball scrapes along the bat or becomes stuck resulting in ridiculous scores and there's no states like a menu or game over. The basics are there though but I'll be improving this over the next week to add better collision, sounds and "english" (where the ball bounces off the bat with a certain velocity) as well as multiplayer.

I did finally learn how to use Github with Visual Studio though in this exercise. It's quite painless once you get used to it. I still prefer Perforce but for project sharing/collaboration, Github is the clear winner. That won't stop me from using Perforce though.

Code:

I modified the code in the book however it's mainly from the tutorial so I won't be posting. The next Pong game I will though.

Challenge // LP's 12 Months of Games

So I'm an engine programmer...I like optimisation and tool creation. I'm at my happiest when making/doing things that makes gameplay programmers lives easier. That's mainly because I find the more gameplay aspects of games, well, tedious. 

The problem with this mindset though is that ultimately it makes me a terrible engine programmer. I can't make the best game engines if I don't know how games work. Like I know how a game works in the logical sense of how a computer understands it but I don't understand the nuances of level design, timing, AI, suspense, re-playability, state, message dispatching, entity systems, stat balancing...the list is endless. Hats off to gameplay programmers; you are wizards to me.

That's why, I'm designating the next 12 months as the year of games (it was originally supposed to be a new years resolution but I always fail at those so I'm starting early to try and trick myself). I'm going to attempt to make a game every month; no matter how shitty or simple; I want to make a game that has a start, a middle and an end. I've already got some ideas like:

• Slenderman clone in UE4 (I already half started this in 2020 and then got bored when I had to actually make the game)
• Tetris
• Solitaire
• Pong
• Space Invaders
• Doom
• Five Nights At Freddy's clone
• Super Mario World clone (not the entire game...jesus like 1 or 2 levels)
• Game Jam entry (probably Ludem Dare or Haunted PS1)
• Bejewelled clone
• Minecraft??

I want a good mix between styles, like shoot-em-up, platform, 3D, strategy, etc. Also I need them to be well documented so I don't get caught up in deciding what game mechanics to put in. I've noticed that if there is too much choice, I get overwhelmed and abandon the project. I think that's why I'm such a terrible gameplay programmer; the ability to do anything is too much and I just want very specific projects like; implement rotating images. Add animated gif support.

For the more classic games I'd like to just use C++ and DirectX or FLTK/SFML and then Unreal for the 3D games...I might even make slenderman in UE5 as I've not even opened that thing yet.

I'm saying 12 games because I feel that's more realistic, however if I feel like making something new every weekend I'm not going to stop myself. I'll update this post with games as I finish (or not finish them) and I'm excited to see how I've done by November 6th 2022.......

EDIT:

- Timber!! [C++ & SFML] (Nov 2021)

- Basic Pong [C++ & SFML] (Nov 2021)

- Zombie Arena [C++ & SFML] (Nov 2021)

- Thomas Was Late [C++ & SFML] (Nov 2021)

- Alien Invaders Basic [C++ & SFML] (Dec 2021)

- Alien Invaders Part 2 [C++ & SFML] (Jan 2022)