For our group project we helped develop an emotion recognition package for game development in Unity. The package allows Unity to record microphone data and transmit it to our cloud backend built with microservices. These microservices would translate the data to emotion data and send this back to Unity. Game developers can then use this data for whatever they want.
For my personal project I mimicked some elements of an MMO game. For now this includes an inventory and Auction house. T
During the development of our group project we made agreements to ensure that development of the project would go as smooth as possible. When things were not working out we would look at the problem as a group and make a decision together.
Together we setup a cooperation contract, agreed on programming conventions and set up a scrum board to keep track of tasks and things we have to do. We also wrote peer reviews after the first and 4th sprint and made agreements where things fell short.
Halfway through sprint 2 we had to work from home because of the corona crisis. In order to better keep track of what everyone is doing, we had started doing daily stand ups to inform everyone what you have been doing, what you are going to do and what problems you are running into.
At moments where we had fewer but bigger tasks to do, we would employ pair programming to speed up development. This Worked out really well and we could learn a lot from each other as well.
To streamline our version control we made use of a DTAP approach and merge requests.
Click here for more info
For both my personal project as well as our group project Unity was chosen as the primary frontend.
Because of this It's important for us to know how to properly communicate with for example a Spring boot backend. For both project we will utilize REST calls for direct communication, however for my personal project I also need to use Websockets so that the backend can notify the frontend for changes.
REST calls are natively supported by C# and Unity so those were easier to implement, however after some research and looking around it became clear that websockets are not natively supported and require a library.
In our group project I noticed some strange behaviour in the results we kept getting from vokaturi. Vokaturi is an emotion detection software that uses audio data, but it almost always returns the angry emotion. I decided to investigate what is causing this and how it could possibly be fixed.
I'm planning on graduating in Game design so I will be working with Unity more in the future. I think it will be useful to already have some knowledge on things like REST calls and websockets in Unity for the future.
When I started this semester I had little interest, slightly more now, in CI/CD and development pipelines. I know they can improve a workflow a lot when it is properly set up, but from experience from this semester they are really hard an finicky to set up. Myself I want to graduate in game design and I do know that these kind of pipelines are used in that field, but I want to focus more on gameplay programming instead of backend or server development. I do think it is useful knowledge to have for the future. I'm sure that at some point I will have to work with these kind of pipelines again, maybe even in my internship.
For my graduation internship I would like to actually work on developing a game. In my first internship I primarily worked on tools that would be used to further develop a game, but I want to focus more on gameplay programming. Write code that makes the game work.
Are DevOps and CI/CD my cup of tea? Definitely not. Will I take this knowledge with me into the future? Absolutely.
Microservices should be able to work independently from each other. One system dropping out should not break the rest, the other services should stay working. This presents a challenge when services have to communicate with each other.
As an example, let's say a user wants to start an auction for an item they own. The client will first send a REST call to the inventory service in the backend to check if the user actually owns the item. This is done to prevent people from posting auctions of items they don't actually own. When the inventory system concludes that the player owns the item it will remove it and send a message to the auction service. If this auction service were to be down but the inventory service is still up and running the backend would remove the item from the players inventory and never actually start the auction. Of course this is a problem.
To fix this a message broker can be used. A message broker can hold messages in queues. When a service is ready it will take a message from the queue and process it, if it is successfully processed it will remove the message from the queue. In case it was not processed correctly it will still exist in the queue for a next attempt. This also means that messages will be stored if no services is available to take the messages. Because of this messages are assured to eventually reach their destination.
Now, using a message broker, when a user wants to start an auction the inventory service will still remove the item from their inventory, but if the auction service were to be down it will store the auction creation message in the queue for when it comes back up. When it does it will automatically take the message and post the auction.
For a more detailed diagram of all involved services and the communication between them click here.
For continuous integration I have set up a Jenkins pipeline in azure. This pipeline will automatically retrieve the code from github, and run some preconfigured tasks. In my pipeline implementation it will run the code on github through SonarQube and puts the results on sonarcloud.io. If the quality gate passes it will build the projects and deploy them on a kubernetes cluster hosted on azure.
Click here for more info.
I have hosted my microservices on a kubernetes cluster in Azure. I have chosen for Azure because students get some budget for free as well as the well documented tutorials which allowed me to set everything up very quickly. When the Jenkins pipeline finishes a build successfully it will automatically deploy the new version on the kubernetes cluster hosted in Azure. The kubernetes cluster can also be monitored directly in Azure.
Click here for more info.
Each of my microservices has their own database instance. Only user account names have to be shared between services. As explained in chapter 4 Scalable Architectures, when a new user account is created the authentication service sends a message to the other services and tells them to create an object in their database representing that player account.
User accounts only consist of a username and password. Only the authentication service knows of the users passwords which are encrypted.
When a user logs in, the authentication service will return a token to the user they can use to authenticate with other services. These other services do not store this token anyway, the other services only know of the accounts username in the database to check against when retrieving user data like owned items.
Click here to view the data models.