Decoherence 1: Beyond the Wizardry

Decoherence 1: Beyond the Wizardry

Postby eugeneloza » 16 Dec 2017, 07:23

Well... maybe it's not the right time to make this topic, but anyway, no more secrets. That's what I'm working on since 2012. However, unfortunately: Current Project Status: FAILED due to my inability to make a proper interface for the game. That means I'm trying to revive it, but it's far beyond my reanimation skills and all of my work goes down the drain killing what's left over of my motivation. Approx 20 thousand lines of code, 500+ A4 pages of scenario...

Decoherence is a free and open-source phase-based RPG in the mood of Wizardry 8 in hard sci-fi setting written in Lazarus/FreePascal and Castle Game Engine.

Sources: https://github.com/eugeneloza/decoherence

The catastrophic war is over. The surviving civilizations of the Diadem Galaxy formed a Galactic Commonwealth of Bass (leaders), Asek (scientists) and Kerf (engineers). Other civilizations are Vegetos (chemists), Velox (pilots) and 'almost-self-destructed' Thess (biologists). Anticipation of 'Galaxy Golden Age' is soon shadowed by discovery of a strange phenomenon in a nearby galaxy. An unexplained spherical anomaly appears and engulfs most of the stars. There is a narrow 'cone-like' exception with vertex at a star named Victoria which obviously "stopped" the collapse. Despite the anomaly being very far away and even at present faster-than-light speed it would reach the Galaxy only in 1500 years, several precautions and scientific projects have been started by the Commonwealth in case the collapse reaches the Galaxy or anything similar appears in the proximity. One of the most 'intriguing' project was the first exogalactic expedition - because there is strong belief that the collapse was stopped by intelligent life. The expedition arrives to Victoria in about 700 years when the galaxy is completely diminished excluding several hundreds stars in 'the cone'. The flight was surprisingly successful but upon entering the star system the starship is unexpectedly caught into a non-gravitational field and is dragged to the nearby gas giant. The crew ejects via landing module which crash-lands at one of the moons. Only up to 6 of 21 crew members survive.
And the adventure begins :) Failure is not an option.

# Features

* Complex and versatile phased combat
* Party of up to 6-8 members each with his feats and traits
* Unique old-school style RPG mechanics
* Dynamic battles with deep strategy to think over
* Random-generated customizable world
* Non-linear plot with unexpected turns and many choices to make
* Hard sci-fi setting
* Many secrets and easter eggs

And when Science meets Magic...

Image
Image
Image
Image
Image
User avatar
eugeneloza
 
Posts: 500
Joined: 22 Aug 2014, 12:15
Location: Ukraine

Re: Decoherence 1: Beyond the Wizardry

Postby Julius » 16 Dec 2017, 08:36

With "interface" you mean GUI?
Maybe a radical departure from the arguably ageing Wizardry8 design concept could be a solution?
User avatar
Julius
Community Moderator
 
Posts: 3297
Joined: 06 Dec 2009, 14:02

Re: Decoherence 1: Beyond the Wizardry

Postby eugeneloza » 16 Dec 2017, 08:50

Yes, I mean GUI. And yes, this game has almost nothing to do with Wizardry 8 (even the setting is different - fantasy versus sci-fi) - it's mostly about the "feel". And yes, Wizardry 8 GUI was ugly :)
The problem is in game mechanics (combat first of all) is extremely complex to provide for a very wide range of available options and choices, still preserving everything simple and eye-candy. The last part requires a very intuitive GUI to provide one-two-three clicks to select any action, otherwise user will surely get lost in hundreds of actions, preks, multiperks, chapters and states. However, It's the 4th (or maybe 5th?) time I'm rewriting GUI again and again and it doesn't scale correctly (with all due animations and anchoring/parenting). The system appeared just too complex for my current skill... :(
User avatar
eugeneloza
 
Posts: 500
Joined: 22 Aug 2014, 12:15
Location: Ukraine

Re: Decoherence 1: Beyond the Wizardry

Postby Julius » 16 Dec 2017, 09:20

I am pokeing in the dark as I have never played Wizardry8, but "phase based RPG combat" seems a bit like various concepts explored by Japanese console RPGs... maybe worth doing some research on that to get a new perspective and take some time off the game? Looking into ways of making a PC interface controller compatible (as much as this is despised in certain circles) can also give new insights into interface design.
User avatar
Julius
Community Moderator
 
Posts: 3297
Joined: 06 Dec 2009, 14:02

Re: Decoherence 1: Beyond the Wizardry

Postby eugeneloza » 16 Dec 2017, 09:36

While there are several "implementations" of phased combats, the only games where it was truly "phased" are Wizardry series and Thunderscape: World of Aden. It goes down to more of semi-real-time strategy games than RPGs here :)
Yes, I'm thinking of implementing a controller support in the game, but it's not a priority task. Practically the whole "disaster" started when I tried to implement Android(i.e. touch)-friendly GUI :) However, I'm not sure if I could avoid it otherwise.
User avatar
eugeneloza
 
Posts: 500
Joined: 22 Aug 2014, 12:15
Location: Ukraine

Re: Decoherence 1: Beyond the Wizardry

Postby farrer » 16 Dec 2017, 10:40

eugeneloza {l Wrote}:Yes, I mean GUI. And yes, this game has almost nothing to do with Wizardry 8 (even the setting is different - fantasy versus sci-fi) - it's mostly about the "feel". And yes, Wizardry 8 GUI was ugly :)
The problem is in game mechanics (combat first of all) is extremely complex to provide for a very wide range of available options and choices, still preserving everything simple and eye-candy. The last part requires a very intuitive GUI to provide one-two-three clicks to select any action, otherwise user will surely get lost in hundreds of actions, preks, multiperks, chapters and states.


From the screenshots reminds me a lot Might and Magic VII, but the combat from that game was rather simplistic as far as I remember (just had melee/ranged weapons and spells)...

For access on a lot of skills/perks-like hierarchy the better interface I can remember was the radial menu from Neverwinter Nights (see: https://www.youtube.com/watch?v=uFevVjeawaY), although it is not very suited for real-time combat (ironically, NWN had only real time combat) . Maybe something like that could be a solution to your GUI interface: a radial menu for access of any skill/perk, and a 'quick-slot' assign bar, for user quick assign common used skills/perks.

I would suggest to either try to implement something like that or try to simplify your game mechanics to a bare minimum (if that does not destroy the felling you desire for the game).

(I'll try to test the game when I have some time to setup a pascal build environment here)
User avatar
farrer
 
Posts: 110
Joined: 24 Feb 2014, 21:00

Re: Decoherence 1: Beyond the Wizardry

Postby eugeneloza » 16 Dec 2017, 11:34

farrer {l Wrote}:For access on a lot of skills/perks-like hierarchy the better interface I can remember was the radial menu from Neverwinter Nights

Yes, practically the same thing, but not radial, rather in a strip, like this https://decoherencestudio.files.wordpre ... esign2.jpg As the combat is not realtime (actually it is, but the regular pauses provide player with opportunity to think over given orders).
The idea is that there are favourites (player can assign several often-used actions to favourites).
chapters (usually those are melee/ranged (regular combat), science (use of science (physics, chemistry and biology/medicine) or magic stuff), modifiers (like actively resist acid damage), items (use item during the battle), special (like self-maintennance for thess character))
Each chapter contains actions (which can be passive or active, character can preform only one active action, but multiple passive, e.g. he can call a magic sword and keep it with his magical powers, or he can try to actively resist fire damage, which will slow him down, but will increase fire resistance; effects currently affecting the character (like poison or regeneration) are also "passive")
Each action has "modifiers" that increase action efficiency. E.g. player can just decide to do a sword slash, but he can also decide to use piercing slash (that deals less damage, but has a higher armor piercing), combo slash (a series of attacks that hits all enemies near the character), accurate slash (that will never miss, thou will take some time to aim), etc.)
So, the player has a very wide choice of actions, each being just 3 clicks away - select chapter, select action, add modifiers (if required). If needed, enhance it with global modifiers.
Some items may get more modifiers or even actions by upgrading.
The choice will usually go down to "do more damage" (which will wear out the character quickly) or "save strength" (if the battle looks like a long run). Or, maybe, burst forward and take out unarmored targets, and then concentrate on defense and recover.
Unless all these options are very intuitive, properly animated and easy to use, the player will have a hard time understanding "what has changed, what is selected, and what isn't selected, etc..."

So, practically, all I need is just to scale elements against anchors and animate them between changing of the state. Sounds easy enough, but not working :)
There is GUI, in GUI there is PartySpace, in PartySpace there are CharacterSpaces, in CharacterSpace there are "healthbars", "portraits", "action-space", "status-space", etc. aligned against parent container and each other. This alignment isn't working as it should, because I can't make a proper notification pipeline (if one element has changed its state, it should notify all anchored elements, including in situation when some of them have already been freed). All this considering different possible screen resolution, very different interface "States" possible... all should go bug-free and smoothly.

I would suggest to either try to implement something like that or try to simplify your game mechanics to a bare minimum (if that does not destroy the felling you desire for the game).

I've thought about that. But the problem is, after simplification there will be no going back as mechanics will be "woven into" the whole game, and this is another problem yet to consider - how to implement all those things properly :)
Rather, the problem is, that I've proven myself incapable of designing such complex systems. That said, even if I'll be capable of beating down this GUI problem, there is absolutely zero guarantee no other like that (e.g. enemy movements, passive perks processing, overworld generation, music management) will pop up in a month or two.

(I'll try to test the game when I have some time to setup a pascal build environment here)
Unfortunately there's not much to test here at the moment. Just a random generated map (by Mazer algorithm https://forum.freegamedev.net/viewtopic.php?f=22&t=6517 , however, highly advanced) with no interface and only enemies still trying to attack the player on sight.
User avatar
eugeneloza
 
Posts: 500
Joined: 22 Aug 2014, 12:15
Location: Ukraine

Re: Decoherence 1: Beyond the Wizardry

Postby farrer » 19 Dec 2017, 11:27

It seems like you're implementing the GUI by yourself too (correct me if I'm wrong). Castle engine have some sort of GUI library on it, not? It could simplify the work or make better the management of elements which seems, from what I've understand from your post (those 'spaces' and 'containers' you've mentioned is a black box to me ;) ) your biggest problem now.

Anyway, don't underrate yourself, someone that is able to create an advanced and decent 3D maze generator is able to resolve both the current GUI problem you have and any other that will appear. Maybe just try a different approach, or set the project at a side for a while and resume it latter (that could do a great impact: sometimes it's good - and very productive - to take a break, work on other projects or other things, before going back to resume a complex project like Decoherence).
User avatar
farrer
 
Posts: 110
Joined: 24 Feb 2014, 21:00

Re: Decoherence 1: Beyond the Wizardry

Postby eugeneloza » 20 Dec 2017, 20:35

Yes, I'm trying to write a "my very own" implementation of GUI. And yes, Castle Game Engine has its own nice GUI. However, the problem is not in "making" or "drawing" GUI, but in automatically arranging it. And here, actually, hardly any third-party solution will help me. The problem is that at this moment it should automatically arrange elements (which can be very different, like text, images, fixed-size images, scaled images, just empty "containers", etc). And eventually I end up with either uninitialized or wrongly-arranged elements.
Hardly I can postpone this issue any longer (yes, I've been postponing it ever and ever again for several years by now :D), as without interface, everything I've done (and will do) is just a set of modules, that don't get together into a game. I made different sorts of breaks, no, it doesn't help :)
The problem is that I found myself unable to handle such complex architectures. I just can't fit it into my head altogether, moreover (and maybe, the worst reason) is that I can't get myself to work for an extended period of time, and after taking "breaks" I simply forget how something was implemented and write further code, which contradicts the previous one.
Therefore, even if I beat the GUI problem and my new (will it be the 5th or 6th?) variant will work without significant bugs, there's just no guarantee that there will be no more such "stops" further. I can already name "pathfinding", "Scenario-World interaction" and "thread-less overworld", with a very high chance I won't be able to implement properly, or they won't work as expected (meaning, breaking the gameplay). Yep, that doesn't make me stop. But makes me very pessimistic about future of the project.
With my recent estimates (that didn't consider such critical failures) the expected time till betta-release was 20 years (to implement basic game features and create/adapt assets). Now it has increased at least twice (and it's very long ago when I was 25). So, not much luck... Unless a miracle happens :)
User avatar
eugeneloza
 
Posts: 500
Joined: 22 Aug 2014, 12:15
Location: Ukraine

Re: Decoherence 1: Beyond the Wizardry

Postby c_xong » 20 Dec 2017, 23:58

Sounds like you need a retained-mode GUI framework with auto-layout functionality. Which is unfortunate because immediate-mode GUIs are all the rage and there are lots of good open source game IMGUI libraries, but none that I know of for RMGUI.

Perhaps someone knows of one, but I would definitely avoid writing one myself. A GUI library is a full-time project on its own, there is no way you can make one at the same time as making a game, in a reasonable time frame.
User avatar
c_xong
 
Posts: 234
Joined: 06 Sep 2013, 04:33

Re: Decoherence 1: Beyond the Wizardry

Postby eugeneloza » 22 Dec 2017, 13:21

Eventually I couldn't sleep yesterday night until I've deleted everything and started rewriting everything from the scratch. This time GUI will be static and screen resolution will be fixed. Very bad idea, but anyway better than giving up the project completely.
Wish me luck :)
User avatar
eugeneloza
 
Posts: 500
Joined: 22 Aug 2014, 12:15
Location: Ukraine

Who is online

Users browsing this forum: No registered users and 1 guest