For I Have Sinned is blackjack inside of a confessional booth, but as you sin, your odds get evil.
As in they get worse, but in more ways than one.
This game was made in a group of 11, and was made to be as blackjack with a twist. This twist was decided to be that the player needed to manage and maintain their holiness.
Lowering the holiness, decreases the players luck while also increasing the amount of times the enemy will cheat.
With my role being programming lead, I took on making the main mechanics and flow for blackjack, merging that with the enemy cheating, player cheating and luck. I made the bones of the project.
My Role
My role for this project was programming lead, meaning I designated tasks and resolved problems when they got brought up.
Tools Used:
Unreal Engine 5 (Specifically using blueprints), GitHub Desktop, Trello, Miro, Excel, Blender, Krita
Some Interesting Mechanics
In this project, cards were split up into data assets containing their texture, number, suit and any other cool things we wanted. This allowed for things to evolve in a good way, as I managed to make special cards with them (see joker cards for explanation). However, making a new data asset for each card took too long especially as I made these in bulk when I got the textures for them. So I needed to find a different way of doing things.
I used and editor widget with asset loaders to take the textures of the cards and an inputted enum to create and save multiple data assets in bulk so instead of taking half an hour for each card suit it only took a matter of clicks.
This game was structured for that a dealer class was in charge of the flow of the whole game. This had both positives and negatives for the project, but one of the positives was how easily this allowed for me to make the enemies cheat in very different ways wihtout changin much.
In the dealer, I added delegates/event dispatchers for everything thast happens in the game. I then created child classes from this class. BUT, I did not create new functions connected to those delegates, because I did not want the cheats to be directly tied to them. So, instead of that, I created actor components which connect themselves to the delegates, meaning I could change and move them around the different dealer classes easily.
Deeper Breakdown of One Mechanic
One twist of the game was special activated cards which do special things when activated, but as stated previously, these cards are all one class that have their details set by a data asset. So how did I do these special effects?
Actor components! Similarly to the enemy cheats. But again, no child classes, so I needed a way to add these to the cards. And for that I used soft class references, references which only have the classes loaded when they are needed. The card then checks if the data asset has this soft class reference and if it does it creates the new component which then has an event dispatcher connected to an overridden function which does the effect of the special card.
Reflections After Release
On my end of this project, I am happy with how things went. I got all the tasks done that I needed to, while also assisting others with their tasks occassionally, after finishing my own. I managed to keep the file structure of the project pretty clean, and adapted throughout the project to stop commit conflicts, as unreal engine blueprints are a lot more sensitive than I was used to at the start, using an excel spreadsheet to allow for different team members to claim the different classes, so therefore no people would work on the same part of the project, even just a little bit, as that would create conflicts for me to fix.
However, I should have made my code more readable on parts where I thought my other team members would have look at or modified. From this, I also realised I needed to write external documentation on my code as well. But more importantly, I think I should have gotten the other programmers to work a bit more, as I did most of the work on the codebase.