AUT - Game Programming (C++) Course Portfolio (COMP710 - Level 7)
This portfolio is a record of many of the significant things I learned and completed during this class. It will be made up of learnings from the exercises we completed as well as the game projects we complete.
Week 12/13 - TGP Hand-in
We have reached hand-in! Very happy with what me and the team managed to develop. A game with many levels and a fun, simple but creative mechanic/hook have resulted in a game I’m quite proud of. Especially considering the time which we developed it in.
In the final week and days we did a lot of polishing art wise. Ray added some nice art for the blocks which really makes the game pop as you can see to the right. I enhanced the particle effects too which also added a lot visually.
I also fixed the collision when hitting blocks from the side. Before this wouldn’t cause death and as a result the game was far too easy. However, with this change the game is now challenging but to a fair degree where timing is important.
Finally, I created some of my own custom levels using Nemiahs level creation system. This was very easy to use and also really fun. Being able to easily place where you want eveything without touching the code is brilliant. The file to the right shows a few of my levels in text form which is translated using the parser class Nemiah wrote shown below.
Week 11 and 12 - TGP Development
We are approaching the hand-in date for our TGP and are finalising a few things. We now have many of the core features in that we wanted and are now putting the finishing touches on the game.
We now have a fully animated player, parallax background, data driven levels that go from one to the next and sounds. Most importantly core to the levels we added the trampolines. The last two is what I’ve been working on.
Through the creation/development of the levels blocks we have been handling the variety with Enums. Fire, Earth, Ice, Tramp, Flag and Player. All pretty self explainitory but extremely beneficial to ensuring theres no confusion throughout the project. Its helped immensly in other areas when we need to reference any of these objects. For example, in the code to the right you can see how we are referencing the Tramp against the Player. Without enums this would prove quite difficult because they are both entities and not separate class objects.
SFX and Music were enjoyable things to add and I especially enjoyed the footsteps I added as they add significant immersion. I did this with a timer/cooldown combo in the process that can easily be changed in order to match any animation speed of the player.
From here we’re pretty on track for hand-in. We have a few days to try reduce/remove any bugs and memory leaks. However, we are happy with what we’ve made and think the gameplay loop is quite enjoyable.
Week 9 and 10 - TGP Start
Now that IGP is out of the way its time for to move into the TGP (team game project). After finding some other team mates we came up with some ideas. We had the idea of doing a Age of War like game or a tank trouble game. However, we ended up taking some inspiration from Fireboy and Watergirl and thought about making a puzzle game.
We decided against doing a multiplayer game similar to Fireboy and Watergirl just to ensure our scope is achievable. We also wanted our idea to be unique and put our own spin on the genre. An idea we came up with was a platforming switching/toggling idea where the player controls the world rather than the player. The player is an autonomously moving object and the players job is to guide them through levels.
We settled on this idea and split up the workload managing sprints through a trello and starting on the documentation needed. We got our GDD and TDD done and dusted inside the first week. Week 9.5-10 was all about development so we had something to show in the demo session.
I decided to take charge of the physics. So I developed a new scene with box 2d world implemented similar to my other game. However, unlike my other game I needed to implement actual collisions. The issue here is that I still don’t know how to get debugging working. Fortunately, since our game will just be squares this makes finding out edges is a lot easier so this wasn’t too complicated to setup.
The idea is to have the player actually be static on the x axis and have the blocks move to the left. This helps us avoid having to make a camera system as the blocks can just move into the scene simulating player movement. The code below shows how the dying will work in terms of collision. If the players Y value isn’t higher than the incoming block then they will die. Otherwise - if jumped on - the player is fine. The player will also die when they fall below the bottom of the screen. The screenshots on the right also show how the gameplay loop is there of main menu > game > death menu > game or main menu.
Week 8 - IGP Submission
Week back from the mid sem break and I’ve submitted both FWT and Gold submissions. The FWT was missing some features and had a few bugs but things were solved for the Gold submission I just handed in. The reason I didn’t have text in the Walk and talk submission was due to the code given not matching up with the version we were told to use. This has been resolved luckily getting help from a class mate who gave me the neccessery code to get it working. No I have a main and death/level completed menu.
I’m happy with what I submitted and talk about it more in depth in my post mortem but I think theres a good base here for a deeper experience. There’s some features missing with what I original scoped out but whats there is still a fun little game with lots of features we learnt leading up to the project. Features like physics and sound really help this games feel a lot. Although, box2d wasn’t implemented to the degree I originally wanted its still there in the shield movement and jump which I’m really happy with. It was overall an enjoyable project which I learnt plenty from. I am now quite confident with C++ and its setup with Visual Studio. The general structure of header and implementation files with recurring functions like Initalise, Process and Draw is something I have become quite familiar and comfortable with.
Semester break weeks
Througout the uni break I’ve gotten deep into developing the game. I have the main game level setup with enemies spawning, shield deflection, jumping, projectiles, and all art/animations in. The enemies spawn from either side randomly and bombs spawn from the top. The gameplay feels nice and shield is nice to use due to it having physics tied to it. This means theres a bit of intertia when rotating it which results in nice feeling movement. The jump is also physics based and results in a realistic looking jump/fall. Most recently I have been working on the SFX for the game and it has really brought it to life. Deflection, explosion and music have really made the game more engaging and fun. Next week I need to get the menus/UI working which I’m currently struggling with because the SDL_ttf library hasn’t been working for me (as shown with the scribbles in the screenshot). I will consult with the teacher to try resolve this issue. As you can see there is a debugging input too but this needs to contain more variables for testing in this Alpha phase.
To the right is some of the code from the enemy spawner which shows the use of the GetRandom() from the inlinehelpers class to ensure randomness each time the player plays. It also shows the variety of enemies: wolf, coal walker, and bomb.
Week 7
This week I’ve worked primarily on art for the game. Specifically the sprite sheets because 3 of the entities in the game will be animated. The player, enemy 1 & 2 will be so I wanted to get this out of the way quick and early so most development time can be focused on coding. So far I have done rotation for the player and walking in and shooting animations for enemy 1 & 2. I will leave player movement animations as this will be something I will add later if I have enough time. I really want to start focusing on the gameplay before worrying more about art/animations. I may end up not even animating the main character to just focus on getting everything working but I will have animations in other places like the bomb explosion for instance.
Box 2D has proven quite frustrating this week as I cannot get the debug drawing to work at all. I have tried many different tutorials and methods but it just won’t show me any information. This means I’ll be moving towards a simulated physics approach with my projectiles. I think it will still be effective enough but its a shame I can’t get what I originally envisioned in.
Week 6
Unfortunately due to laptop issues I haven’t been able to work on my game as much as I’d like. My laptop isn’t responding properly to my charger so its been out of use at times. However, I have still moved forward focusing on the IGPs (individual game project) documentation. I have worked on and completed the pitch and GDD (game design document). The pitch is a high level overview of the game and describes what you’ll play and see. The GDD goes more in depth about the gameplay, features and everything that will be included in the game. I am happy with these documents and with my game idea. I think it will be achievable and hope my laptop doesn’t hold me back. I think I may move the engine to my PC and try and get a GitHub going so I can work on both devices. However, firstly, I want to try repairing or looking at other options for my laptop. My next focus will be on creating the art and then starting on developing the games character movement and shooting.
Week 5
This week I worked on getting some of the things from previous weeks up to date. This was mostly in terms of middleware. I needed to get FMOD (sound middleware) and Box2D (2D physics engine) working in the GP framework. This wasn’t quite as easy as I expected it to be with it needing manual integration from GitHub and the instructions were a bit outdated. I tried using the instructions with C-make but it just wasn’t working. However, I ended up getting it working through Nu-get library manager in Visual Studio. As for FMOD this was a little easier and I got it up and running pretty quickly with a soundsystem class created and playing sounds. The Box2D integration is quite minimal at the moment with just a ball falling to the ground working so far but the fundamentals are there for a game to be built out using it.
FMOD: FMOD was quite easy to setup. After including the appropriate files provided to us and including the .lib files and the name in the input section it was ready for implementation. As suggested making a wrapper class like the particle system one would be ideal so thats what I did. I thought storing the sounds in a map would be the best way to keep the sounds linked to a const char* and not creating the sound every time I needed it. To the right you can see how the creation/playing of sounds works. I don’t really understand much about the channels but from further research and implementation of a volume function I think its to do with just that, adjusting the sounds volume.
Week 4
This week was a bit stressful as I was a bit behind overall with the engine as mentioned in the last entry I only just set it all up. However, it was great this week to actually get used to the engine and how it functions.
The exercise shown here is the space invaders one and was great for learning about the new Entity class. All objects in the Scene are sub classes of the entity with some of the functions overidden and some inherited without change. This was great for creating shared functionality like the m_bAlive boolean. This variable for example, was helpful in ‘destroying’ the objects as they’d only be drawn if alive. I feel quite confident with the framework now which is awesome. I did find this exercise quick long to complete though, meaning I couldn’t do many others because of time constraints. However, I did also complete the audio exercise and the particle system integration but these are a little hard to show through this website. Will hopefully integrate this into my game project to show-off then.
Week 3
This week was all about getting the game engine framework working.
Wish I could say it was smooth sailing but when copying (manually) from the slides I missed one line which prevented me from rendering sprites properly. Eventually after much time I found and solved fixed the omission.
The exercise to the right was a pretty straight-forward one but good for getting used to the engine. It required us to render 5 checkerboards. The middle one we changed the attributes of a bit more (size and rotation).
The engines actually much easier than I realised to work. However, I’m still getting my head around how much of it functions. So far I have learnt a lot though and am sure I’ll learn more as I continue to use it!
Week 2
In this second week we really nailed down in C++ and also covered some other things like singletons and using the STL.
The picture to the right is from the game exercise we were given to show our skills with OOP and C++ fundamentals generally.
Here I show the Crystal class. It shows good use of OOP fundamentals with a helpful constructor and public methods which publically expose the private variables for getting. This keeps another coder or myself from accidentally changing these values later on. Making the Crystal a class really helped with the clarity of the main.cpp file as it wasn’t burdened by structs or anything.
Week 1/2
Missed the first week of this course but did a lot of the exercises at home to catch up. Am already familiar with C from year one uni and have done a little C++ as well. However I’m still a beginner so these exercies helped.
First thing to get used to again is the structure of writing code. Mainly in terms of OOP. Weeks 1 was just getting used to fundamental coding principles and week 2 focused on OOP. A lesson learnt in the exercise shown in the snippet to the right is actually to do with pointers though. The lesson is that when using a pointer with ‘new’ you need to ‘delete‘ it to deallocate. Then you need to set the pointer = 0. This ensures there isn’t a wild pointer.
