Heads up on 1.0E

Discussion in 'Clockwork Empires General' started by Nicholas, Nov 30, 2016.

  1. Nicholas

    Nicholas Technology Director Staff Member

    Just a quick note: we are doing a fair amount of work on the build machines this week, moving them to a new home; this will delay 1.0E while we get things set up, and consequently patch 1.1 as a result. Just keeping you posted. :)
  2. Naffarin

    Naffarin Bureaucrat-Inspector Exemplar of The Empire

    what is a qu ? :D
    Exile likes this.
  3. Nicholas

    Nicholas Technology Director Staff Member

    Me hitting the enter key out of order.
    Exile likes this.
  4. Not such bad news: maybe I'll finally get intobuilding a Steam Knight? :D:eek::rolleyes:
    Exile likes this.
  5. Tikigod

    Tikigod Member

    PeterH and Exile like this.
  6. Bluebird

    Bluebird Member

    And how is the server move going?
    DrusoMR likes this.
  7. PeterH

    PeterH Member

    Seeing as the version number on the experimental branch is still the same as on November 24 when I decided to take a break from CE, the relocation may have tried to cross the Bermuda Triangle and did not succeed?!?

    Or maybe I should turn experimental branch off and see what happens.

    But I'd like to hear, for one, if there's anything still in the pipeline at all.
    Last edited: Jan 28, 2017
  8. Tikigod

    Tikigod Member

    It's somewhat looking like key personnel involved at Gaslamp parted ways.

    Nicholas has changed his twitter profile to remove mention of working at Gaslamp and replaced it with "I made games once, it was awful."

    Dgbaumgart now has himself listed as a freelance artist and independent developer with no mention of Gaslamp, and has thrown up a few blog posts over on gamedev.net mentioning work on developing his own projects running off of Unity and sneaking in a mention in a 'review of works' that he wasn't for the idea of Clockwork Empires to start with rather wanting to work on a 2D spiritual successor to the Masters of Magic genre of games but being outvoted at the time.

    MooManibe who was an animator on CWE (at some point at least) is also confirmed as independent now and not working on the game.

    So of the 3 listed 'founding Partners' of Gaslamp it would seem Daniel is the only one not clearly showing themselves as no longer associated with Gaslamp. Personally, I wouldn't hold up much hope for much to be in the pipeline for Clockwork Empires, nor for ever really hearing any real word on what exactly happened between the end of November and January.
    Last edited: Jan 28, 2017
    PeterH likes this.
  9. Teutomatos

    Teutomatos Member

    I suspect at least a real Eldritch transformation ... They worked with strange tools artifacts and so, without vacum chamber, no hope ...
    Asid likes this.
  10. PeterH

    PeterH Member

    Thanks for the heads-up, Tikigod. I didn't know that Nicholas has also {apparently} departed, although I was aware
    of Mr. Baumgart's no longer being associated with Gaslamp Games and read in a post here that MooManibe had quit
    or been dropped.

    Yeah, well, it sure looks like GG is a dead duck. {le sigh}

    I am not surprised, in the end, that they threw in the towel. It's funny, really, only the 2nd time ever that I bought an "Early Access" game, and on the strength of Dungeons of Dreadmor. I used to do beta testing back in the day and you'd get some
    small remuneration or some goodies as recognition for doing it ... these days you have to shell out money for "Early Access" to receive the honor. But, really, I can't moan: I got 470 plus hours of entertaining bug hunts out of my investment of $29, that's more fun than many games I've bought in the past. (Buyer's Regret over GalCiv 3? --- YOU BET).
    But, to get back to the first sentence: I tried several times to tell the guys to get the game stable before introducing
    new content or modifying content ... but I guess that's not how they wanted to work. And I would expect that, with that storm of unbridled creativity, they ended up with a byzantine mare's nest of code and it became just too much to keep working on without generating a good income stream. Hence, probably, the way premature release that backfired majorly on them.

    {grins like a sad Cheshire Cat}

    Anyway, I may check in here once in a while. It was nice meeting, and talking to all of you!
    Au revoir.
    Teutomatos likes this.
  11. Mad_Ludvig

    Mad_Ludvig Member

    I think it was pretty obvious this was the case. How many times were the actual recipes wrong from what was displayed in game? Why wasn't the data for the display as well as the actual recipe pulled from the same source?

    Being someone who works in software as well, code quality is very hard to pull back from the brink once it goes south. Although it seems backwards, the only way to go fast is to have really high quality. Due to contractors, prototype systems being used before they were tested, getting behind etc, I imagine things weren't very pretty towards the end.
    Teutomatos likes this.
  12. Tikigod

    Tikigod Member

    I think a large part of this was due to how they decided to structure their data.

    Near everything was referenced through external XML files continuously parsed runtime as external script references rather than from neat and tidy internal code that could be kept... well... neat and tidy. If something was changed whoever made the change was also technically responsible for catching which other external XML files also had to be trawled through and any semi-related references to references to references to references updated accordingly.

    It's a pretty clunky structure to utilise as much as CWE did when you're going for a constant design reiteration approach like Gaslamp adopted. And I can only imagine it really did a number on productivity at times and probably ended up shaping decision making more than it probably had any right too.

    For some things it's handy for player modding to have item recipes and such exposed, but as a key data structure design for almost all aspects of the game it's not exactly ideal for development and often a better solution is to have internal default states for everything and then have external files act as overridable values if flagged as modified... so have all recipes, behaviour references and such internal. Then have a handful of XML files for things like recipes that are a copy of whatever is the internal default data that is produced on first execution (or on first execution after build version change). With the first aspect of the XML being an 'Override defaults with XML?' flag that the game checks on initiation to see if it should stick with vanilla/internal values or parse in the player modified values.

    I've always been curious why Gaslamp opted to have so much of the scripted behaviour and references thrown in as external files fed into the game as whilst it's not uncommon to have external elements, the sheer scope of how much was structured via XML just always came across as hugely inefficient considering the TYPE of game being developed and without any real benefit except perhaps if people with little to no programming language experience were being expected to make game behaviour changes and were involved in shaping how systems act, so XML was deemed the most "Plain text to understand" solution to have non-programmers try to act as programmers.

    But I really hope that wouldn't be the case as that just sounds like a spaghetti design nightmare for anyone with actual programming experience to have to then deal with and have to fix others inexperienced 'solutions'..

    Edit for clarity about external files:

    If Gaslamp had been making something more along the likes of Europa Universalis where for all intents and purposes the game is '2D', split into clear predefined regions with little "movable parts" and most everything is automated calculations of a half dozen variables per nation and presented through UI windows with little to no player input, then having so much driven by external files can work.

    But for a 3D real-time building game, where you've got all those runtime AI calculations going on for pathfinding, Object identification and sanity checking for 'n' possible interactions across multiple independent groups on one map, player freeform building and attempting to have meaningful individual colonist behaviour simulation going on etc... there's just too much going on and needing to be controlled to really structure it via external files in my book.
    Last edited: Feb 4, 2017
    Teutomatos likes this.
  13. Kaidelong

    Kaidelong Member

    Eeeh, I don't buy it. So long as you're okay with long loading times, the XML won't be a problem. You don't have to continually re-parse it while the game is running, just when it starts. Also remember that the interface changed mid-way through development. If they'd done it over, they'd probably just have had the lua call straight into the code and mutate the game objects.

    PS: XML does have its own problems, one of the most insidious being the way it tempts you to do things hierarchically rather than flat. Repeated run time parsing of it should not be one for a game, though.
    Last edited: Feb 4, 2017