A game uncopylocked - and some advice for lazy developers. Feedback is also highly appreciated.
Game Link
It’s uncopylocked. Heres the link.
https://www.roblox.com/games/4818917439/DRAW-Ultimate-VR-Playground
→ An introduction
This resource likely wont apply to many of the developers who reside in the these forums. Actually, it’ll likely only apply to a small minority who read this. Over the past saveral weeks me and my friend, and developer @LuaPharaoh have been working on various VR-Related games - with our main successor being Ultimate VR Playgrounds. We made the game after seeing Skeds VR Playgrounds and noticing how popular the game was - even with its very trivial and easy code. So I decided to set off on the task of designing a game that improved on his playgrounds - took an almost identical concept but added to it. @LuaPharaoh reluctantly jumped on board.
If the project and code is so bad, why even open-source it?
Two reasons - feedback. And for those who’ve relentlessly begged us to do so. Even though I would like to attach a huge disclaimer that this code is not good - we also understand that some developers don’t really care at all about that. - And just want to build a game that works with VR similar to this playgrounds one.
Some Advice & Feedback
This advice comes directly from the mistakes we’ve had to reflect on over the course of this project. Like I said, the majority of you developers who bark on the gruling task of looking through this games code; will cringe and wince at many of the things we’ve done. I would really like to hear from those more motivated than me - not only some feedback on how I can improve. But also in regards to some questions;
- Are there specific methods or ways you practice to avoid botching a much as possible? How do you not fall into an endless loop of botching and bug-fixing. Is it just experience?
- What actually helps keep you motivated to not only just keep developing a game, but to keep developing it well - without using easy shot-cuts that will eventually bite you in the bum.
Here is some advice - or at least reflection of things we did in this project. That we should’ve of. And developers like us - will probally relate to this.
Don’t assume cause your game is ‘better’ than another, it’ll do well
This was one of the biggest flaws of this whole project. The idea that our game was both more functional and more feature-filled than Skeds. - which biasly I would say we achieved. We easily had more funtionality than his game and our systems were perceivably better - by far. In total we threw a mere (however our whole) 25k robux on advertising. With some free advertisement from some bigger youtubers. Even in the peak of the game we only managed to maintain 60 players, totaling (current) 32k visits and not even getting a quater of the investment back. (Most of which was gained by actually directly purchasing robux).
Botching becomes a black hole that consumes the whole project
It’s easy enough to start a project with nice modular code and good practices. Maintaining the same casing - and having code that is really nice and practical to look at. But once you get a taste of the botch - it really does consume your project. This was a huge mistake on my part - a few botches were thrown in place early on and after that it was entirely down-hill. Each subsequent system became a botch - code simply thrown in to patch together something. It had no modularity or future-proofing. My whole coding philosophy was to simply throw code in and then go through error by error until it worked. After that I’d wish and hope that code would never be opened again (spoiler, almost always it would cause future issues which became bigger and bigger as the project went on)
Sanity checks can’t save bad code
Countless times when code would go bad - we’d fix it by simply throwing a sanity check at it. If something was nil - couldn’t be found, or was an incorrect type. An if statement to make sure it was, otherwise ignoring it. The underlying problem of the code being inpractical for what it was doing wasn’t really questioned. I really think there was a huge mistake here though this lends itself to the botching technique.
No continuity between scripts, or even code blocks in some cases
CamelCase? pascalCase? snake_case? We have it all! This is more of a preference thing - I guess, but there was no real practice in how we did the casing. Sometimes Services were done entirely CAPS, sometimes they were done in snake_case. Some functions were local whilst others were not - for no real reason. Small things such as feeding events straight into a function rather than actually calling back to one. - you would think there was at least 5 developers on this project. Not 2 - due to how all over the place the code was.
Conclusion & a question of advice
Overall the project was a complete failure - VR Hands 3.0 released and not only improved on Skeds but entirely smashed our game too. Beating both ours and skeds by a land-slide, not only in functionality but in player-count. The whole project was demotivating - we were happy for the players and community we built but then extremely dissapointed in the failure to expand - or build a bigger one. Once the new game released we entirely cut our chains to the game - which was just eating development time to fix bug after bug, and botch after botch. To have very deminishing returns.
The only positive from this game was the feedback we had from players, who were extremely and motivating. Telling us how much fun they were having, and how much they enjoyed the game and wanted development to continue.
