top of page
  • gabestott

TDEMO INDIVIDUAL

This serves as a summary of my experience of TDEMO throughout my first year of study at University of Portsmouth, computer games enterprise. It covers the games created throughout the year in regard to their conception, design, development and the skills and experiences gained from their development.


We started the year with the task of creating a hyper casual one button game. This meant the game could be anything so long as it only opperated using one input control. This was very much the same task which I had undertaken as a means of entrance exam while applying for my place at the university. I unerstood the concept of a hyper casual one button game and had a few ideas inspired from other games I had played with several ideas on how they could be improved and enhanced. I had been playing some of the popular game "among us" and had noticed there was a mini game which reminded me of anothere mini game seen in a childhood favourite of mine "Ratchet and Clank". The core premise of both mini games is to align rotating pieces in the correct place. I took this idea and made some notes and diagrams to explain and elaborate on my concept. I chose to use "game maker studio 2" as the engine for the development of what I eventually named "spinny clicky", a very over simplified but apt name. The game's core mechanics changed slightly as I developed the game as a result of overscoping. This was the second game I had ever properly made and finished, and unlike the first game I'd made I was unable to spend every hour of every day of the one week I had to make it, solely on the game. I had to divy up my time evenly between all my modules, something which I now know to be a near impossible feat and not entirely necessary either. In the end spinny clicky ended up rather lack luster; having a scoring mechanism and even a highscore mechanism but being graphically hard to look at for prolonged periods of time for it's horrendous colour pallet and a scoring mechanism which almost everyone who played it said was unfair and often didn't register what was clearly a succesful hit. This was a problem with the collision boxes. I hadn't spent enough time fine tuning the core mechanics and had instead tried to add extra features which with hindsight is the opposite of what you should aim for. Aim to do a few things incredibly well and then add to that.


The next theme we were tasked with was to create an incremental clicker game. For this we were placed into teams for the first time. This was a great first experience working on a game with a team and our team lead did an excellent job of bringing the team together and encouraging an enthusiastic working environment. The scope of the game was ambitious as is to be expected for a team of inexperienced devs but somehow we managed to pull together and produce a game which really closely resembled the inital concept. The name of the game; Clicker dot exe, a meta approach to clicker games in which an incremental clicker game overlord sits behind an oldschool crt monitor creating clicker games with every click. For this game I agreed to work on the audio which became a theme for my first year of game dev in TDEMO. As with any project first comes the research which was primarily youtube tutorials and some online "how to's", focussed mainly on how to create game audio from scratch. Using homemade audio recordings via mobile phone microphone and household objects such as key jangling or tapping metal cutlery on different materials I was able to gather the fundamental pieces which would go on to be edited in the Digital Audio Workstation (DAW), Fruity Loops. By importing several recordings, pitch editing and volume adjustment you are able to make some very interesting and unique sounds. The drawback for this technique is that is can often be quite a lengthy process and so for a small game with only a few sounds this is great but for a larger game this may not always be the best option. Unfortunately the sounds we created never made it into the final version of the game however they were used in the promotional video which showcased it. In hindsight this could have been a turning point where I began to tackle more of the . The key takeaway from this game was that a good leader, encouraging both productivity and also creativity with a relatively hands off approach can lead a team to a succesful game.


Up next was the fantasy platformer where once again I was tasked with sound design. The concept for our platformer was very different from our final product and it's easy to say that it was due to our project being too ambitious. Our inital concept was a 2.5D platformer, meaning a 3D player model navigating a 3D world but with access to only 2 dimensions, left/right and up/down. Our concept was to have a novice mage cast spells which propelled him like small explosions to navigate the levels. Our modeller quickly created a fantastic wizzard and accompanying platform assets with textures to match. Meanwhile our programmers set out to make the game playable. With regard to sound we decided that we'd go for a few simple sounds for jumping, dying, opening doors to the next level and picking up keys to open the doors. To really make our game stand our we wanted to give it a soundtrack to accompany the gameplay. I had prior experience with editing tracks and recordings in Fruity loops DAW but I had never finished a track and I didn't have much in the way of music theory knowledge. Despite these challenges I spent the majority of development focussed solely on the audio while the team worked on the mechanics. I didn't communicate as much as many other members of the team due to the nature of audio work requiring a quiet or silent environment to be able to hear what you're working on. As a result I was relatively unware of the struggles facing the programmers with trying to implement a physics based explosion repulsion mechanic which was originally the core premise of the game. Ultimately this would have been another great opportunity to get stuck in with the sound implementation but that wouldn't come until a little later on. Generally this project struggled with a lack of polish, both in the audio and the mechanics. The player model wouldn't rotate to face the direction of movement and there was no built in audio volume control. Some complained the sound of the player whe jumping was also irritating which makes sense as it doesn't match the movement of the player due to us axe-ing the explosion mechanic and opting for a dash mechanic at the last minute.


Star fox was our next theme. I was appointed joint lead alongside Gabriel Daka, I am sure this was not a coincidence. This was my first time leading a project and it was full of valuable lessons. We started by collating all the team members into a discord server and setting up the sever so there were relevant places for all possible discussions this was to keep discussions focussed and stop overlapping discussions as is a risk whn you only have one text channel. We had regular meetings and discussed the concept thoroughly. The team were excited about the prospect of combining two genres the platforming genre we had tackled previously, as a mini level and the star fox style as the bulk of the game which would be played between the mini platformer levels. The idea was that the platforming sections would act as boss stages. We had originally concepted that there would be a short storyline and even voiced characters. If you've read this far then you will already know that this smells suspiciously like overscoping and you would be correct but we'll come to that soon. As a team leader I tried to delegate tasks and keep track of the games development using kanban / trello. Where we had to make 2D assets for the platforming section and the 3D assets for the starfox section this put a large strain on our art / modellign team. I even stepped in to try and create some low poly asteroids for the starfox section using my limited knowledge of 3DS max. The audio took a complete hit and was virtually non existent as I fulfilled the role of team lead, in a manner which in hind sight was probably too hands on. However this project did serve as a great opportunity to learn about audio implemention, audio libraries (full of premade sounds), sfxr/bfxr ( used for quick 8bit style game sounds which even includes some presets which could randomly generate unique sounds). As mentioned earlier, this game was simply too ambitious and as a result of trying to create something as complex as this we ignored the golen rule of "Do a few things well and then add to it". Despite the end result the process was fun and with less of a restriction on the development time we could have created something really enjoyable.



Finally we come to Submariner.


Sbmariner was a goliath of a project, unlike anything I or any of the team had ever attempted from a technical point of view. My role was not originally team lead although eventually it would come to pass that I would become team lead. Originally I was simply tasked with sound design.

The project itself was to a submarine simulator for the royal navy to use at recruitment events, showing the role of the planesman and the periscope opperator in a 90 - 120 second gameplay loop. This was my first time working on a client based project but that was not the case for the whole team. What made the project so unique for us all was that they had requested it to be VR compatible and 2 player multiplayer. I begun by simply researching the sound scape of the submarine while the team begun research into other aspects of submarines such as their mechanics or their visual elements for the modells we would need. We delayed any practical development until we had confirmation of the brief from the royal navy contact because we didn't want to waste time developing anything if it wasn't going to be used. In retrospect this may have been the wrong decision and I think if I had the opportunity to go back to the start as team lead I would make a different call, which is useful knowledge for future projects. This didn't just impact the practical development but also the team dynamic as we had started strong with plenty of excitement and enthusiasm only for this to quickly dwindle as everyone become increasingly more anxious with what their roles and tasks were within the team. Personally this hadn't impacted me much as whatever the brief was it probably wouldn't impact the audio too much.


Skipping ahead to when we were finally given the brief we begun work and unfrotunately the team dynamic had realistically suffered too much. We weren't able to work quickly or effectively as a team for much of development due to communication problems and disagreements surrounding mechanics and working times. Overwhelmed with the task of singlehandedly trying to tackle both the multiplayer and the VR our original team lead stepped down and handed the responsibility to myself. From there we tried to reorganise ourselves and change up our approach. We had meetings with our client to discuss our progress as well as implementing new measures such as stand-up inspired progress meetings, peer review, role specific task delegation using trello as well as an action plan. This was a rocky transition as we adapted to a new way of working and a change of leadership, I personally needed to get up to date with what everyone had been doing and what was left to do. There was a lot of progress accross different areas of development; 3D modelling / texturing, UI visuals and programming, Sound design and implementation, gameplay mechanics etc... But little to none of it was combined anywhere. One of the main tasks we set out to do was to begin collating everything which then brought to light many smaller implementation tasks and reworks. The scope of the game was cut down to single player non VR at a push. We contacted the navy and discussed this with them and fortunately they understood. As we pushed ourselves and eachother to create something we were incredibly proud of our team dynamic was continuously tested and as a team lead I believe I did what was best for the completion of the project. However in future I will try to create a more well structured way of working from start to end using all the techniques I have learnt this year. I will use a game design document religiously as well as keeping trello boards up to date and clear with a heavily inspired kanban system. I will also encourage face cam on team meetings to help improve communication. More clearly structured file organisation for both In-game and general files, documents and assets as too often has the phrase "where can I find that", been uttered in recent projects. The biggest most key takeaway from this project is that crunch in games is not favourable and should be avoided when possible, this may even come at the cost of a more relaxed development process.


So in as few words as possible:

Encouragement, enthusiasm and organisation are massively important skills for succesful leaders in game development. Consciousness of scope, time and the skill of your devs, is equally as important for producing polished and playable games which people enjoy.


And on a personal note, I consistently surprised at how much I have learned in such a short period of time.

8 views0 comments

Recent Posts

See All

留言


bottom of page