KarroK

Not only aren't there options other than CC, but my (dutch, mastercard certified) credit card gets declined by fig.. While it works just fine for overseas amazon etc. What up with that.

The credit card I have (dutch bank) gets declined by fig, while it works perfectly fine everywhere else. Dutch debit cards don't have the whole card number cvc etc going for them either. So I can't even pledge right now.

I finally got my order through, just using Chrome, guess patience rewards sometimes ;-)

I tried both Chrome and Firefox, get the red error message on both. Please don't make me install internet exploder :'(

An error occurred processing your order. Please try again later. If the problem persists, please contact us. after pushing [Place Order] button. Turned off adblockplus and notscript, but still can't seem to complete yet

You'd like at least some QA as soon as they have something in a workable state though . The earlier bugs are found the faster and cheaper they can usually be fixed.

Any way to volunteer for a parttime QA under some bitchin NDA for those willing to invest some time into making the game awesome (after just having handed their wallet and 1st born over for the kickstarter) ? I realize there will be an open alpha and beta, but surely testing can be done by a group of volunteers reporting to the QA leads in-house? Both coding and QA seem lightly understaffed, but can be quite determental, but at least QA can be done by semi-qualified volunteers. Let people who are interested send in a resume or something, just so you don't get swarmed with a gazzilion people that just want to try it once.

having a "cheat" console might not be a bad idea though depending on the game. Take for example skyrim, sometimes quests just block, vital NPC's don't spawn etc. The console allows you to reset a quest, spawn the NPC etc. Of course this is just one of uses aside from all the other stuff like making you a god or w/e or spawning items/goods. But players make the conscious choice of using them or not using them. If it adds the option of circumventing game bugs by the player until they are fixed I think a "cheat/test" console is a good plus to have available. Just imagine being stuck on that one main-plot quest in any RPG and not being able to progress due to a bug, that's just annoying.

As long as it has enough space to carry worthwhile items (for us gatherers) tbh. In diablo for example I always hated having to pawn off gear sets because I lacked space. Space is usually one of the first mods to any RPG game to come out, it would suit obsidian to keep the honor to their own and bring us enough bag space at least. references just off the top of my head: diablo2: plugy -> millions of item spaces skyrim: carry mods torchlight 1 & 2 inventory expansion mods

tldr: somewhat broadening the scrum discussion a bit I've been in two different teams (small teams, 4-6 people) working on different aspects of the same product for little over a year now, so I thought I'd share my experience. First off, the initiative to use scrum came from management first, not the developers. But since our previous "method" we used was a little less.. organised we just went with the flow. The first thing we noticed was that it was quite an interruptive process, that was used more as a tool for management instead of a tool for the developers. We went on and loosely implemented our own version of scrum, with as little of the interruptive or time-consuming administrative jobs etc. In the first team we kept a not-too-big scrum board (physical whiteboard) with magnetic reusable "stickers", green for a story, yellow for tasks within that story and red for impediments. Then we divided the board into sections: not-started, in-progress and done. Took some of those round magnets and (since we're all gamers sorta) put our avatar on the magnets and used those magnets to show who is working on what. In the next team, we basically used none of that and simply had a properly sectioned spreadsheet for our main tasks, subtasks and our guestimates for those tasks, none of which are shared with product management and are there merely to give us the insight we want. We keep track of days-left on tasks and keep a history of that. We include our availability and we can guestimate for ourselves if we're going to be short on time or not and take decisions accordingly. A couple of things to keep in mind (as I've found out at least) if you want to go with scrum: - Have the initiative to go and use scrum come from the developers and make sure that your bosses know that it is a developer tool before it is a management tool. - Time estimates (story points) are exactly that, estimates, and certainly NOT a planning of any kind. The estimate accuracy can differ wildly depending on the difficulty of the task and any complications that might come with it. - Smaller teams make for less overhead, shorter daily standups and more time for.. yknow, work - Scrum duration should NOT, I repeat NOT be linked to a release cycle (assuming you're doing way more than 1 release cycle). Have a trunk that is always in a releasable state, have a "merge" trunk for regression testing and multiple feature branches, test the branches, if they pass, merge them to the merge-trunk, have that tested again, and if that is stable, toss it in the trunk. This way it doesn't matter if features don't make the cut for a release because then it will just go into the next one. This is important especially if your sprint duration does not sync up with the release schedule. - Personalize your scrum process, do what feels good to you and the team, keep it as a tool for your group to benefit from and not let it be used as a management-stick to whack you over the head with because they don't see the difference between your estimates and "planning". Doing so will simply lead to team members vastly overestimating tasks. - Scrum works good for work that you can slice up into tiny parts (ie setting up basic architecture, implementing a basic framework etc), where each of the parts is well known by all the team members. This means estimates will be more precise. - Flip side is, for coding into unknown territory (ie advanced stuff that might require re-doing, re-evaluating, tinkering etc) the estimates will be off by quite a margin, this won't improve at all unless you come to a point where those tasks become repetitive. - Storyboards are optional (imo) but can give developers a good insight of what everyone is doing and what the status is. - Scrum can feel incredibly wasteful, so keep daily standups short and to the point, technical or specific discussions that do not involve all group members should stay outside of the standup. Keep the sprint-meetings to the point, before you know it you spend half a day or longer just making some decisions. - Developers are in charge, if a developer tells the product owner that certain technical stories (ie framework expansion or w/e) need to be done before a certain feature can be implemented, then that is the way it is <deal-with-it.jpeg> Above all though, a manager should be able to trust the developer teams enough to work autonomously, check in every once in a while but let developers do what they do best, develop, while rocking out to some tunes and being in the zone.. until some scrum meeting interrupts that flow And of course most important: Scrum is a tool (replace "resources" with "tools") Now I just hope I didn't bore anyone to death, I've too much left to do in this world to get stuck up for murder-by-proxy ;-) I'm also interested in what the industry vets think about scrum and what they do and do not use, please share!