evaluation

Page contains my evaluation presentation and recordings, primary feedback on the almost final product and my written evaluation of the project.

Presentation

Primary Feedback

Meeting the Brief

My deliverables have ended up quite different to the vision I had set out in the brief, although the concept has remained mostly unchanged. I originally was planning on doing a futuristic-looking rhythm game with a whole narrative, or at least a context so what the player was doing felt like it had a purpose, however that was mostly scrapped as a selling point in favour of having a drastically different visual style to the majority of rhythm game and going for a more calming feeling.

Legally there are some issues with the game as I don't have the license to any of the music packaged in it. The actual release of the game wouldn't have any music to play along to, you would add the music yourself, and since I'm not distributing that music as it's already owned by the player it wouldn't infringe on any copyright. The main menu music however could be an issue as it is from the soundtrack of an old game (Mirror's Edge) as I couldn't find any royalty free music that was free and also fit the feeling I was trying to achieve for the game. I thought it would be fine to use it in the submission for the project however, as I recognise if I were to release the game publicly it would be generating income to fund me paying someone to compose menu music for it/paying for the rights for it, but as a student I can't afford to do that for one project. Another approach I could take with respect to this would be seeking a partnership with a music provider such as Spotify or Apple Music, and then allow people to play music via Spotify/etc by logging in, then we would have the license to use the music in and would also be good as a marketing strategy, as rhythm game players usually listen to music a lot outside of games too.

My planned target audience of ~15-20 year olds who are already rhythm game players hasn't changed, as the branding and gameplay is all suited towards those, but it probably does have a much wider appeal now the visuals aren't stylise and retro, instead going for a gradient/calming feel similar to mobile games which appeal to fairly large audiences. So the visuals are more accommodating but the gameplay and difficulty is still suited towards people with experience with rhythm games. The music available in the prototype is probably also more suited to rhythm game players as they were just music files I had on hand when making it, but in the full release of the game music taste wouldn't be an excluding factor as players would use their own music anyway.

I believe I've achieved a lot more than even I expected when I initially started working on this project. The final product is almost indistinguishable from the Photoshop and After Effects mockups I decided on earlier on in the project, I've fixed almost every bug that appeared while I was making it, and the game is actually quite fun to play. I've tried to log every change made during the planning and the production of it in my production log and write something to give context so anyone can see my thought processes and how my decisions have changed the way the game looks or works over time. I've been open to feedback from the beginning, from Akira, my classmates, and players I've found on the internet, and you can see the way their feedback has helped shape the project too, with several revamps of the visuals towards the beginning of the project as well as changes in the difficulty and functionality of the game when I realised I hadn't been considering newer players as much as I should have been.

In terms of features of the game I think I've gone above and beyond what I could have done. I made a fully functional (apart from adding new songs) executable of the game using C#, a language I had no actual teaching in, when I could have made a basic prototype like the one in the gifs at the start of the production log and only done the visuals, but I believed it would be more helpful for me to create the whole game as I want to study Computer Science at university. I also made a script using Python that could convert songs into files that my game could read and play, allowing for a library of 10 full length songs or so in the prototype instead of one or two short ones I made manually for testing. I've made a compilation video of the visual changes I've made to the game since the start, and even though it was because the person next to me also did one it provides a nicer way to look at it over time than quickly flicking through a slideshow. I've added some reviews on the main page of this website that change every time you refresh the page, taken from the feedback form I did a couple of weeks ago, done using knowledge of JavaScript. I think some of these extra features have made the project easier to assess as well as making it seem more professional.

The most challenging part of the project, surprisingly, was implementing the menus. As I had no idea how to make a UI in Unity it was all quite bashed together as I went along. It took 2 hours or so of programming and testing to make the bars representing the songs scroll the way I wanted them to, which was fairly mind-numbing. Since I figured I would change the song library I had to make the song boxes be generated when you entered the menu, rather than manually entering all of them, which meant I had to figure out the spacing of all of them dynamically as well as fitting all the text I needed to on the preview box and making those generated boxes link to the correct song in the gameplay part of the game, and also having them be the correct proportions at different screen aspect ratios. Pretty much everything programming related took 4 times as long as it looks like it would have done since I had to learn how to do what I wanted as I was going along.

Given it's lack of a competitive leaderboard it lacks any meaningful multiplayer compared to osu!, which is a feature people would want added to my game (slide 13), but I don't know enough about networking for that to be achievable in this particular school project. If I were to add multiplayer it would either be regular gameplay but synced with a live scoreboard for both players or there'd be some kind of twist on the gameplay, like a "hot potato" mode where it switches between players, or Guitar Hero's guitar battles where playing well gives you power-ups you can use to make it more difficult for your opponent. Compared to retail rhythm games like Guitar Hero it has less music in it initially but the ability to add your own music to it makes up for that. osu! has community made maps rather than a pre-existing set of tracks to play but it has a large enough community following that trusted volunteers can curate the maps and provide a platform to download and compete with them, that my game wouldn't be able to achieve without a large community following of its own, and that's a lot less likely to happen in my single-player calming game than in a competitive game like osu!

Issues and Problem Solving

The only issues I had that I couldn't resolve before the deadline was with adding your own songs and also some lag spikes towards the end of long songs/between scenes reported by people in the feedback form (slide 14-15).

I created a script that could generate the song files, and the game could read those, but when testing I loaded the songs into the Unity project before compiling it. This meant the way it read the audio is different to how it would read it if it was in your documents folder etc. I tried several different methods of getting Unity to read audio files after it had been compiled/at runtime and I couldn't get anything working while also devoting enough time to the other parts of the game. I think it might have been because the new version of Unity made an old module redundant but that old module is what everyone on the forums was saying to use, but I'm not sure. It is a pain that I couldn't get it working but if I were to actually release it that would be the first thing I tried to fix.

The lag spikes I think were due to my code just not being optimised very well and having to read a lot of data every time they loaded. That kind of thing can only be solved by me combing through the code and making it cleaner, or entirely rewriting how I did some things and it didn't seem worth it to spend lots of time making it half a second faster to go between scenes with everything else I had to do.

The first issue I overcame was with the visuals of the game. I was trying to hard to force the convoluted context I had come up with into it and it was making it look dull and kind of generic. After doing more research into graphic design principles and colour theory, as well as surveys on why people played rhythm games, I had a better idea of what I wanted the game to make the player feel like and how to go about it, which led to me abandoning the context and making it more focused.

Another issue I had was with the song generation script, where the library I was using detected the beats of the song, rather than the rhythm, making it less of a rhythm game and more of a metronome simulator. After doing a lot more research and looking into how games like Audiosurf generated their levels I realised what I was looking for was actually called "onset detection" rather than "beat detection". Another issue I had was with the song generation script, where the library I was using detected the beats of the song, rather than the rhythm, making it less of a rhythm game and more of a metronome simulator. After doing a lot more research and looking into how games like Audiosurf generated their levels I realised what I was looking for was actually called "onset detection" rather than "beat detection".

Another problem was my difficulty calculator. I was putting lots of weight into things like the note speed or health drain which was entirely arbitrary and not enough weight into the note density (how many you had to hit per second). This made some of the songs say they were easier than they actually were when generating them, which lead to the majority of people who tested it early on saying the ones labelled easy were actually hard/the labels didn't reflect the actual difficulty. From this feedback I looked back and based it entirely on note density (which I realised I was calculating wrong anyway and had to rewrite). I then made the health drain constant across all songs and made the approach rate (speed of the notes falling) adjustable with a score modifier, so you were rewarded for playing the harder modes successfully but also had the option of not doing so. The difficulty labels were much more accurate but it also showed the majority of the generated songs were in the top half of possible difficulties. In order to find easier songs for new players I adjusted the generator script to accept song files from rhythm games like osu!, so I could give it a timed file from that game that was easy enough and it would convert it to the format my game could read. I got someone who was a fairly new rhythm game player to find some songs in those other games that he was comfortable with and were slightly too hard for him and used those in the prototype just so I had a good range of difficulties for when I sent it out for testing.

Most of the other issues I had were with programming, and solving these usually followed a pattern of me trying to code it how I theoretically thought it should work, it not working, then me googling and researching for an hour and changing bits until it did, so I won't go into too much detail with them.

Successes

3 things I liked about my project:

1. It was surprisingly functional and I learnt a fair amount getting it to that point
2. It looks a lot nicer than I was expecting it to when I first started the project
3. Other people seemed to enjoy playing it

1 - Going into the project I had very little experience with C# and Unity. I made a functional but buggy and not particularly enjoyable game for the Game Jam unit in Year 12, so I knew I'd be able to make something vaguely representing a rhythm game before I went into it, but in my stress towards the start of the project that I wouldn't be able to I spent a while researching and testing and I ended up having a playable prototype before I even did the pitch presentation, leaving me a few months to refine it and develop the visuals without having to worry. The UI also turned out a lot more functional than I was expecting while still looking nice and like the mockups, and was ironically harder to program than the actual gameplay part. Since programming skills are quite transferable between languages this project has given me some pretty good experience for uni/later life even if I don't actually end up using Unity or C# again.

2 - When I came up with the context for the game initially I had an idea of what I wanted it to look like, but when it came to actually sitting down to mock it up I realised the idea was a lot less clear than I had thought. Looking back at it the ideas I had were pretty generic too, so I'm glad it didn't end up looking like that. With guidance from Akira and other people giving feedback I was able to shape it into something minimalistic that I believe filled it's role pretty well.

3 - The feedback from the google form and just people I got to test it in general was a lot more positive than I was expecting it to be (slide 2, slide 12). It's likely they were just being nice since everyone who tested it I had some connection to beforehand but it's a pretty good feeling to make something interactive and then see people enjoy interacting with it, and it certainly made me feel more positive about the project as a whole.

If I were to go back and improve the project now, I'd probably add more game modes, as based on the feedback I got the lack of variety in playstyle meant it wasn't incredibly replayable (slide 13). I'd also spend more time researching how to load audio in Unity because a fair amount of the suggestions in the feedback form were song requests, as clearly my music taste is slightly niche (slide 13-14). Finally I'd probably go through all the code and rewrite/optimise bits to decrease load times. With my inexperience dealing with compiled languages like Unity there is probably a lot of badly structured code in there that I didn't pick up on while writing that would concern anyone who actually knew what they were doing and would explain the long load times. Some things in there I did recognise could be done more efficiently, like the song loading, but it wouldn't have made a substantial enough difference to justify going back and improving it slightly given how much work it would take.

Visually I don't think there are any adjustments I would make, apart from reading textures from a file so people can make their own "skins" and allow for greater customisation, another thing a couple of people commented on in the feedback form.

Progress and Learning

Technically, I believe I've improved as a programmer. I've now got to the point where I'd consider myself above a beginner in C# and Unity, and all of this was learned by attempting something and googling when it went wrong. I'd probably be confident enough to start projects on my own in Unity, and I was able to help a couple of Year 12s fix things in their projects like collision glitches and animations not working before the show using knowledge I had gained while making this game. I've improved a little in Photoshop/After Effects too, making better use of things like blend layers when designing in Photoshop, and gained a bit more experience in some different Effects in After Effects when making the trailer/production time-lapse videos, but none of it was particularly groundbreaking new techniques that changed the way I did things in those programs. Maybe if I were to do the project again I'd try and be a bit more experimental with the visual designing to try and make full use of the capabilities of those programs. As I've mentioned before I'd also pay more attention to the optimisation of the code I was writing and make sure it was up to a good standard, as evidenced by the long load times it just being functional doesn't mean it's the best it can be.

In terms of project management I think I managed the project fairly well. Through the use of the gantt chart I had a fairly good log of what I had a plan to do at the beginning of the project, and I ended up sort of following the schedule I had set out for myself. Halfway through the project I started doing bi-weekly todo lists to evaluate my progress and plan what I had left to do, as with my designs changing various parts of the gantt chart became irrelevant. I also started making my production and research log as soon as the project started, and tried to log everything within a day of me doing it, which I haven't been very consistent with in past projects. It proved very helpful for remembering what I was trying to do each day, and evaluating the project as I was going along as I could flick back and see it changing over time. That said these aren't really new skills I've learnt and rather skills I knew I should have had beforehand that I'm being more consistent with. If I were to do the project again I'd try and keep the gantt chart up to date and change it as I went along rather than going back to check it every few weeks and ignoring the now irrelevant bits, and also log the feedback I got a bit more formally than just images in the research log so it would be easier to refer to later on.

Design wise, I've learnt a fair amount about designing a UI for a game, after reading up on what people expect and looking at examples. I've also got more experience in designing a kind of minimalist UI, which I had done for the website project last year. Even though I had a bit of experience with minimalist design a video game UI was very different to a website, so I still had to experiment and research before the UI actually ended up looking good. I also did research into colour theory, and effects of shapes and gradients on people to influence the design of it too. I also learnt quite a lot about designing a game, balancing it and making it suitable for the whole audience. On more than one occasion an issue people had with the game when giving feedback on it was because I hadn't considered it from their perspective (e.g. the difficulty of the lower level songs - they were fairly easy for me so I assumed they would be for everyone else even though I had just spent the last few months play-testing the game). If I were to do the project again I'd probably change the way I did the mockups, as for this I made a mockup then had to wait until I could show it to Akira, then I'd do another one based on the feedback and would have to wait again. I probably should have been making several mockups at a time rather than one I liked and tweaking that, but it turned out okay in the end because there was still a lot of iterations and improvements made to it that way.

Videos of Presentation

Phone ran out of space halfway through so had to resume with a different device.