Installera Steam
logga in
|
språk
简体中文 (förenklad kinesiska)
繁體中文 (traditionell kinesiska)
日本語 (japanska)
한국어 (koreanska)
ไทย (thailändska)
Български (bulgariska)
Čeština (tjeckiska)
Dansk (danska)
Deutsch (tyska)
English (engelska)
Español - España (Spanska - Spanien)
Español - Latinoamérica (Spanska - Latinamerika)
Ελληνικά (grekiska)
Français (franska)
Italiano (italienska)
Bahasa Indonesia (indonesiska)
Magyar (ungerska)
Nederlands (nederländska)
Norsk (norska)
Polski (polska)
Português (Portugisiska – Portugal)
Português - Brasil (Portugisiska - Brasilien)
Română (rumänska)
Русский (ryska)
Suomi (finska)
Türkçe (turkiska)
Tiếng Việt (vietnamesiska)
Українська (Ukrainska)
Rapportera problem med översättningen
Diskussionsregler och -riktlinjer
6 
Anmäl detta inlägg
Not in the slightest. The devs said themselves from day 1 that if any existing engine had been able to do the job, they wouldn't have bothered making their own engine. Part of the genesis of Stonehearth was the proof-of-concept for new technology (at least, completely new at the time) that the founders worked into their custom engine right from the start.
And in the end, RIOT games ended up buying the whole Team Radiant studio to get hold of their tech innovations (admittedly, more on the fighting game engine for Rising Thunder than Stonehearth) -- Radiant's DIY work was simply that impressive.
Not that it stopped ill-educated "gaming commentators" from suggesting a switch to Unreal or other "professional" game engines from equally early on. Marketing pitches (aimed at game developers) leaking out into the consumer/gamer market have become basically the death-knell of any kind of respect for craft among devs -- every capital-G Gamer has heard about whatever BS tech demo lit up the last big trade show (e.g. in Unreal's case it was Nanite), and is fully confident that it's the tech which will make The Perfect Game and any failure to live up to that ideal is simply a skill issue on the development team's part.
Given the 10+ years of innovations and additions to Unreal since the Stonehearth devs first began work, and the fact that Stonehearth exists already as a point to aim for, it would probably be possible to make a passable imitation of Stonehearth as a fresh project in unreal. On the surface, it could look the same and sound the same and feel at least familiar. Underneath, it would be nothing like the original Stonehearth and would need to have a lot of limitations that the original doesn't; since the whole point of the original was to not be restricted by the limitations of existing engines at the time.
Bruh you might want to go back and watch some of the Desktop Tuesdays and try to understand how immediately (and immensely) ignorant that statement shows you to be.
The challenge in creating a game like Stonehearth isn't "simply" simulating a whole lot of agents -- you can do that easily with tech from 20 years ago. The difficulty comes from making those agents reactive and interactive. Stonehearth's hearthlings aren't just "set and forget" monotask workers, the entire time that they're working on a task there's a risk that the task parameters (pathfinding, availability of materials, access to a workbench, etc etc) might change. When one of those parameters does change, the entire task queue needs to be updated -- even with all the tricks being used to simplify tasks (such as hearthlings "claiming" resources and workbenches that they'll need later, not just immediately), there's still potential for things to go awry (e.g. a claimed resource being stolen by goblins, spoiling, etc), and so the game can't assume that any pre-planned tasks will happen according to the plan. It has to refresh and update those tasks at every step. That creates magnitudes more data flow than you imagine -- and worse, the data is not static; even as one task is checking through available resources to claim another task may already be claiming one of those resources. Managing that, and preventing conflicts and race conditions, is a hell of a lot more complicated than just throwing 250k tasks out into a queue.
I've seen the tech demo you're describing, and I can tell you from a glance that none of those tasks involved any communication between agents -- it was simple one-way information flow, with no interdependency of task order. In other words: the demo picked 250k jobs to assign to 250k agents, and never looked at the task list again. That doesn't work for an actual game.
Unreal is a game engine built for high-graphics first -- it's very good at crunching lots of pretty polygons; everything added more recently with the aim of improving its compute power is bolted on. It's not an engine built from the ground up with the express goal of accurately simulating a lot of agents in a complex dynamic world -- at the end of the day, Unreal was still originally built to support fancy looking corridor shooter games. That's always going to be its DNA. Bolt on as many systems and addons as you like; it doesn't change the fact that Unreal works in a fundamentally different way to how Stonehearth's engine does.
They usually about the "new" ECS that unlocks these potentials. Well... Better late than never i guess. One of the (many) reasons radiant did their own engine was because they created it using ECS, like 10 years before Unity and Unreal implemented it.
It is one of the reasons why it is easy to mod it too.
That all said, game jams have prototypes in like a weekend. With your skills, and this friend which seemed to be even more skilled, a quick prototype would not be a hard task, probably a few days only. Until there, not much point in arguing about it.
I dislike the idea of tying this particular project to Unreal (or any other proprietary engine) because of the serious dependencies that imposes on the project. Stonehearth ultimately died because of a large commercial entity snatching it away from us players. I think it would be a mistake to risk that again by getting in bed with another large commercial entity, and my preference would be for an open source community-driven project that anyone can build on and fork to their heart's content without getting mixed up in any sketchy licenses.
Ah, but it was never about the techniques alone -- yes, the techniques could be replicated more easily with modern technology. In exactly the same way that a digital artist can easily replicate the Mona Lisa these days.
So why do none of those re-creations hang in the Louvre?
It's because the technique is only part of the story. Having access to the technique or tool doesn't mean knowing how to use it effectively, or being able to even understand how it really works. That's why simply saying "oh, ECS or U5 or [insert magical wonder-tech here] is so much better now, that would make Stonehearth better!" so obviously misses the point -- engine limitations were only ever part of the story. The challenges that Stonehearth overcame ranged from some purely technical ones at one extreme of the scale, to some purely player-facing/UX challenges that frankly could have been solved with MS Paint and Notepad.
Plenty of the challenges fell in the middle though, where it was part technical limitation and partly a player-facing concern. A perfect example: enemy camps vs town walls, and how that wastes game memory because there are all these camps of enemies that can't get into your town. That issue isn't really a technical issue, the devs figured out early on exactly what was happening and why... the problem becomes: how do you solve that and deal with the enemies building up without making the game un-fun? The enemies could break down walls, but that ruins the fun for people who like building big pretty walls. The enemies could just leave soon after finding there's no path... but then all you need to do to trivialise enemies is dig a 2-block-deep moat around your town and call it a day. The devs tried both approaches and neither was satisfying; which is why they went with the visitors system instead -- that's an incentive to keep your town accessible. Saying "just use [insert latest and greatest game engine here] to allow more enemies at once" misses the point -- you still end up with the exact same breaking point, it just happens at let's say 30 camps instead of 10 now.
Nobody is saying that Tom or Tony or any of the other Radiant devs (remember that in the end the team got kinda big) are some kinds of wizards; all they had to work with was the deep understanding of their own tools which they built themselves. But that's kinda the point -- because they made some of those tools themselves, they knew things about the creative process that can't be recreated except through a hell of a lot of trial and error.
If you manage to produce a Stonehearth 2, that can deal with large populations...then you would be my hero!
@YetiChow
"enemy camps vs town walls, and how that wastes game memory because there are all these camps of enemies that can't get into your town."
Make them build a ladder or rope at the wall/into a trench and slowly climb.
Make them swim, if there is a moat with water.
All of this is already in the game.
I always told myself that someday if I had the money this would be a game I would invest in to be remade. Maybe someday that will still be a possibility.
Now you have to calculate the pathfind plus this new algo for walls and water. You just exponentially increased the lag. They will need to calculate a path, and when failed, recalculate it but now considering climbing a wall (and then going down later), ok where the ladder go? You can't just say something like the first wall they meet, cause there is no such thing, the whole path is a single thing. You can't guarantee that the ladder up (then another down) will even lead to a path being completed, so you have to recursively check this all again other times, for other places too
You really want to tell me these codes can´t be used for an attacker?
Items can be interacted at adjacent blocks, so there is a 1 block radius around them. If not on the ground (not even this reachable 1 extra block region), the item itself will automatically request a ladder right next to it, going down until it reaches a block, probably ground. The same for roofs. Walls will simple check the current highest block and order scaffold at that same height.
Imagine you are pathing around the terrain, the pathfinder find a wall as its next step. Do you just mark it as a ladder spot and continue searching above, or do you try to go around? Ok, you decide for the ladder, and after doing a bunch of calculations, it results in a failed path. Now what? do you try the same thing but moving the ladder one block to the side? If it fails again, will you keep testing every next block until something is valid?
Now you have way more stuff to check and combinations, you get way more lag.
This.
To put it a shorter and more simplistic way for those who think it's as simple as re-using code from hearthlings: that just results in goblins building ladders all over the place, without any "smart planning", until literally the whole map is connected again. Then you get swarmed by everything all at once, and the wall becomes worse than useless -- it's now a liability that just causes everything to stack up into one mega-wave, assuming your game hasn't crashed under the pathfinding costs first.
the Team Radiant devs already came up with a better solution -- "locking out" sectors that the game recognised had no path through them so that the game wouldn't waste time looking for paths in them. Unfortunately, because the player is able to create paths at any time, locked-out sectors can't stay locked forever -- any time a player interacts with something in that sector, the sector has to be unlocked and checked again the next time a path is required. Of course, if the locked out sector is inside the wall (or any area that's accessible from the town but not the outside), and the player is constantly interacting with it (building, planting/chopping trees, mining) then it's just going to keep checking, failing to find a path, re-locking and unlocking again the next time a change happens to the terrain.
When you understand the systems that underly the "town land claiming" and the map chunks, it's very easy to use them to lock out sections of the map "for later", or to make large no-man's-land areas to force enemy camps to spawn in areas you want them to. It's also very easy to create limited access points that give you plenty of opportunity to deal with enemies without blocking access to the town.
Unfortunately, most players won't explore this -- it's so much easier to just wall the town off and trivialise the attackers. Which is why this "performance problem" really boils down to a game design problem -- you need to encourage the player to keep their town accessible, and then the performance issue largely just goes away instead. There will always be some mountains/rocky areas that cause issues, but as long as the player doesn't interact with those areas frequently, the game will quickly mark them as inaccessible and stop spawning camps there.
Hence the previous comment about "having access to newer and better tools doesn't necessarily mean knowing how to use them effectively." Building Stonehearth 2 is not simply a matter of throwing more processing power at Stonehearth 1 -- if that would have worked, the original devs would have done so already. They knew about this tech as it was being developed, and a couple of times they even addressed how/why a new tech being announced at the time was exciting but they couldn't just bolt it into Stonehearth.
The problems of a required object or ingredient not being available by the time a character gets there is a gameplay challenge, not a programming challenge. The player should manage and defend their resources better so the character doesn't end up arriving at a stockpile and scratching their head wondering where that thing has gone. Characters should probably reserve things so they aren't all trying to grab the same block at the same time, but that should be the extent of it. If the game plays out in a way that involves some lost time from characters getting confused, that's okay, balance the game around that.