Project roadmap

edited August 2015 in Announcements
There has been a lot of discussion about design for various things: experience gain, other modes than roguelike, progression, AI, etc.
While I appreciate everyone's drive and passion for VQ, I'd ask the community to understand that creating the design is up to the project and not the community.

There is a specific reason for this and it's called "feature creep". Many a project fall prey to that, especially in the indie game development sector, and I will do everything in my power to prevent this. It's basically the death of the project unless you have nearly infinite resources (a thing we definitely don't have). I have been in IT projects for more than a decade and I still see feature creep even with professionals with many years of experience. Sometimes it's pure ignorance, sometimes it's sheer arrogance ("ah, that's easy to implement") and sometimes protocol is just abandoned for no reason at all (other than the fact that a specific individual doesn't likes working "by the book"). That's why I am also here as a producer, to make sure this thing does not happen.

Also, were we to let the community write design documents, a false sense of what is being promised by the project would implicitly be created. The project only promises what it also communicates itself. I hope that makes sense to everybody.

While we will always listen to the community concerning the design, what goes into the design and what doesn't is a project decision. We are currently working on a project framework/roadmap, since the community has had a lot to say in the last two or three weeks. We understand what the people generally want and will try to deliver the more desired features first. We value the opinion of everybody in the community, but you also have to understand that we have our own opinion. It might be that the feature you're looking for isn't making it in anytime soon, but keep in mind that it is basically one guy coding all of this, so naturally not everything that you specifically dream about can be created. So please don't think any less of VQ for that but instead let us know that you really would like to see feature X and if we can somehow make it happen. Who knows, maybe we like your idea and might consider it. :)

Without going into detail at this point, I can at least tell you that the standard RPG mode is going into the first release, since there seems to be a high demand from the community regarding this mode. The roguelike and sandbox (god-) mode are taking a backseat for now. Once we have a revised design document, we will publish it accordingly.

Thank you all for your valuable input so far, and thanks for understanding my point.

Edit 30th August 2015: We have now (actually since a few weeks) a proper high level feature list that Gavan is implementing. Work on the engine is done for now, but of course there will be a performance pass later in the year/beginning next year, when the major features of the game are all in place.
We are aiming at a smaller game for now. Kickstarter backers are entitled to a free copy, depending on their thier maybe even more than one copy. This smaller game is having a lot of the features that we also need/reuse for Voxel Quest, as advertised in the Kickstarter. The reason for this is, that implementing the full RPG game right now would take around another 1-2 years, from where we stand now. We discussed involving the players early, but came to the conclusion, that it will do more harm than good. Early Access is a difficult topic and there are many ways to do it "wrong". We try to avoid negative feelings towards our project as much as possible; we are, however, aware that long waiting times are also a source of negative perception. For the meantime, this alternate game will hopefully bring some entertainment and joy to you, while you wait for the big game.
I'm not saying that this project would have been impossible without the KS backers, but you made it quite a bit easier on us with the money that was made available. So again, my sincere thanks to all the backers out there, and thank you for sticking with us, even if our projections for early access were waaaaay off last year.
«1

Comments

  • From the "Overall Feel Of The Game" thread:
    Clement said:

    I got the 'overall feel' (taking the thread tittle) that VQ has evolved a lot with community feedback but the data is spread on a lot of threads, on different forums (LT), on KS comments, twitter, etc.
    The information may be fresh in some minds (hopefully Gavan's mind at least) but I feel after few days/months, it'll be a mess to find what was said. Maybe it is time to start a design doc v2 ? (And try to address @Flatfingers‌ N°3 concern )

    Perhaps it would be useful for some members of the community to put together their own document, not necessarily a design document, but just an unofficial document containing the main ideas that have been thrown around so far. It doesn't even necessarily have to be shared with the entire community (that way there would be no confusion about actual promised features), it could just be a place for major members of the community to organize their thoughts so that @Pain‌ and @gavanw‌ can have a more orderly source to reference/pull from when looking for potential additions to their own design doc.

    I'm going to link this thread in response to the above quote, as well.
  • @mmnumbp‌, that is an excellent suggestion. Our community managers @PreacherJayne‌ and @Talvieno‌ can maybe help organizing this? They also have a far better overview of all the current discussions than me.
  • Just to be clear on my quoted comment. I meant: it is time for Gavan to start a design doc v2.
    However this can be quite hard to sum up everything, so I second @mmnumbp (although I'm not sure I'll have the time to help much :/ )
  • Ah well, if it's part of the job, I'm entirely up for helping write a community idea doc. Many of the discussions are debates rather than anything concrete, however - that could be a little interesting to pick through. All the same, yes, it would be useful to go through everything and pick out the key points for a bulleted list, so that Gavan and Pain can go through it more easily.

    I completely agree with feature creep. It's a dangerous thing, and should be avoided at all costs - I think Gavan has a fairly good idea of where he's taking the game already, at least, so that's a very good thing. Well said, Pain! :)
  • @Clement‌, sorry, I didn't meant to imply any drawn conclusions from your comment, I only meant to bring in relevant discussion
  • @mmnumbp‌ No problem, I was just making my comment clearer. You did nothing to be sorry of ;)
  • edited November 2014
    "I can at least tell you that the standard RPG mode is going into the first release"

    I'm not going to lie, I was reading this and waiting to read "rouge like will be first" (being that it's probably the simplest one to make)

    I am so happy you guys are taking the difficult road first. Thank you.
  • @Pain I'd be happy to help get started on that, though I think having a document that's editable by everyone might get a little hectic...I could summarize the major points of what has been mentioned on the forums, and @Talvieno and I could keep some sort of running list of community suggestions and preferences.
    mmnumbp said:

    ...it could just be a place for major members of the community to organize their thoughts so that @Pain‌ and @gavanw‌ can have a more orderly source to reference/pull from when looking for potential additions to their own design doc.

    I'm a little averse to limiting the community doc to "major members of the community" -- I'm of the mind that either everyone should be able to contribute, or the design doc should be simply a summary of the community input (though if someone would like something specific added to the doc, I'd be more than happy to add it).
    mmnumbp said:

    It doesn't even necessarily have to be shared with the entire community (that way there would be no confusion about actual promised features)

    Maybe this would be a good thing to put on the wiki? That way it's readable to everyone, and we'll make it clear that the opinions expressed in the document are just that -- community opinions. While Gavan and Pain may be take them into consideration, there's no guarantee that even a popular feature will appear in the final product.
  • edited November 2014
    Also, I'd like to add everyone is free to toss around ideas - we definitely don't want to discourage that. :) Just because I say "yes, xyz is potentially feasible" does not mean it will make it into the engine anytime soon, or even at all. The main priorities are getting a playable, fun game (and as a consequence of that, a working engine). As per community input (and as mentioned by @Pain‌), this will be the standard RPG (non-roguelike) mode first, with other modes to follow if/when time/resources are available to do so. Still, it is necessary to mention all the things that @Pain‌ did, because we don't want to setup false expectations of what will make it into the game.

    Enabling a permadeath option takes zero effort, so I will include that option just for the hell of it (unless there is a problem with doing so that I could not foresee).

    Many sandbox options will be available just because I used them to debug and test, but the sandbox is still taking a backseat.

    All that said, never hurts to hypothesize about ideas, what might work and what might not. I can help all of you determine what is possible in the engine. If if I can't implement feature XYZ, there is a good chance that someone in the community can.

  • gavanw said:

    If if I can't implement feature XYZ, there is a good chance that someone in the community can.

    Re-quoting this for importance. With the source code, anything is possible.

  • Pain said:


    There is a specific reason for this and it's called "feature creep". Many a project fall prey to that, especially in the indie game development sector, and I will do everything in my power to prevent this. It's basically the death of the project unless you have nearly infinite resources (a thing we definitely don't have).

    That makes sense.

    But given that Gavan is willing to share the source, there will probably eventually be mods available which have many of these features anyway.

  • Warp9 said:

    That makes sense.

    But given that Gavan is willing to share the source, there will probably eventually be mods available which have many of these features anyway.

    That's part of the reason we want to keep a running list of major community suggestions! So people with spare time can make them happen. :)
  • edited December 2014
    Featurecreep is real and it's evil! It killed my older game project. Then again I was working in a shitty editor and ended up recoding the thing to death to the point that I was developing my own game engine in a crummier game engine. Lessons are learned over featurecreep battle losses.

    However I believe there to be a cure to the dreaded monster. You are gaining support and you will get better work done for sure. One can somewhat avoid feature creep if you crowdsource features. A lot of opensource projects end up paying for x or y feature etc. There are ways of achieving high quality even with lots of features.

    Development needs to feel fun, less like work. If you make an app type store that hosts content you can also benefit from indie people using your platform and gain money from a more trafficked site from ads.

    That being said, I think the key is focus on things you can get done especially in a time frame. Worry about splitting things up and adding more modular stuff a bit later if you don't get how to do it at first. Though you can save some time by knowing some design patterns or ways to add modularity in constructing things. For example: http://uint32t.blogspot.com/2014/10/a-walk-through-cool-code-generation.html is a good tutorial on adding modular configs.

    By the way, I'd love it if we could have a few threads for suggestions on tutorials etc. Also a feature request thread might seem a bit overkill at first, but could help at least reason out what you think should be done or not. And a design document shared over googledocs would be super simple and nice to have.
  • Keep in mind that the flip side of feature creep for a game is being able to pull everything into a cohesive whole. Simply outsourcing features makes it less likely to achieve that. With a traditional development team, you have a higher level of collaboration and communication that helps give everyone a unified vision and see what other pieces are looking like.
  • edited December 2014
    Switch33 said:

    By the way, I'd love it if we could have a few threads for suggestions on tutorials etc. Also a feature request thread might seem a bit overkill at first, but could help at least reason out what you think should be done or not. And a design document shared over googledocs would be super simple and nice to have.

    Maybe it's better to wait until the game gets more playable. Not like i dont trust gavan to not give into feature creep, but having a forum filled with brilliant and interesting ideias is tempting for anyone :P
    For example, im planning to spark a discussion about a addon-manager, but gavan already said hes not worried about API or anything, since it adds nothing for now and only adds overhead to his effort.

    There was an google doc with some stuff around, let me see if i can get it in here...
    EDIT: https://docs.google.com/spreadsheets/d/1BPf9SzvzCYVZa5V1KsL6elh5sv8O_bg4WNyTvmhRT_s/edit?usp=sharing
    From: http://voxelquest.vanillaforums.com/discussion/comment/1276/#Comment_1276
  • edited December 2014
    @Ukrany
    An add-on/mod manager has been briefly discussed here.
  • Switch33 said:

    [...]

    However I believe there to be a cure to the dreaded monster. You are gaining support and you will get better work done for sure. One can somewhat avoid feature creep if you crowdsource features. A lot of opensource projects end up paying for x or y feature etc. There are ways of achieving high quality even with lots of features.

    [...]

    While the idea works in theory, there is just the problem, that we don't have that kind of money. The money we currently have is not even enough for Gavan, so why would we spend even more of that (little) money on outside sources?
    Also, while buying code is generally not bad (I've done it in the past for my own coding project), you still need time to implement this "foreign" code and make it work with your environment. Granted, this takes much less time than coding it yourself, but maybe it's not 100% what you were looking for and end up discarding it anyways; basically you then lost money and time at that point.
  • Pain said:

    Also, while buying code is generally not bad (I've done it in the past for my own coding project), you still need time to implement this "foreign" code and make it work with your environment.

    I've found that this works really well for smaller features when both parties are already developing for the same platform. I do side work as an Android developer, and we use the Unity3D engine because we have some character models that we'd like to be able to animate nicely. Problem is, Unity3D doesn't always play nicely with native Android functions. I'd spent a number of hours trying to figure out how to implement "toast" notifications, those little bars of text that appear and then fade out after a little while. It was a pain to do, and I ended up spending 5-10 hours trying to figure out the best option. I couldn't figure it out, so I checked the Unity Asset Store and found what I needed. I bought it and had it set up in 5 minutes. Best $2 I ever spent!

    It was convenient for me to buy code because it was by nature modular and I didn't need to know how it works, just how to use it. It also helped because my code and the code I bought were each built for the same framework, Unity. Since Gavan is building his own engine, it's not likely that it'll be that easy to integrate code. And the VQ engine is fairly new (a couple of years old or so, isn't it?), so it's important that it's flexible and easily modifiable so Gavan can form it to his vision by release. Modifying someone else's code can be hard to do because if often takes a lot of time. Also, I can't image that Gavan has the need for the same type of asset one would find in something like Unity's Asset Store, because he's looking more for full-fledged features than simple integration hacks like I needed.
  • There are cases where modular code works well and cases where it does not.

    Sometimes I find equations that I can just plug in and they work (example: calculating screen space transformation for isometric coordinates), and it saves me the trouble of working it out on paper. Or another great example of a time saver was Markus Schutz's point shader - it was only 2 lines of code that I needed, but it could have taken me a while to figure out had he not pointed me towards it.

    I suspect many improvements like that can be implemented by the community - minor tweaks to performance, visuals, and so forth can usually be done without impacting other stuff.

    On the other hand, outsourcing something big and complex like the AI would turn into a hot mess really fast. :)
  • @Ukrany
    An add-on/mod manager has been briefly discussed here.

    Ive read it already but thx :)
    to be honest its too early to think of API. Like i said, a playable game is a higher priority than a easy-to-use API(i hate feature creep too).
    gavanw said:

    There are cases where modular code works well and cases where it does not.

    Sometimes I find equations that I can just plug in and they work (example: calculating screen space transformation for isometric coordinates), and it saves me the trouble of working it out on paper. Or another great example of a time saver was Markus Schutz's point shader - it was only 2 lines of code that I needed, but it could have taken me a while to figure out had he not pointed me towards it.

    I suspect many improvements like that can be implemented by the community - minor tweaks to performance, visuals, and so forth can usually be done without impacting other stuff.

    On the other hand, outsourcing something big and complex like the AI would turn into a hot mess really fast. :)

    Maybe its because im used to Java,etc but i find that with a well defined interface things usually work. Of course we should behave ourselfs(dealloc your stuff guys), but can we afford to spend time defining interfaces and stuff?
    Still lets not forget tht once source code is avaiable (or maybe even before) well you help get those pesky bug and optimize everything
  • @Ukrany - yeah, I'm more focused on getting a game out than anything, but it is always in the back of my head that this is going public soon. That said, everything is still changing so much it is wasted effort to attempt to modularize every little thing at this point, although I am trying to keep everything as clean as possible.
  • I'm quite relieved to see this thread. A well-performed project that sticks to its original goals is always better than an incomplete blob project.

    Except Dwarf Fortress, but hey.
  • I definitely agree with what's been said here -- I'm super excited about the modding potential of VQ, but I'd much, much rather see a well-made game first before things get moved around just to accommodate mods.
  • @PTTG‌ : Dwarf Fortress should never count. It is quite unique in its project setup, compared to the rest of the indies. ;)
  • edited December 2014
    Toady survives on donations alone - that's unique in itself. It also allows him to make the game however he chooses, without having to hold himself accountable to any of his fans. Saves him a lot of PR problems for sure. :P Not very viable monetarily, though.
  • Sorry to bump this topic but have you guys considered Trello for managing your roadmap?

    https://trello.com/
  • HeadClot said:

    Sorry to bump this topic but have you guys considered Trello for managing your roadmap?

    https://trello.com/

    Yes, in fact we have been using Trello since the project first started. :)
  • @gavanw - Any chance of making that trello public?

    Just curious. :)

  • edited August 2015
    HeadClot said:

    @gavanw - Any chance of making that trello public?

    Just curious. :)

    I wouldn't think so, no - largely because of how vague it is, and how often it changes. It wouldn't do for people to get excited when they mistake a long-term goal for an imminent one, or upset about something that wasn't clearly explained. :) We mostly just use it for Gavan's notes. He's the only one actually coding, after all.
  • Talvieno said:

    HeadClot said:

    @gavanw - Any chance of making that trello public?

    Just curious. :)

    I wouldn't think so, no - largely because of how vague it is, and how often it changes. It wouldn't do for people to get excited when they mistake a long-term goal for an imminent one, or upset about something that wasn't clearly explained. :) We mostly just use it for Gavan's notes. He's the only one actually coding, after all.

    Alright understandable :)
Sign In or Register to comment.