Home
Artists
Search Recent Random
Posts
Search DMs Popular Hash Lookup Tags Random
Importer
Import FAQ
Register
Partychan Telegram ThePornDude
Home Artists Posts Import Register

Lessons Learned (Patreon)

Published:
2016-09-02 15:49:53
Edited:
2017-05-12 05:45:42
Imported:
2020-07

Content







Current Public Build:https://www.patreon.com/posts/public-release-3-6658958

Current Patron Build: https://www.patreon.com/posts/alpha-v1-02-1-6658752

Judge Heath Here, and here I wanted to talk to you guys about some more changes we'll be implementing to how we do things here at Team Nimbus.

This last update, combined with lessons learned from the original update, has lead to us questioning our exact methodology of going about making the game. We now see two possible methods of going forward. One is far more structured, but will result in a slower update schedule (one or two a month). This was our original plan, and what we've been using so far, the new method will just refine it further. The second method will lead to far more releases, but will be far more buggy in each release. This second method will put far more of a burden on you guys as testers, but will lead to more releases and perhaps a greater feeling of investment.

Method 1: Slow and Steady

On the first we continue to work on known bugs, and then on the second, we start adding into the bug list all the other bugs that our patrons turn up. By the 12th we finish off whatever bug fixes we have been able to get too, release the hotfix, and begin working on implementing new features (new scenes, new dialogue, new mechanics, etc). On the 25th, we shut down all of that, and begin internal iterative bug testing. On the 30th or 31st (or 29th if it's february) we release the new build to our patrons and the bug fixed build to the public.

Method 2: Fast and Messy

This method becomes far harder to organize, and we end up being far sloppier in our release schedule. This method will be far, far, far closer to how most indies release. It is a rolling set of bug fixes, new features, and other stuff. We release patron only builds as we can, and then set a regular time to release the latest 'public' build (either every 2 weeks or every month) that is delayed slightly behind everything else. As this method will be a rolling set of changes, where the new features and old bugs will not be fixed separately from one another, public builds will either have to be buggy, or on set dates the build we release will be the most 'current' build we have, released to the public rather than our patrons. This method also carries the risk of us having bug pile ups that get hidden under piles of new features overtime, but in theory it'll better suit our one man programming operation and allow faster iteration.


I'm opening up a vote on which way you guys feel we should go. This vote isn't defining on which way we WILL go, but we really want to know how you guys, both our non-patron fans and our patrons themselves, feel about this.

Comments

CloudMeadow

Which method do you think would work best for us going forward? (This is a nonbinding vote, we're just testing the waters here)

Anonymous

Method 1: Slow and Steady

Anonymous

Considering the amount of work you've managed to in such a short time, I can handle slow and steady.

Anonymous

Method 1 Slow and Steady

Anonymous

Method 1 Slow and steady

Anonymous

Method 1 slow and steady

CloudMeadow

Please remember that votes are handled by clicking the "Like" icon on the vote options in the first post. Simply stating which one you like isn't enough.

SirSaber

Thanks for telling us that.

Anonymous

Method 1 sounds more preferable

Jathby Dredas

Agile is nice when you have the resources, or a strong base to iterate from, but I think it may be overrated and overused. A solid, structured approach is rare for Indy devs, but so is survival. Fuck Darwin, go with Method 1.

CloudMeadow
>>2452369

No problem, I keep forgetting not everyone has seen the original test vote post way back when.

SirSaber

Also if you go slow and steady you guys will be more tranquil no? Less stress I mean. I prefer that you Nimboys keep the updates steady but also that you don't overdo it like you did with the streaming once. It is nice to see you dedicated but don't go killing yourselfs.

WonderLlama2008

I'm in software development myself. Please stick with Method #1.

Kaidasaurus

How about a hybrid system of slow and steady with the odd early patch for new systems to play test?

Anonymous

I would honestly think slow and steady will be a lot better. It would help on concentrating on things already touched up on and honestly: You guys did state that it'll be easier. In my book, that creates less stress in my opinion.

Anonymous

Steady, slow if u want, but steady for sure.

Anonymous

Definitely Slow and Study, I much prefer knowing that the longer updates are going to be polished and capable of working you know?

ILoveThighs

Slow and steady please.

Anonymous

Slow and steady sounds good

Vilis

Maybe Slow and Steady but see if there are a few patrons out there who want to help with testing? Like, I don't have time to test every few days, but there might be 10 or 20 patrons who would LOVE to test each and every build.

Dream Tree

Slow and steady is my vote!

Skullmageddon

I would go with Slow and Steady.

Anonymous

Slow and Steady ofc

Anonymous

Slow and steady, but share the test build that you shut down and start working with on the 25th (well-labeled as a test build so people don't get "prview build" stuck in their heads) for a sub-tier that wants it and doesn't mind helping with bug reports. You'll probably get a lot of data from those dedicated fans who like to help with that stuff, if you don't mind sifting through more reports to get it.

Anonymous

Steady at the helm.

Fiona McGreggor

Go slow. Give us regular, reliable, and consistent developments. I don't want to throw my money into a frantic mess that Breeding Season turned out to be. So much promise, so random, and now failed. Don't be that! Do this one right and you can have all the monies.

Anonymous

Slow and steady.

Anonymous

I'm sure we can withstand waiting... Not like you're gonna turn away from us or anything. *koff koff* We are here. And I say I will wait. *sits on lawn chair*

Anonymous

Slow and steady wins the race. I'd rather wait and have you guys work slower then run the risk of massive amounts of bugs that may interact with each other in interesting ways that kill playablity.

Kadah
>>2452365

On the Patreon app, seeing the first posts is difficult with lots of comments. On the site, it quickly buries them. May want to edit the post to state that as even this comment will soon be buried. In either case, it's often good to make use of free and willing resources when dev resources are limited. Edit: Since posting this a minute ago, there's already several more pages burying everything on the app. lol

Anonymous

Slow and steady, I think. A methodical approach to new features and bug fixes will end up with a better product than fast and messy, for sure.

Anonymous

Slow and steady will better.

Anonymous

Everybody voting! Hit the 'oldest' option at the top right of the comment section to get the comments and vote with your likes!

Anonymous

Slow and steady, quality before quantity.

Anonymous

Method 1: Slow and Steady

Mr.Light 94

Method 1: Slow and Steady

PoshOctavia

this is actually a good question, if you use the players as testers you get the game done faster since thats stuff you don't have to do yourself, but at the same time it makes it look like you are just developing a buggy mess and looks unprofessional. if you go slow and steady it looks better and means your releases are all playable but you risk people losing interest or getting impatient, which considering how the other game went would be really bad.

Anonymous

In my opinion (you don't have to follow it) I'd like for a slower release, I'm perfectly ok for waiting on bugs and everything to be worked out if it means we get a good copy of the release, but on the other hand getting it out faster does mean I get to play it sooner and I'm sure a lot of people would like that. I just see that no matter which way we look at it, someone or a few people are going to be slightly upset no matter which method you take. Ex: Method 1: "what's taking so long?", Method 2: "It won't run, it keeps crashing, theirs a bug with"....etc. BUT I'd say it's more up to the makers of the game to decide how they'd like to do this.

Artakons
>>2453836

Good points. But considering that with the 1st method they would be releasing an updated version every month, I think people would get used to the pace, and the complaints would be minimal. It also helps the team organize their work properly and work on all the reported bugs. With the fast and chaotic method 2, there is a bigger risk of overworking, which causes mistakes and either gives us more bugs, or slows down the art/animation departments in case something needs reworking. I'd say method 1 is safer and definitely better. At least at this stage of the project. Maybe give it a year and then let's consider both methods again ;)

Anonymous

It's best to moderate the time effectively and recognize what has to be done. For example you can two builds each month. One that is fast and messy that will undoubtedly have bugs and another that fixes all or most of the bugs, with a progress update to the patrons of why it has occurred. It might be a rush to fix bugs but even then so long as a little piece is added each time then players will understand. We're not that evil. The best way to do this is show us progress reports several times each month on what you're doing, how long its going to take, why focus on that, what you plan to add in the future, and explain to us if ALL these changes will be in the next build or only some of them. If you think you should wait and focus on fixing bugs then do so after presenting us with a new build. BS did the same thing and its the reason why so many people played it. Just try your best in working on this great game but please, just tell us what going on alright?

Anonymous

In my opinion, I Would prefer method 1 than method too. No reason to rush in the development of the game to be a mess.

Anonymous

Method 1: better to work at your pace than push to hard and goof yourselves up.

Anonymous

Method 1: Slow and Steady

Anonymous

Method 1 for reasons already stated. You guys gatta both pace and respect your own lives and schedules or you'll burn out. We can handle the slower pace for waits and releases :)

Anonymous

Method 1.

JK

"[...]in theory it'll better suit our one man programming operation and allow faster iteration." This, to me, is the key point, so I'm voting against the majority here. SOME structure is good, obviously, but too much has a tendency to just bog things down. With such a small team, method 2 seems much more practical and organic.

Anonymous

I say Method One; anything worth doing is worth doing well, and it's better to do it right the first time than to have to keep going back and fixing things.

Digginit

Definitely method one. Do it right the first time so you dont have to do it thrice over.

Anonymous

Method 1

Dr. Supersocks

method 1, of course. I'd much rather you put out a more refined, stable build with less features than a buggy release with new content that may or may not work.

Tohoko, the LEWD Writer
>>2453288

yeeah... this is full of contradictions here... I don't know how else to say this but... BS was doing the first method, only difference is that there was no actual progression and turned into a stagnating pile of pig poo before the fan got to it. We all know the rest of the story.

Tohoko, the LEWD Writer
>>2452732

it also creates a potential for contempt and complacency, which are both bad to have when developing a game.

Fiona McGreggor

Eloquently stated. However, speaking from experience, it seemed that a lack of structure that put undue amounts of responsibility on a few individuals was a leading cause of BS's randomness and subsequent implosion. Successful development teams for productions of this type have clear methods of progress and troubleshooting. They KNOW what they want to end up with, and the minutia of it is handled systematically. While it's satisfying for us as patrons to be all up in its business, we are ultimately a liability to production if we make demands on everything, Like the producer that wants to change the script simply because he is throwing money at the production. Setting the bounds of what the patrons can influence is a good thing for CM to do, in so that the core of the game remains on track for production to be steady, and we can play with how it looks and feels. To this end, I think that a hybrid is valid within what I have already stated. Keep the core mechanics of the game on the down-low and let us know what is happening as it comes up, and give us as much detail about the parts we are more concerned with and would influence as possible. The art, the characters, the story, the gameplay are all parts which an end user needs be concerned with.

heb heb

yo I'm not even a backer or programmer, but isn't this a false choice? move quickly, break things quickly, then put in fixes where needed. maybe you realize this, but it'd be easy to spend time fighting some problem which would be moot by implementing a new feature. Likewise, you probably can't get a solid base to work on without ironing out some bugs.