It drove me nuts that GMod multiplayer games were declining rapidly in quality over the years and I wanted my own platform that had faster load times, better out of the box game mode experiences and so on. And I actually did it.
Due to some licensing agreement change issues with Valve, I ended up not taking it to the storefront.
But prior to that, I didn’t spend enough time marketing the mod anyway. Those who knew about it seemed to pass along some encouraging words, which was nice.
These days I work on Planimeter’s Grid Engine instead, and I have the freedom to do new things with it. But of course, new is always hard.
Anyway all that to say this reminds me of Minecraft, which is obviously a fun game. And if this has Lua and some proper bindings, it’s gonna be a blast. I’m sure it already is.
But it’s hell on earth trying to get people to play a game that is a spiritual derivative—of another well-established game.
Have fun developing this. But do it for you. Like I did Half-Life 2: Sandbox for me. All these years later, my mod still runs better than even the latest version of GMod. It does that because I put more care into it.
But since the Source SDK 2013 base is frozen in time, and there’s no usable Source 2 SDK, no one plays it. But that’s OK. I had fun.
In a similar manner, I sort of wish there would have been someone from the gaming generation before me, maybe a Quakeworld player, who would have passed on the same insight.
Projects this large will take years of your life in development time. You only get to work on some many of them. Ask yourself if you want to see yourself working on this in 5-10 years, or a similar title.
We love each day we spend working on this, so yes we definitely see ourselves working on it in 5 - 10 years. ^^
You're right about about the fact it may be hard to sell spiritual derivative at the beginning.
We realized many Minecraft players only play for a few weeks when there's a major update (~once a year). Mainly because of the lack of renewed content and the lack of very diverse experiences. This is where Roblox excels.
We want Particubes to become an alternative for them, when they're done playing Minecraft and still want to play in a familiar environment where they can interact with everything.
We're still big Minecraft fans ourselves (as players and server admins). Particubes is a way to fix some of our own frustrations with it, but will end up being a very different product.
Also, sorry to read about the licensing agreement issues with Valve. :(
We thought about building a good scripting environment for Minecraft instead of building our own engine, but depending on it felt risky, and since we're in for the long run...
No one really articulates that level of project planning in this space, so let me be the person to mention it.
You could be working on updating the user interface while you're asking yourself if you need to really be focusing on this, or finding a new job so that you can afford that engagement ring, or asking yourself what features or bug fixes you need to prioritize in the middle of having your car fixed.
You might end up postponing voice chat until the next major release because you can't get a week of time to yourself because Valentine's Day is coming up and you haven't planned how dinner and a movie is going to work with COVID-19 changing what is possible.
You know, stuff like that. Because you're definitely going to have full-time affairs while working on this stuff.
And don't just focus on the product. So many great developers who have the skill to work on these projects focus 100% of their time on the actual product, which is of course, critical. If you don't have something good, no one will play it.
Keep in mind that at some point in time, you'll need a strategy to move from 100% development and documentation to a near minimum 60/40 of product development and marketing.
Far in advance, figure out what your penetration strategy is. For example, what forums you need to establish a presence on, what fledgling YouTubers you need to create relationships with, how you incentivize kids to share the game with their friends and what devices they're using. The latter most being perhaps the most difficult space to understand, since I constantly hear no one uses a desktop or laptop anymore.
You need to have spreadsheets of this stuff and measure how you're making progress in creating a headspace for your product in people's minds based on their routines of where they go to hang out and what content they consume.
Best of luck! You have a great piece of software here, just keep it up. If you want to play it, there's bound to be others who want to, too.
More in depth:
The main problem with minetest it is that it seems not complete/done on the art assets and main game, and the devs always say that is intentionally not a Minecraft clone yet people come searching one on the subgames.
That being said, we agree supporting web browsers should be on the roadmap. But we’re a small team, it’s just not a priority currently.
I've decided on not doing anything which isn't "open website X" -- it's far too hard to teach twenty 10 year olds, and their parents, how to install some program, set up account, etc. etc.
For something that would be used for 2-3 weeks for most of the class, getting 20 copies installed on student computers is harrowing. Our 6th graders are allowed to use Chromebooks, too, (7th-8th graders need a real computer) so not everyone has a full-fledged computer. If we go the phone route, many parents hold the app store passwords to control what apps the student installs... and some of the 6th graders don't have phones, anyways.
Computer labs aren't really used so much anymore (and can't be this year), but if we were to go there I'd still need to either beg facilities/IT to spend limited time installing it or go install it on 20 devices myself with credentials I'm really not supposed to know.
If browser isn't a near term priority, maybe don't say "coming next".
Just getting 2 copies of some robotics control software installed among all the students in my most recent class (picking the people with the most "normal" looking computers who were most eager to install something) chewed up a big portion of my attention for 2 class sessions, and we only meet 3 times per week...
Devs out there: if you make something like firebase that lets you realtime sync in-memory server data (instead of db data like firebase) among clients in a cost-efficient way such that it's viable for multiplayer browser games and mobile apps, there are a lot of people who would pay for it. Me most of all. I would pay $100+/mo on a starter plan for it, even before I scaled.
You really have to have serious technical chops to do this well right now, and it's a big barrier to entry.
The 19yo who wrote Agar.io single-handedly is nothing short of a savant.
Godot also makes it very easy to export games to be run in the browser.
But if your goal is not networked physics, it's certainly a much more simple problem!
Are you wanting something like a cloud-based ... browser/cache basically a users localstorage/db/browser data would be synched in the same format in the cloud?
How are you imagining this? (Burned out dev, looking for a side project).
I just wish there was a SaaS (much like firebase) where you sign up and have an API that lets you define the data that your game-state involves (which may be a large schema), and then provides you with a suite of methods for letting clients create, find, and join group sessions ("games", "matches", however you want to call them) where the game-state is synced across all clients in that session until the game ends, with each client being able to modify the game-state within defined limitations (i.e. play the game.) I suppose the server would have to know under what conditions a game ended so that it could notify all players and end the session.
It just seems very daunting to me.
With that said, I also want something like this and definitely think it's a problem worth pursuing. I know there's Photon for Unity but I don't know what it actually provides and it's obviously tied to a specific engine.
I know, I'm side tracking from productive conversation, sorry for that.
Of course, a lot will have to be done by you for anything like client-side prediction, server reconciliation, lag compensation, entity interpolation, but knowing that the state manages itself is already a huge relief if you are unfamiliar with these concepts.
Another project which already includes many of these features is https://github.com/timetocode/nengi. It is more opinionated and well focused on fast-paced games.
On my side, I have been creating an open-source multiplayer game for the browser that includes client-side prediction, entity interpolation and server reconciliation https://github.com/halftheopposite/tosios.
For the middle part, i developed https://github.com/NewChromantics/PopNotPoker as an alternative to boardgame.io for easy room creation, sharing, and most importantly to me, exetremely easy game rules (all async js)
The "netcode" would be stuck on top (player movement, voice chat etc), using a bit of player meta for say webrtc session sync (or udp addresses etc etc)
This is an approach I used for 25 years on pc, console and now vr & web games; have "keyframes" where the server/authority dictates new game state to everyone, and everything else is client side predicted and throwaway
I've been working on a new game on and off which is a bit less working with websockets directly and I looked at ably to be that firebase like system, I've found it works reasonably well if you squint, though it's definitely not the same thing.
You can hack together a pretty nice implementation which gets you started using for example using presence to store a minimal dataset associated with synced state. Then derive gamestate off that.
Which you can then expand on.
Though maybe you were wanting a more complete solution =)...
- : https://www.ably.io
- : https://www.ably.io/documentation/realtime/presence
If anyone has experience with building this kind of thing, I would gladly pay for some consulting.
It has all the parts you would need to get any multiplayer game (from 1vs1 to MMO) working.
I'm working on a client that I will try to make more accessible (just like particubes and roblox are trying to do), but no matter how you turn it you're going to need some basic programming skills:
A few suggestions that may or may not be helpful:
- I realize that this is a big part of your esthetic, but blocky "game fonts" are hard to read. They're fine for games, but for editing code I want a normal monospace font rendered at a normal DPI.
- I feel like there should be a way to apply code changes without a full Publish. It's nice to test a change without resetting the entire world.
- Your docs are off to a good start, but it's really not clear to me how everything comes together. A more in depth example would be more helpful at this point than API docs, I think.
I'll definitely keep an eye on this. Nice work!
Our aim is to be a place where people can play games but also one where anyone can make games. We're in the process of unlocking the first stage for the gameplay side of that by releasing our TypeScript based scripting API soon.
Particubes looks great too and it's cool to see so many companies popping up in this space.