Showing posts with label games. Show all posts
Showing posts with label games. Show all posts

Friday, 15 December 2023

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.

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

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.

Solitaire Win Screen Classic Animation - C++ and SFML

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.


Solitaire Win Screen Classic Animation - C++ and SFML

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...

Tuesday, 18 April 2023

Dev Diary // Using ChatGPT to make an Idle Clicker Game

There is an idle clicker game called Cookie Clicker. It's amazing, you click a giant cookie, to make more cookies, to buy buildings and upgrades that will make cookies. There is a grandma apocalypse, a dragon called krumblor and ascensions. Kittens can give you milk multipliers which boosts your cookies per second. The entire goal is to make as many cookies as possible per second. It is utterly addictive and completely free:

Cookie Clicker was first released back in 2013 and I started playing around 2015. Soon after release, the creator made a website: Idle Game Maker, which turned the cookie clicker code into an engine and allowed users to make their own idle game. It's really intuitive and easy to use; and you can host your game for free using their website.

Whilst messing around with that engine recently; I realised a lot is hidden away from the user. Being an engine programmer, I wanted to know more about how clicker games actually function but I have next to no knowledge of web development; enter ChatGPT.


The above video is me sitting down with Chat and trying to get it to create the bare bones of an idle clicker with as little coding from me as possible and I'm amazed at the results. I filmed for 50 minutes and by the end of that I had a clicker game with 2 buildings and a lucky button that appears randomly. I edited about 3 lines of code in total but used ChatGPT to generate everything for me. Even asking it to move CSS elements to different places.

I don't think I would continue trying to get it to create the entire game as that would get a bit tedious; but now I've got the bare bones, I've got a solid starting point to tinker with. I would probably start making it look prettier first before adding anything else.

HTML, CSS and Javascript are completely outside my zone of knowledge but having looked through the generated code; the html and JS is actually pretty readable and easy to add to. The CSS on the other hand will require some more thought.

You can find all the code generated in this session here:

Tuesday, 14 March 2023

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

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

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:

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

++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.

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:

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

I used GIMP to change the hue of it to create 6 other colours.
Dev Diary // Adventures with Tetris (C++ Console Window & FLTK)

I then created a simple window with a quit button.

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

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.

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

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).

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


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:

Dev Diary // Adventures with Tetris (C++ Console Window & FLTK)
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:

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

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:

Tuesday, 31 May 2022

[Dev Log] Generic Slenderman Clone Part 2 // UE5 & Blueprint

So after part 1, I had the bare bones of a slenderman game. In this part I wanted to flesh out the mechanics a little more and make it start to look more like a "game". My Goals for part 2 were:
  1. Replace the cubes with actual "notes"
  2. Create random spawn points for the notes
  3. Create a sprint mechanic + realistic jump
  4. Add sprint and notes to HUD widget
  5. Change it to night time
  6. Create a flashlight
  7. Create a battery mechanic
  8. Executable
1. Replace the cubes with actual "notes"
2. Create random spawn points for the notes
For this I opened up blender and made the shittest piece of paper. Took about 1 minute. Made sure to resize the plane to A4, curled the edges slightly and gave it a material slot for the front and back and then exported it to Unreal.

[Dev Log] Generic Slenderman Clone Part 2 // UE5 & Blueprint

I downloaded the note textures used in one of the slenderman games off google images and created materials from them. Then created a way for the notes to pick one of the materials at runtime. There are 8 different textures and each note is unique:

[Dev Log] Generic Slenderman Clone Part 2 // UE5 & Blueprint

I created a new blueprint which now handles the spawning of the notes and what material they get. This blueprint contains 16 locations where the notes could spawn. More can be added but only 8 locations will be picked at runtime. You can change the number of locations in the details panel in the editor.

[Dev Log] Generic Slenderman Clone Part 2 // UE5 & Blueprint

3. Create a sprint mechanic and realistic jump
Default unreal man jumps like Princess Peach; in fact it's more floating than jumping and greatly annoys me. Fixing it is quite simple though by just changing the Z Jump Velocity in the Character Movement.

The sprint mechanic is also relatively simple. When shift is held, it reduces the sprint each second and when it reaches 0 (from 100), you can no longer sprint. It takes 10 seconds to replenish fully. I achieved this by using timers instead of ticking. That way, we're not constantly checking to see if we're sprinting (or replenishing sprint value) every frame; only when we need to.

[Dev Log] Generic Slenderman Clone Part 2 // UE5 & Blueprint

4. Add sprint and notes collected to the HUD widget
Using icons from the Android library (they're free to use) I added a progress bar and text to the HUD:

[Dev Log] Generic Slenderman Clone Part 2 // UE5 & Blueprint

The progress bar does use a binding to update itself which is expensive but barely anything is ticking in this game so I didn't really care. In UE5, the progress bars now come with a default animation as well which is snazzy. The notes text is updated when a note is destroyed and the blueprint sends a message to the HUD.

5. Change to night time
This was one of the most difficult parts as lighting in Unreal Engine is unbelievably difficult. You need to change colours determined by sun, override sky colours, change the post process volume and exponential height fog....it's never ending. Also, as the scene is so dark afterwards; I duplicated BP_Sky_Sphere so I could add a tick box which would allow me to switch between day and night in real time.

In the construction script I added this mess:
[Dev Log] Generic Slenderman Clone Part 2 // UE5 & Blueprint

Which toggles between "soft day" and night:

[Dev Log] Generic Slenderman Clone Part 2 // UE5 & Blueprint

6. Adding a flashlight
For this I simply add a spot light to the character and attached it to the head socket so it moves with the character. I thought about a doing a torch you hold in your hand but couldn't be bothered with the hand animations as this is true first person so instead, the player is wearing a head torch. I added some nodes to allow the player to toggle the flashlight on and off with F.

[Dev Log] Generic Slenderman Clone Part 2 // UE5 & Blueprint

The flashlight is its own blueprint and spawns on the player as a child component. I gave it a light profile as well using one of the default UE ones so it's softer when far away from objects; but then the cone shape starts to appear when you get closer. It always annoys me in games when the flashlight is just a circle in the centre of the screen.

7. Adding a battery mechanic
This didn't take long as it was almost copy and paste on the sprint mechanic. I added some timers to the flashlight so when it's in use it begins to lose power and it updates the HUD with the new power level. I added a cylinder to game which acts as a "battery". When you pick it up it replenishes the battery power; regardless of how much power you have left. So batteries should be used wisely as you can't store them in an inventory.

8. Executable
In the gif, "slenderman" is motionless as I disabled it's "AI" for the moment whilst testing (and I forgot to remove the debug output from sprinting) but it's starting to look more like a spooky game now!

[Dev Log] Generic Slenderman Clone Part 2 // UE5 & Blueprint

In part 3, I'll actually create the forest map, add sounds like footsteps, cracking twigs and some story elements. By the end of part 3 it will look like a proper slenderman game but it still won't act like one.

Monday, 17 January 2022

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:
LP's 12 Months of Games // Alien Invaders Part 2 [C++ & SFML]

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.

Friday, 31 December 2021

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:
Space Invaders Clone Using C++ and SFML

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:

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:


Friday, 24 December 2021

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:

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":

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

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:

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:

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:

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

Armed with this knowledge I then set about creating a cannon that fires lasers at the doge image to destroy it:
C++ & SFML // Creating The Disintegrating Shields in Space invaders

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:

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

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.

Saturday, 13 November 2021

LP's 12 Months of Games // Thomas Was Late [C++ & SFML]

Completed Via Tutorial

The 4th game taught in "Beginning C++ Games Programming" by John Horton and there are some more things I found strange:
  • The engine class had 4 functions but only the constructor and 1 other function were defined in the cpp; the others were given their own cpp file....I have honestly never seen this. I can understand wanting to keep the code "manageable" but just collapse the function? There are class definitions in Unreal Engine thousands of lines long. If you're having trouble use Alt+G to directly go to the function or just Shift+F and search.
  • The private const member variables in classes. If they're private, they can only be used within the class anyway so move them out of the class and into a private namespace in the cpp. Those variables are padding out the size of the class; all those bytes add up; especially if you are creating many instances of the class (as games often do). The const variables in the namespace will still be static but at least they're only being created once instead however many times you have created instances of the class they were in.
  • There are also other implications on your classes to do with move/copy constuctors caused by const members.
  • I've also seen some "Variable const x", especially in function argument parameters. Yes the compiler will accept it but it's good practice when declaring a const variable to have the const before the type. You may see const after a function declaration but that is promising that function doesn't modify any member variables inside the function. The const before the function return type specifies that return value cannot be modified.
  • The given code doesn't actually work or compile. 
  • Pointer pointers were introduced....in a book aimed at those who have never programmed before....I have no words. I know you can't create a 2d array without using values defined at compile time but that's because it's an array; just use a vector. This is not Beginning C Games Programming.
  • The LevelManager should be holding an instance of the level vector array, this eliminates the need to new anything up. In the original code the pointer is returned to a different class. If it has to be a pointer at least ensure that whatever is holding the pointer frees it properly in the destructor (or better yet, use smart pointers).
  • He includes headers in cpp's that have already been included in the matching header file.
I will admit, I did find this funny though:


Finished Result:
The tutorial spanned from chapters 14 - 18 and I stopped halfway through 17 because the game is severely broken:
LP's 12 Months of Games // Thomas Was Late [C++ & SFML]

I don't have time to get this working nor do I really care. There was something going on with the drawing and ordering of the sprites vs the background. Left and right were only for the green shape, A and D were for the red. It knew this when input was received yet for some reason it decided to apply the updates to some other sprite.

There's only space invaders left now which should be more fun; this one was a bit dry.

Code:
No code drop for this one. The authors repository for the book is here though:

Friday, 12 November 2021

LP's 12 Months of Games // Zombie Arena [C++ & SFML]

Completed Via Tutorial

Another tutorial finished from "Beginning C++ Games Programming" by John Horton. 

Please do not use this book to learn C++. Some things boggled the mind when following this tutorial like:
  • variable + 0 (???)
  • Creating a header, only for it to contain functions that are neither marked as extern or static or within a namespace. One function returns a raw pointer which is deleted somewhere else...
  • #pragma once #ifndef #define combo (pick one. I like ifndef define because it's slightly more portable).
  • Constant float to int/int to float with no casting or safety in place. For example, he'll choose to make an int variable but only use it with a float???
  • Singleton classes. Don't get me wrong, I like singletons but this is not the best way to do it. The constructor should be private with copy and assignment deleted. There should instead be a static public function that declares and returns a reference to a static instance of the class to ensure it is destroyed properly.
  • Member functions that don't modify are not marked as const nor is anything returned by const reference if it can be.
  • Initialises class members in the constructor body instead of via initialiser list; this causes the member variable to be default initialised and then assigned again.
  • Const member variables are initialised in the class body definition??? static const integral types yes, but otherwise for linking sake, it's best to initialise const members in the constructor.
One thing that really bugged me was all the event handling for input was done in main. I am a firm believer that objects should handle input events themselves. That said, the author promised at the end of this game that there will be better code handling in the next two projects so I'll hold further judgement until I finish the book.

Finished Result:

LP's 12 Months of Games // Zombie Arena [C++ & SFML]

I was having fun with this one by the end. I quite like "Demakes" and I think this style would make a good Left 4 Dead demake. The hitboxes on the zombies are a bit janky and I'd like some background music but other than that I'm actually pretty happy with this one. 

It taught some solid SFML concepts that I can take away to personal projects. I'm itching now to start Tetris or my own version of pong to apply what I've learnt but I'm going to finish the book first as he mentioned using more advanced sound features, particle effects an split-screen in the upcoming chapters.

Code:

There's a code drop for this one as I feel I changed it enough. Assets haven't been included for copyright reasons but here is the authors repository:
https://github.com/PacktPublishing/Beginning-Cpp-Game-Programming-Second-Edition

Monday, 8 November 2021

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:

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

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.

Sunday, 7 November 2021

LP's 12 Months of Games // Timber!! [C++ & SFML]

Completed via Tutorial

I started a book called "Beginning C++ Games Programming" by John Horton. It's aimed at those who've never used C++ before and teaches you how to make 5 games using SFML. I thought this would be the perfect introduction to SFML as I could ignore the bits about C++ and focus on the library. I was right.

I've just completed the first game; Timber!! I've used sfml once, many years ago to try and make pong. At the time I had been learning cpp for about 6 months and found it utterly confusing. This time, thanks to experience with FLTK and DirectX it was more "ah so this is how I get a sprite, this is how I draw it, this is how you poll events" etc.

I'd say this project would take a while for a complete C++ beginner but it was perfect to showcase on how to get to grips with sfml. I'm looking forward to the other 4 games and learning other sfml features.

As for the tutorial itself; I don't like the amount of hardcoded numbers and the fullscreen game (I prefer windowed when debugging). All the textures rely on the screen being a certain size as well but I can remedy that in my own projects. Also, the author is extremely bias to arrays and OOP with the code being very java-ry. I wouldn't recommend the book for first time C++ programmers as I feel it would teach some bad habits; make sure you use Principles & Practice for cpp.

Finished Result:

LP's 12 Months of Games // Timber!! [C++ & SFML]

The assets were all provided by the book and I made a few adjustments to the code but other than that it's pretty much what the book gives.

I will say I'm extremely surprised by just how easy SFML actually is to use. I'm already formulating how to get a tetris game working or match 3 from just doing this simple game. So I guess it was a good tutorial overall.

Code:
A code drop will not be provided for this one as it's mainly from the book.

Saturday, 6 November 2021

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: