To be able to do this we built a system based on a technology called ECS (entity-component-system) and used that for everything in the game. animating your trusted sword and turning it into a companion that follows you through the dungeon… or doing the same with an altar or a dungeon wall) and complex elemental magic and related effects (weapons becoming damaged from hacking at walls, an extensive liquid system in order to have pools of healing liquid or rivers of confusion liquid). attaching a dragon head to your body giving you the ability to bite and breathe fire), animancy (e.g. the individual character, the items carried, the murals on walls, the slippery fluid on the ground, the genetic DNA of your hand) because we want to have crazy features often mentioned in the ramp-up of the game release like grafting (e.g. ![]() Our target is more the micro level of the game (e.g. Our goal is to implement a game engine that can scale up the complexity to insane levels, all in the name of fun. Ultimate ADOM has a very complex data structure because we really try to simulate a highly detailed fantasy environment. And Java has the far better open source ecosystem with far more advanced (and tried and tested) solutions to complex issues. But strangely both languages have areas where the design and engineering behind the languages are miles ahead of the contestant and you really wonder “how can this happen with all these brilliant people working on language design”. My personal opinion is that both languages are fantastic to work with (and these days I even prefer C# to Java although Java has been my big love over more than 20 years ). The dangerous thing we noticed early on is that – while C# and Java look very similar on the surface – the actual ecosystems are vastly different, especially in the design approach to the programming languages and the open source ecosystem surrounding these two worlds. This now is going to get a bit technical but I would like to explain what happened so that everything is clear and in the open: While we have 20+ years of experience doing Java development and the many years of C programming ADOM, the C# and Unity used in Ultimate ADOM brings its own challenges with it. Here's a technical explanation for those of you in the know or with the interest about what went wrong with our initial estimate.ĭata in Ultimate ADOM is insanely complex. In the next few days, we are focusing nearly exclusively to getting Saving and Loading into the game in a way that works for everyone. ![]() Your feedback, both positive and negative, is very valuable to us and very welcome. Ultimate ADOM: Caverns of Chaos is still an Early Access game, and as such there are some core features missing. We have recently published a roadmap where we outline where the next big features such as Hunger and Corruption (in April), better combat options and AI (in June) or enemy spellcasters (in August) will make it into the game. ![]() In short: The solution we thought would work didn't quite, and we feel that the frustration of trying to load a game that would then crash around you would have been much higher than not being able to save and load at all. The first is that we've been overly optimistic about our ability to get Saving and Loading into the game in a way that works instead of most often placing you into a mirror universe of the one you left when saving, where things roughly look the same but don't, and bugs will murder, corrupt and crash you, and not in a good way. It's quite simple: It's entirely our fault. So what happened? Why are we going to EA without such an important feature, knowing full well people usually don't like leaving their computers running for hours? We are working on it and expect to provide ASAP. ![]() If we hadn’t stumbled upon a serious internal bug it would have been part of the EA release.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |