Posted August 10, 2024 by ashraful3605
Game Development Log - Production
Within the 7-week long production period, there was a main focus on getting the basic features done in order for there to be some sort of playable game with enough features that, a player of the game can navigate through each section of the game, however this would be without the artistic changes from the games art and animation students.
This would mean we would have a level blockout for each of the 6 levels, with one student per level and another student focusing on the modular assets that could be shared among all the levels. There were originally to be six levels that incorporate similar traps and look to represent one of 6 gods (Zeus, Ares, Dionysus, Hades, Poseidon and Artemis). However due to unforeseen circumstances one member had to leave, which led to the scrapping of the poseidon level.
Throughout the duration of this period, we were also tasked with getting some help with the audio needed for the game. This was mainly done through the collaboration with another course from another university. This was done with ICMP. This meant that there was a need for great amounts of effective communication between both the general games development team and the audio team. Where there wasn’t initially enough communication between the two different teams, in the end there was enough audio that all members of the game development team were more than pleased with.
With two games programmers for the project, (Ashraful and Ash), this meant most of the workload was to be split in two, where Ash took the main lead on setting up the project and the necessary applications for the file sharing and management, where as Ashraful looked to try implementing some features for the game such as the traps and the menu system. Where Ash was looking to get a headstart on the use of C++ in order to code some aspects, meanwhile Ashraful was focusing more on the use of blueprints and other built in unreal features. While it seemed that Ash was teaching the novice (student) Ashraful,
When it came to starting the foundation for the game, Ash was able to quickly and easily set up the necessary applications to ensure that all in terms of communication, file sharing and general recording of plans (and such). This meant starting to set up the Gitlabs and Gitkraken together to work to have a good form of file handling and sharing. However, this also meant that this new form of file handling had to be taught to others in the group. Where it had its advantages, this proved to be the only disadvantage of using new software that others in the group had not used yet. This also meant setting up the necessary communication. In this case, we looked to use slack as it was an easy method of communication whilst providing free integration of certain applications we were using (Gitlab).
Ashraful on the other hand had begun to work on the traps at the same time. After being taught the basics of using Gitkraken and how to set it up at home, using various tutorials, Ashraful had begun to implement some traps. Initially, the traps were just being copy and pasted from different tutorials, but as practice went on, there was a realisation that there wasn’t a need to be following these tutorials down to the crumb. There was a change in how the traps looked and worked. Initially, they were looking to have animation for them, which was obtained online. But the new ones worked to move the traps using built in blueprints and mathematics. Spikes were to be either static or move to jump at the player when close enough. There was also a swinging axe trap that initially worked to follow an animation curve, but then was later changed to be more malleable in the speed of the swing, the size of the arc of the swing and how long it took for a complete swing.
Ash had also worked on creating the player controller. This was vital as the game itself was to be played in 2.5d format. This meant that the third person sample controller worked with planar movement enabled, left stick (including keyboard) movement is mapped directly to movement along the global x axis This also allowed Ash to begin creating some more foundations for the general outlook of the game. One example of this is the introduction of new game modes that would change based on the needs of the level. For example, the main level would use the game mode for the movement of the player and locking of the camera, however in the menu level, there wouldn’t be any need for the player to be able to move around the level and move along with the camera, so there would only be a mouse available on screen at this point. Ash had also started to work on creating the basic template for the files within the project itself as well as the format for the levels themselves.
Within the first week, Ashraful had realised that not all of the traps he was thinking of creating can be used within the intended level blockouts being created by the Games art and Animation students. So at this point, after a conversation with those with a level blockout already ready, a list of what traps were needed for whose level was created with a key to show which traps were on the level blockout plan. Also, within this conversation it was also discussed which traps were needed and whether the already made traps could be used in any way to replace the intended traps. One of the traps which proved most difficult was the fire trap, where without the artistic input, the fire aspect was proving too difficult to be completed at the time. So instead of spending too much time dwelling on the lack of fire,this task was pushed to have it more as a stretch goal rather than something that needs to be completed immediately.
Meanwhile, Ash was making use of his C++ knowledge and began working on another vital feature of the game, which is the doors. These doors would work to be intractable by the player, and when interacted with would transport them to the next level in the map view. On paper, the concept was easy to explain, but when implementing them, it proved more difficult than expected. In order for the doors to be working in the correct manner, the package system was also needed to be working. It starts with an enum value relating to the region or the level (ares, hades, HQ …). Each door stores the same enum value as its region with the packages for each region also storing the same enum. When the player interacts with the door, the door requests a level load from the game mode blueprint. This blueprint has a reference to a data table thats being used like a dictionary. It looks up the first row in the table that has the matching enum and then loads the level from that table row. If the door you interact with is a delivery door then instead the package you are carrying is checked. If the package and door enums match, then you’ve completed your delivery.
Within this period of time, Ashraful hadn’t spent enough time on the project as was initially wanted. However, despite this there was a menu system created that got to work in the end without the settings section working. The main issue came when the method of adding buttons and such into the menu system was not in the typical format. When wanting to add a button that was to be used with the blueprints, the canvas had to be declared within another blueprint with a widget component attached. This meant that when creating or adding to a new canvas for the menu, there had to be another component open in another blueprint in order for the blueprints to be able to read the button. Another aspect that was implemented was the pause menu, which worked to pause the game when the P button was pressed (or escape). There was also the start of the importing of the necessary traps to the necessary levels. At this point. The branch that was being used for the creation of the traps was not on the right branch which meant that whatever the other programmers were doing, it could not be seen or read by the person on the traps branch. But with the expertise of Ash, this was quickly fixed and the error was explained to Ashraful.
With Ash, the door system and packages system has begun to show errors. When interacting with a door, the engine would crash to the desktop. This error is something that has yet to be fixed and is still an ongoing issue.
By using C++ at a point where not everyone else was, meant that there would be little help and more self-discovery. Where, when something was not working, it would be difficult to find someone to help and difficult to find help anywhere. It was, however , a risk worth taking. Without the use of C++, elements of the project would have remained limited and the overall playthrough may have been a little simpler.