reid-moffat/battleship

A C++ and SFML GUI game created for a team Software Development course project

Hi 👋

I'm a Software Developer focusing on API development with clean, concise and clear code. Feel free to connect with me on Linkedin for project collaboration!

My projects

🤝 = Team project

• A open-source course tracking & verification LMS 🤝
• A NPM utility package for simple and flexible array generation
• A Stock price alert site (code)
• A C++/SFML battleship game 🤝
• A course mark distribution website 🤝
• A app development club website 🤝
• A simplified job application organizer (code) 🤝
• A list of practical Bash shortcuts
• A point-maximizing cribbage algorithm

My skills

Core:

Tools:

Backend:

Frontend:

battleship's Issues

Set up workflow for testing

Since SFML has been added to the project itself, set up a workflow that tests building the project with each push

Make the mousePosition a static state variable which is consistently updated

This will reduce the number of params needed for methods such as updateButtonState

After completing a game and starting a new one, attacking will cause the executable to crash after a few tries

This is likely due to the way grids are instantiated- I used a not so good static way of doing it; updating it with the new singleton methods should fix it

Move SFML textures and sprites to resource managers

Each screen should have one resource manager for sprites and textures instead of a field for every sprite/texture

They will be initialized in the screen's constructor and a reference to each texture/sprite can be obtained. It will also handle errors such as not finding the file

Refactor repo structure

• Move the build location to bin/ (gitignore this)
• Move header files from include -> src (make sure to refactor so all the include statements don't need to be manually done)
• Re-organize the screens directory into actual screens and top-level helper classes (state, screen template, screen manager)
• Add SFML to include/
• Refactor tests -> test

Add smart pointers to all screens

• All screen instances are replaced with std::unique_ptr<> and their getInstance() method is updated to instance.reset(new typename)
• The remaining member variables are changed to smart pointers

Change screens to singletons

The static class methods are not efficient or a good style

• Each screen should be a singleton
• screenLists in screenManager will hold references to them (from getInstance())
• Each screen will still have a public run() method

Create issues template

Refactor gameplay "Narrowing conversion from 'int' to 'float'" issues

Code such as this can be simplified:
((128 + (coordinate.getX() * 16)) * 5)

Condense SFML objects into data structures

gameplay.cpp especially has a lot of bloated code from manually loading everything. For every class, move SFML objects (textures, sprites, etc) into data structures such as maps

On debug mode in clion, a seg fault is raised after the first click on the game screen

The cause of this is likely how the game grids are stored