Revision of OpenSBC Devlog #1

Bluefield revised this gist 1787705425. Go to revision

1 file changed, 21 insertions, 15 deletions

DEVLOG.md

			@@ -81,31 +81,37 @@ Let's analyse them:
81	81
82	82		The Polytoria client (and studio) are production-ready systems, maintained by a wide community and batteries included. However, it's built in Godot, and although Godot's capabilities are excellent for making games, there have been complaints about performance...
83	83
84		-	- Performance: 5/10 - Not great, mainly a Godot byproduct, though it could probably be worked on.
85		-	- Contributor Potential: 8/10 - Lots of Polytoria developers (and staff) are present in the OpenSBC community.
86		-	- Readiness: 10/10 - 'Drop in' solution.
87		-	- Maintainability: 7/10 - Well documented, well known.
88		-	- Dependency: 5/10 - Not many third party tools beyond Godot and the Lua library, but there would likely be some dependency on the source of the fork for updates.
	84	+	\| Category \| Score \| Notes \|
	85	+	\| --- \| --- \| --- \|
	86	+	\| Performance \| 5/10 \| Not great, mainly a Godot byproduct, though it could probably be worked on. \|
	87	+	\| Contributor Potential \| 8/10 \| Lots of Polytoria developers (and staff) are present in the OpenSBC community. \|
	88	+	\| Readiness \| 10/10 \| 'Drop in' solution. \|
	89	+	\| Maintainability \| 7/10 \| Well documented, well known. \|
	90	+	\| Dependency \| 5/10 \| Not many third party tools beyond Godot and the Lua library, but there would likely be some dependency on the source of the fork for updates. \|
89	91
90	92		### My own Godot client
91	93
92	94		Making my own client in Godot from scratch... Well, it'd definitely carry some weight.
93	95
94		-	- Performance: 7/10 - Better, since I'd have total control over how entities work in the engine.
95		-	- Contributor Potential: 5/10 - Although it's a custom client, it's still Godot, so anyone with game dev experience can contribute.
96		-	- Readiness: 3/10 - I'd be working from 'nothing', but Godot's tooling makes it easy to cover many of the steps.
97		-	- Maintainability: 4/10 - Godot offers some good opinionated project structures that make it easier to maintain in the long term, but there'd be tons of systems I have to cover entirely...
98		-	- Dependency: 9/10 - Full control over the dependencies, except for Godot itself and its plugins. Pretty good!
	96	+	\| Category \| Score \| Notes \|
	97	+	\| --- \| --- \| --- \|
	98	+	\| Performance \| 7/10 \| Better, since I'd have total control over how entities work in the engine. \|
	99	+	\| Contributor Potential \| 5/10 \| Although it's a custom client, it's still Godot, so anyone with game dev experience can contribute. \|
	100	+	\| Readiness \| 3/10 \| I'd be working from 'nothing', but Godot's tooling makes it easy to cover many of the steps. \|
	101	+	\| Maintainability \| 4/10 \| Godot offers some good opinionated project structures that make it easier to maintain in the long term, but there'd be tons of systems I have to cover entirely... \|
	102	+	\| Dependency \| 9/10 \| Full control over the dependencies, except for Godot itself and its plugins. Pretty good! \|
99	103
100	104		### My own client from scratch
101	105
102	106		Now this is dangerous territory...
103	107
104		-	- Performance: 9/10 - Full control over memory allows one to do some magic tricks!
105		-	- Contributor Potential: 1/10 - Good luck navigating my codebase...
106		-	- Readiness: 1/10 - I'd have to figure out every step of the way, from rendering a cube to being able to see my own UI...
107		-	- Maintainability: 1/10 - Ask any game dev if they've maintained their own game engine for longer than three months. (they haven't started working on the game yet)
108		-	- Dependency: 10/10 - Would run on TempleOS.
	108	+	\| Category \| Score \| Notes \|
	109	+	\| --- \| --- \| --- \|
	110	+	\| Performance \| 9/10 \| Full control over memory allows one to do some magic tricks! \|
	111	+	\| Contributor Potential \| 1/10 \| Good luck navigating my codebase... \|
	112	+	\| Readiness \| 1/10 \| I'd have to figure out every step of the way, from rendering a cube to being able to see my own UI... \|
	113	+	\| Maintainability \| 1/10 \| Ask any game dev if they've maintained their own game engine for longer than three months. (they haven't started working on the game yet) \|
	114	+	\| Dependency \| 10/10 \| Would run on TempleOS. \|
109	115
110	116		As we can see, each one has its pros and cons, but my best choice out of them all is to fork Polytoria's client and make the best of it.
111	117

Bluefield revised this gist 1787705267. Go to revision

1 file changed, 124 insertions

DEVLOG.md(file created)

		@@ -0,0 +1,124 @@
1	+	# OpenSBC, Devlog #1: "Rethinking the web side of things"
2	+
3	+	Greetings everyone. I know devlogs usually come in the form of easy-to-consume videos that you can skim through; unfortunately I am a busy person, and videos aren't necessarily my forte. Therefore I am writing this instead.
4	+
5	+	Now, let's get straight to the point. Today we're going to be talking about the following topics:
6	+
7	+	1. The web and its commitment issues
8	+	2. À la clientèle
9	+	3. In need of an average Joe
10	+	4. Naming the sword
11	+
12	+	Let's begin with the first one...
13	+
14	+	## The web and its commitment issues
15	+
16	+	Nothing scares an engineer more than the thought that the system they are building today, on a beautiful greenfield of code, is the system they will have to maintain a few years from now. Greenfields have a habit of becoming somebody's problem, and that somebody is usually the person who planted them. So maintainability and scalability come to mind quickly, and the two of them together can be quite overwhelming.
17	+
18	+	I am that engineer, and building OpenSBC is no easy task. There are a lot of moving parts, especially given the 'modular nature' of OpenSBC, which is meant to let anyone edit their platform quickly and easily without having to touch code.
19	+
20	+	That of course leads us to the question: how do we build such a system without losing our minds, and how do we build it so that it is accessible to everyone who wants to help and contribute? Finding the balance between complexity and contributor friendliness is hard.
21	+
22	+	Sure, I could spend the next five months developing a complex plugin system in Go with Chi as my HTTP library, writing tons of custom libraries and systems along the way, but then finding contributors would be extremely difficult, since nobody would recognise the shape of my codebase or my standards. Onboarding a contributor would mostly consist of me, apologising.
23	+
24	+	Yes, I could throw in tons of documentation and try to 'make it easy', but maintaining all of those systems would quickly lead to the exact opposite of the maintainability and contributor friendliness I was after in the first place. Do not misunderstand me though: I do want a cool plugin system. The point is that the amount of work it involves means effort has to be moved to it from somewhere else. Effort is not free, and I have yet to find the setting that makes it so.
25	+
26	+	If I want to build a dynamic plugin system, I'll have to make sacrifices on things like advanced routing engines and the other web-side machinery. I'll need something to polyfill all of it. That something is Rails.
27	+
28	+	I've made the decision to go with Ruby on Rails for the entire backend and frontend of the website system for OpenSBC. There are many reasons why, but these are the most obvious ones...
29	+
30	+	### Ruby is simple - Rails loves simple:
31	+
32	+	Building an MVC based platform on Rails is probably the easiest of them out there. Little to no boilerplate, tons of built-in functions, and a design that simply glides while you work on your platform. It lets you focus on what you want to implement rather than on how exactly you want to implement it.
33	+
34	+	### Rails is mature - and the source of truth:
35	+
36	+	Ruby on Rails has had such a spectacular development history that it has been used as a reference by tons of other frameworks (AdonisJS, Laravel, NestJS, and so on). Not only that, it's also extremely batteries-included. We're talking so 'included' that you don't need many dependencies at all. Which leads us to the third point...
37	+
38	+	### No deps? No problem:
39	+
40	+	I spoke with Primitive recently on Anomia about how supply chain attacks have become more and more common lately, and it really makes sense. Almost every library or package out there has multiple layers of dependencies, each of which has its own, which have their own... It's turtles all the way down, except the turtles were last touched in 2016 by someone who has since moved on with their life. It's a massive surface area. And that's something I have to keep in mind as the maintainer of this project, because if a supply chain attack does happen, I'm the one responsible for it.
41	+
42	+	That concludes the first part of the devlog. Now onto the next...
43	+
44	+	## À la clientèle
45	+
46	+	Vertexia's developers are probably tired of me constantly making changes to their engine and then never opening a PR for any of them. Truth be told, I scrapped most of the work I did on the client, and the reasoning is mostly the same as in the earlier section: maintainability and scalability.
47	+
48	+	While I was working on RaveEngine, I made some 'drastic' changes to it, especially around scripting, physics and rendering... These were generally positive, but they came with the strong caveat that maintaining them had suddenly become a much bigger headache than expected.
49	+
50	+	### Example 1: Switching from Avian physics to Jolt
51	+
52	+	I wanted Jolt physics. Why? Because I fucking love Death Stranding.
53	+
54	+	Okay, jokes aside. Jolt offers some insane physics systems right off the bat, and I was very interested in bringing them to RaveEngine, since doing so would directly translate into RaveEngine having a plethora of physics systems readily available in the studio and the client.
55	+
56	+	However, there was one big caveat I hadn't been too thoughtful about... Bindings.
57	+
58	+	Jolt is written in C++, while RaveEngine is written in Rust... you can probably see the problem already. I did manage to 'expand' an existing bindings library for it, but after four hours of debugging why a ball was bouncing higher than gravity should allow, I realised I had just spent four hours working on a bindings library rather than on the studio itself.
59	+
60	+	And that pace, for a project the scale of OpenSBC, is simply unacceptable. So I decided to drop it. I then took a look at the rest of RaveEngine, and came to another conclusion...
61	+
62	+	RaveEngine is too early and too immature to be used at scale. As much as I love the team behind it (DevJuiced and Xampp are doing great work!), the engine still has too many failure points built into it for me to adopt and build on top of. My first PR alone was nine tenths bug fixes and exception handling.
63	+
64	+	So for the game engine I have three options:
65	+
66	+	- use Polytoria's client (lower performance, but batteries included and a well maintained open source project)
67	+	- make my own in Godot
68	+	- make my own "from scratch"
69	+
70	+	For the purpose of portraying how I weigh scalability and maintainability, we're going to assign a score to each one of these across five distinct categories, and that will help us weigh whether it's reasonable or not.
71	+
72	+	- Performance - How performant is this solution? Is it fit for the scale of OpenSBC?
73	+	- Contributor Potential - How much potential does this have of drawing contributors in?
74	+	- Readiness - How ready is this solution if chosen? How much development time will it require to be production ready?
75	+	- Maintainability - How easy is it to maintain? Is there existing documentation, or is this a greenfield?
76	+	- Dependency - How much of this codebase do I own? What third party libraries am I taking on?
77	+
78	+	Let's analyse them:
79	+
80	+	### Polytoria Client
81	+
82	+	The Polytoria client (and studio) are production-ready systems, maintained by a wide community and batteries included. However, it's built in Godot, and although Godot's capabilities are excellent for making games, there have been complaints about performance...
83	+
84	+	- Performance: 5/10 - Not great, mainly a Godot byproduct, though it could probably be worked on.
85	+	- Contributor Potential: 8/10 - Lots of Polytoria developers (and staff) are present in the OpenSBC community.
86	+	- Readiness: 10/10 - 'Drop in' solution.
87	+	- Maintainability: 7/10 - Well documented, well known.
88	+	- Dependency: 5/10 - Not many third party tools beyond Godot and the Lua library, but there would likely be some dependency on the source of the fork for updates.
89	+
90	+	### My own Godot client
91	+
92	+	Making my own client in Godot from scratch... Well, it'd definitely carry some weight.
93	+
94	+	- Performance: 7/10 - Better, since I'd have total control over how entities work in the engine.
95	+	- Contributor Potential: 5/10 - Although it's a custom client, it's still Godot, so anyone with game dev experience can contribute.
96	+	- Readiness: 3/10 - I'd be working from 'nothing', but Godot's tooling makes it easy to cover many of the steps.
97	+	- Maintainability: 4/10 - Godot offers some good opinionated project structures that make it easier to maintain in the long term, but there'd be tons of systems I have to cover entirely...
98	+	- Dependency: 9/10 - Full control over the dependencies, except for Godot itself and its plugins. Pretty good!
99	+
100	+	### My own client from scratch
101	+
102	+	Now this is dangerous territory...
103	+
104	+	- Performance: 9/10 - Full control over memory allows one to do some magic tricks!
105	+	- Contributor Potential: 1/10 - Good luck navigating my codebase...
106	+	- Readiness: 1/10 - I'd have to figure out every step of the way, from rendering a cube to being able to see my own UI...
107	+	- Maintainability: 1/10 - Ask any game dev if they've maintained their own game engine for longer than three months. (they haven't started working on the game yet)
108	+	- Dependency: 10/10 - Would run on TempleOS.
109	+
110	+	As we can see, each one has its pros and cons, but my best choice out of them all is to fork Polytoria's client and make the best of it.
111	+
112	+	## In need of an average Joe
113	+
114	+	The title may confuse some, but the translation is the following: I need an avatar. OpenSBC cannot succeed on code alone, we're going to need some pre-made assets for people to use, and that includes the avatar. I still have not figured out the black magic required to allow fully custom avatars (though I imagine it involves strictly named bones on a 3D model to some degree). That is still a feature for future me to implement, and future me is accumulating quite a backlog.
115	+
116	+	For now? Preferably a simple Joe. A normal square avatar would do, but creative suggestions are very welcome!
117	+
118	+	## Naming the sword
119	+
120	+	As mentioned earlier in the Discord, I'm looking for a name for the 'official instance'. Now, I understand that naming a sandbox platform comes with certain challenges, which is what leads to most platforms being named alike. "Vertexia, Vistora, Vexor..."
121	+
122	+	They're SO common that I even made an automatic name generator capable of producing 7 out of 10 of the sandboxes out there... you can find it [here](https://totallylegitrobloxclone.neocities.org/)!
123	+
124	+	Name suggestions are welcome.

Newer Older