This company focused all it's effort in reinventing the part of multi-player games that did not need reinventing.
40 engineers for 5 years. I'm guessing at least 20 million dollars spent. 1 million trailer views... Let's say 100k wishlists, 10,000 sales at 30 LTV. 300k in revenue
This company will need to pivot if the game is not successful.
I would say the db could be pivoted for multi-player Figma style apps rather than games, but the coupling of server and db means you can't scale the db layer the same way you could do with literally every other db solution available s your company scales
A server DB monolith that explicitly doesn't scale?
You put some of your game logic on the server and some on the client with no clear dividing line?
When PoE2 uses PostGres and Eve Online uses SQLServer?
Also doesn't tackle the main challenges of online multi-player games (physics sim rollback)?
I'm sorry but there might not be a good market for this.
It scales much the same way that Erlang/BEAM scales. Each database is an actor in a distributed actor system. That's how we operate BitCraft, however we haven't released inter-module communication (IMC) to the wider world yet.
Isn't this kind of like simply putting the data structures from the first Unreal Engine (which I believe used BSP), into the latest one? For the game you appear to be building, this appears to be rather unnecessary, even for authoring purposes. Even the Nintendo Switch 1, which is being phased out, might not necessarily benefit enough performance-wise to overhaul these core systems.
It's not a BSP, it's volumetric data (this is in the actual article). Just off the bat I get aerial navigation "for free" without having to hand-place regions, and a secondary collision-query for bullet-hell that's much faster than Chaos, which was a huge perf regression in UE5 from PhysX (which already wasn't great).
Additionally, there's productivity + rapid iteratoin. Trying to build interiors with Unreal's built in drag-out-an-actor-at-time interface is too laborious, and the built-in automations (Construction Scripts, Blutilities, PCG) are impedance-mismatched for constructing interiors quickly.
I don't think I quite understood what you are trying to accomplish that is distinct from what 90s BSP engines like Unreal 1, Quake 2, and Source were doing?
Are you trying to do convex spatial partitions for 3d pathfinding in the air?
I did an indie VR starfighter game Rogue Stargun (https://roguestargun.com) and quite honestly intermittent navigation raycasts from the enemy ship AI is sufficient for this sort of stuff.
The bullets all run on the main thread on mobile hardware and so does all the AI. It's not optimized and I have yet to witness CPU bottlenecks being the main cause of frame drops.
Your game looks simple enough and is on the PC platform... I suspect you may be optimizing for the wrong thing.
How is it that you are running into cpu limitations for raycasts in a bullet hell game with UE5 to the extent you built this?
I wrote a VR game that has hundreds of bullets running at 72 fps on Quest 2. Never went multithreaded and never actually encountered FPS drops due to CPU limitations
Can't tell you wo a profile, but I assume your content was as complex as a full byzantine shooter map. I've also got large enemy squads, so there's an M×N issue.
The answer is no. She pushed out the first board, but the second hand-picked board still wasn't having it with these lowball offers. This is a shitshow
> The California-based company has publicly reported that it is in financial distress and stated in securities filings that there is substantial doubt about its ability to continue as a going concern.
Either way, for the company customers under this circumstance I'd absolutely recommend sending all possible means of requesting data deletion, at least there should be a paper trail that such thing was requested.
I wanted to throw out that one of the founders of Traveler's Tales, actually has a Youtube Channel (GameHut) where he goes over a lot of early videogame programming techniques for (mostly) the Sega Genesis and Sega Saturn.
It's quite eye-opening what this guy and his company was able to pull off in the early 90s with an 8 MHz processor, and a limitation of 2 MB cartridge storage capacity, and only be allowed to code in assembly (!)
https://www.youtube.com/watch?v=IhMMK3QLxSM
TT did all this crazy stuff in the 90s with limited hardware, but their biggest success was making licensed LEGO games.
Making games is hard, but getting IP that people _love_ to begin with is harder.
Might I plug my VR game Rogue Stargun (https://roguestargun.com) which totally doesn't have a certain space opera IP, and concordantly does not sell very well?
Serbia has been Russia's closest ally for decades, with Russia having its side in the wars of the 90s. Perhaps such a weapon would have been provided to support the current pro-Moscow government.
The 10x trope was something Steve Jobs really learned from his days at Atari.
If you look at virtually all the games programmed from 1975 to around 1995, the programming "teams" were incredibly small. Until the Sony Playstation came out, virtually every videogame was written in assembly with no source control whatsoever. Even PC games like Starcraft (released in 1998) had code review done by printing out the physical code and going over it with a marker [this was about the last time Elon Musk had a programming job cough). There was no source control and graphics APIs (if they existed at all) came in thick manuals.
For context, the credits to the Sonic the Hedgehog, a multimillion (now billion) dollar franchise, had just one "Chief Programmer" Yuji Naka, and 2 "assistant" programmers. Most of the time the assembly code would be incomprehensible to anyone but the person who wrote it. I believe there was very little actual "collaborative" programming going on. The gulf between a programmer who could merely code (which meant moving sprites around in assembly), and someone who could ship an actual game, let alone a decent one, was quite immense. When it came time to develop the first 3d Sonic game for the Sega Saturn, Yuji Naka was busy, and an American team was set to the task. Working 14-20 hour days, and forced to write a 3d game engine on Saturn hardware in assembly (due to the crappy state of C compilers at the time), this team could not ship an acceptable game in the 1 year timespan needed by the company.
I think quiet advances in tooling have made both collaborative software engineering more feasible and more effective compared to the 80s and 90s, where entire multi-million dollar industries by necessity sat on the shoulders of a handful of high skilled software engineers.
This company focused all it's effort in reinventing the part of multi-player games that did not need reinventing.
40 engineers for 5 years. I'm guessing at least 20 million dollars spent. 1 million trailer views... Let's say 100k wishlists, 10,000 sales at 30 LTV. 300k in revenue
This company will need to pivot if the game is not successful.
I would say the db could be pivoted for multi-player Figma style apps rather than games, but the coupling of server and db means you can't scale the db layer the same way you could do with literally every other db solution available s your company scales
reply