Devlog #8 - Usernames & Finishing Touches
Usernames:
To start off this week, after implementing the lobby's I realised that it was difficult to tell the difference between players. I remembered that the system for joining with a code was extendable to different authentication methods and other information that could be sent when joining. This meant that it could be extended to send a username along with the join request. Sure enough, I was able to receive the username on the Host. The problem was with being able to display the correct username on the correct character. This was done by storing a dictionary of all players and their usernames on the host and giving them a username through an RPC whenever the player was spawned in. I also did some minor bug fixing on some of the bugs that I knew the general cause of.
The Big Problem:
At this point development has started ballooning into something a lot bigger that the scope of this project. Continuously fixing bug after bug and the list keeps getting longer, most bugs being from the interactions that multiplayer has with the other mechanics. Since the project has become bigger that I ever intended it to be, I have decided to leave development here for now. Is this the best outcome and/or the one I was hoping for? No, but I fell like I achieved the purpose of the project from the beginning, being to learn how to make a multiplayer game. I have only just met the minimum viable outcome for this but I feel that it fine. In the process I learned so much about how multiplayer works that if I was to make a multiplayer game in the future I would have an incredibly strong starting point.
During the course of this project I feel as though I was too passive about a bug, just adding to to the Trello and moving on to implement more features. Perhaps, taking a more proactive rather than reactive approach to the bugs would have been better. Rather than dealing with them later, make an effort to fix as many bugs as possible when they are found. This could have made the rest of the project a lot easier if I wasn't having to step over bugs while testing features. However, if I was constantly fixing these bugs, the project at this stage might have never reached a minimum viable product so this approach will have to used in a different project to be able to say for sure.* In addition, a testing log for all of the features, with links to the bugs may have been a good idea. Being able to know what has been tested and what bugs have been found and how to reproduce them would have saved a lot of time.

The Future:
This project has been put on hold for now. Am I happy with the outcome? Yes, I learned what I set out to do in the first place and have learned a lot about the processes of managing more complex projects. It's unknown whether this project will be continued in the future but for right now there is a (slightly broken) but working multiplayer for the game.
*Edit (29-03-25): I have used this approach in an unreleased personal project (Hel's Champion) and this is a far better way to deal with the bugs. Since this is a group project, I have suggested that we have a good way to test and document bugs and features.
Files
Get Candy Corporate
Candy Corporate
CANDY FOR THE CORP. Lethal Company inspired game about trick or treating.
Status | Prototype |
Publisher | |
Authors | JürgenWithWings, Embit, FLOART |
Genre | Adventure |
Tags | 2D, Atmospheric, Creepy, Horror, lethal-company, Pixel Art, Short, Singleplayer, Top-Down |
Languages | English |
More posts
- Interview Reflection27 days ago
- Devlog #6 - Enemy Spawning & Syncing45 days ago
- Devlog #7 - Lobby & Join CodesDec 09, 2024
- Devlog #5 - Item Dropping & InventoryNov 19, 2024
- Devlog #4 - Item SpawningNov 11, 2024
- Devlog #3 - Network planning & Lighting OverhaulOct 28, 2024
- Devlog #2 - Tracking Bugs (& Version Control)Oct 23, 2024
- Devlog #1 - Deciding Version and Planning ResourcesOct 14, 2024
- Devlog #0 - Starting MultiplayerOct 09, 2024
Leave a comment
Log in with itch.io to leave a comment.