Share this project


Share this project

Haunts: The Manse Macabre is a turn-based, horror game where you can play as the haunts or the intruders. PC/Mac/Linux and Ipad plans.
1,214 backers pledged $28,739 to help bring this project to life.

Not Dead Yet - A Programmer Explains Our Technical Troubles

Posted by Rick Dakan (Creator)

I’ve owed you all an update for a while, but frustratingly there hasn’t been much news to report. We got off to a roaring good start with community involvement in the open source Haunts effort, but we pretty quickly ran into a software roadblock that stymied all our efforts. Resolving has proved quite a challenge. Almost as challenging was actually understanding why we were having so much trouble. As a non-programmer, I could grasp the issue in theory but I didn’t think I could explain it well. So, I asked Michael, who’s an old friend and project backer who has been working on Haunts a lot, to explain it: 

 “Haunts is written in Go, a new and quickly evolving programming language developed at Google to address certain programming challenges that are important to the kind of work they do. There is nothing special in Go that makes it particularly well suited to video games, but on the other hand there is nothing inherent in the language that makes it a bad choice, except for the fact that it's new and not well supported. Anyway, one of the neat features of Go is that it is designed to take advantage of distributed code development and reuse of code developed by other people. It's a slightly hacky feature, IMO, but it works. 

Basically, there is no master "script" that tells the compiler how all the bits of code relate to each other. Instead, that information is embedded directly in the files themselves. So rather than, for example, specifying a folder that contains your "headers", you actually embed in your program an absolute path to github, google, or some other file-sharing repository, and the Go compiler will find the code and build it into your program. If you want to use OpenGL for rendering graphics, you can search the internet for someone who has already built a version of OpenGL for Go, and put import ("") directly into your code. Viola! Thus hilarity ensues. 

Because of course that's not how it really works. Instead, it makes a local copy of that external library. And if you have a local copy, you can edit it. And meanwhile, that person you copied the OpenGL code from? They are also changing their version (fixing bugs, adding features, adding bugs). Therefore there is no guarantee that your version and their version remain compatible: it takes work to maintain compatibility. So when you decide to share development of your project with other people, while "in theory" Go lets you just share the main code, which tells you where to get the imported code, in practice it takes more work than that, because we have to ensure we get the same versions. And that's where Go's feature is kinda hacky. Because it doesn't have a mechanism for doing that. 

Why does this matter? Well, when the original programmer on Haunts handed off the code to the community for development, the first problem we ran into is that the code seemed to be.... wrong. We know that there is "working" version of the game, albeit buggy and incomplete. However, we can't use the source code that we have to recreate that game. Firstly, the source simply doesn't compile. It has syntax errors, so there is literally no output- nothing to "run". But the community jumped right in, fixed the problems, and got the game to compile. Now it "runs", but it's not really a game at this point. First, it's horribly slow. Second, it crashes as soon as you try to play the actual "game" (as opposed to navigating the startup menus). Now, this is the kind of thing one expects when developing a game (or any program). There is a bug (or several) that can be found and fixed, and get us back to the same point as the "original". But this is the part the community is struggling with: why? We know it once worked. So now we're in a kind of no-mans land of the original programmer not being unable to help during his transition to a new job and a new city, but none of the new volunteers with enough time to jump into the potentially very hairy problem of figuring out what is wrong in a program they didn't write, in a language they probably don't know, and with the problems potentially being in one or more of a dozen "sub-programs" that are developed by yet other people that we have no connection with. 

 Can it be done? Yes. The original programmer has now dug up all the original code his build was using and the community has it. Preliminary inspection reveals potentially significant differences, so we’re hopeful that we can make some real progress in the coming weeks.” 

And that’s where we’re at. Not what we’d hoped, not even close, but not dead yet. Once we get this conundrum finally solved (which we will), then we’ll put out the call again and try and get things rolling forward at a good speed in the new year. Until then, Happy Holidays! Rick


Only backers can post comments. Log In
    1. Luke Meyers on

      Just curious, what is the level of automated testing in the codebase? It seems strange to me that it could get so hopelessly broken in a way that can't be tracked down, unless individual parts of the program aren't being tested well in isolation.

    2. Missing avatar

      PinkPiggy on

      I appreciate the update. Keep up the good work. I wish I could help, but QBasic just won't cut it these days. :-)

    3. Missing avatar

      Alter Ego on

      Thanks for the updater. I'm, like some other posters here, a coder too. And I can just very well understand your problem and frustration with this.

      It took otherprogramming languages a long time to come to that point to properly manage the many versions of external code. Now we've maven for Java, bundler for Ruby and even PHP has composer now. But it took a long them to get them there. Those languages I mentioned haven been there *before* the milenium (albeit some in differnet forms, but still)!

      In retrospect people propably wonder why Go was even choosen. I can imagine that the original developer just had enough of it and wanted to try something new. I guess no one can blame him for that.

    4. Daniel


      I'm surprised this issue didn't strike as a serious issue with google while developing the language.
      society is suffering enough from short-term durations of information in this age, and now we even got a programming language that erodes swiftly by its very nature?


      I cannot for the life of me see why I would ever want to develop in that language in the future. C++, for all it's own issues in some areas, seems heavenly in comparison...

    5. Gary Hendrick on

      Thanks for the update, As a programmer, I have been handed keys to the wrong repo more than a few time and so I can sympathize.
      A Happy Unholydays to the Haunts crew and community

    6. S.D. on

      Thanks for the update, but most of all, thanks for an update that doesn't shy away from the technical details!! As a coder, I admit that the concept of having the support libraries I depend on shift under my feet like quicksand... well, that gives me the willies. Seriously. Programming against a moving target is tricky enough without aspects of the programming language *itself* changing.

      The closest I've seen to situation like this was deploying a data reporting/analysis/image-processing suite written in a language called Perl. Perl is frequently maligned for being symbol-heavy and having dozens of awful-looking, perfectly legal ways of doing almost everything. In this case, it was well-written and maintainable. However, Perl's strength, at the time, was the huge catalog of user-built libraries, providing all sorts of wonderful functionality. It even had an archive network and installer tool for installing dependencies at the time of deployment (i.e., first-time installation and setup on a server box). The problem was that after a year or so beyond "completing" development, many support libraries we relied on had changed, and others had different installation prerequisites, resulting ultimately in a slightly different install each time, and each install being slightly harder to integrate than the last.

      Ultimately, I ended up leaving that company for another opportunity (in retrospect, I imagine they felt a little like Rick, when I did that). In my defense, it was not my architecture, and my efforts to explain impending doom fell on deaf ears. I imagine that at some point, here on Haunts, the issue of portability will come up, and a community push will be required ensure proper functionality on each supported platform. I suppose I could chip in a few weeks of effort around that time, since the concept of having good, interesting games on Linux is so important to me.

      Rick, please do make an effort to share (at least) one boring development update from the trenches with the backers each month. Even if it's only a paragraph or two, and entirely written by the Haunts open-source community. :-)

    7. Stavros Tsiakalos on

      Thanks for the update Rick!
      As a non-programmer I mostly have to respond "Huh?" ;) It is good to hear from you though :)