Deleted
Deleted Member
Posts: 0
|
Post by Deleted on May 31, 2015 3:53:11 GMT
First off, they didn't really do a good job of detailing what folks were doing as the community were regularly told that far more developers were upon the title than they could show. Showing that Peter or the others that were detailed in this post were still working on Godus would have been neat (Peter Molyneux, Paul McLaughlin, Tim Meredith and Gary Leech)...as per the entire point of having the damn updates in the first place. This was pointed out to 22cans several times. Then the Daily Dev Updates continued to regularly contradict the number of claimed developers, up until only four developers could be posted about and no reason offered for the absence of others. The simple Copy+Paste was often missed upon the places where they were regularly linked to, as if the daily routine wasn't that important in communication with the community, and seemed to be given to the role of the moderators (when such really isn't their job to do). Then, the Daily Dev Updates ended by the community being expected to believe that the producer had no idea of what their own team were doing on a daily basis, which was becoming more believable as what everyone had for lunch started to hold more meaning. As much as Starbound is similarly in dev hell, as they lack critical core game systems for the features they pitched but insist upon making toys and re-working what was already said to be 90% done about two years ago, while their team lead of Tiy is as often clueless to the point that half of the team doesn't know what the other half is doing in "team updates" - at least they could do the daily blog thing competently enough for a bunch of folks new to this. Have a peek: playstarbound.com/They are even able to put together a dev team roster: playstarbound.com/team/Yes, I just said something positive about Chucklefish...but to be fair 22cans made it possible. |
|
|
|
Post by Crumpy Six on May 31, 2015 9:57:26 GMT
Simon (new CEO, for those watching at home) mentions the daily updates here and I think his assessment is refreshingly astute: godus.boards.net/post/20112/threadI'm not going to fall into the trap of letting the latest round of new hires convince me that anything is particularly going to change, but it's nice to see some acknowledgement that 22Cans' previous attempts to engage with the community have been badly thought out and, as he puts it, patronising. |
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on May 31, 2015 10:36:54 GMT
The first thing that should have been thought about the Daily Dev Updates would be "What purpose are these for?"
Normally, a dev blog is to showcase what is being worked upon and sharing the new bits of a game's development. So minus actually showing anything getting done, they would have to describe what they were doing on a daily basis. When only four developers could be shown...that hardly makes for a great impression, especially to anyone who can basic math: 22-4 = The Trail has more significant development than a game 22cans accepted money from their customers in advance for and appears to be farting around upon delivering upon any of their end.
So...how else does 22cans plan on showing their community that work is being done upon Godus, especially after Peter already described the title as "fully released" back as far as Feb?
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on May 31, 2015 12:35:08 GMT
I don't see the purpose for daily updates either... while no real thing to show... probably just symapthy for an attempt to communicate, which is good. "Unfortunately", devs have to feed the beasts that are the backers/followers, well at least a bit, and regularly.  |
|
Lord Ba'al
Supreme Deity
Posts: 6,260
Pledge level: Half a Partner
I like: Cats; single malt Scotch; Stargate; Amiga; fried potatoes; retro gaming; cheese; snickers; sticky tape.
I don't like: Dimples in the bottom of scotch bottles; Facebook games masquerading as godgames.
Steam: stonelesscutter
GOG: stonelesscutter
|
Post by Lord Ba'al on May 31, 2015 14:19:34 GMT
In my opinion a community update every two weeks would be ideal. It should contain significant information about everything that was worked on in the last two weeks and it should also contain what is in the planning to be worked on in the two weeks to come. Then there should be some discussion between the developers and the community to see if there is any useful feedback.
|
|
|
|
Post by 13thGeneral on May 31, 2015 16:23:42 GMT
In my opinion a community update every two weeks would be ideal. It should contain significant information about everything that was worked on in the last two weeks and it should also contain what is in the planning to be worked on in the two weeks to come. Then there should be some discussion between the developers and the community to see if there is any useful feedback. I agree, and believe a large portion of the community would prefer this method over pointless dailies or patronizing secretive monthly "teasers", like we've got all too often over the last 2.5 years. It doesn't sound that difficult to me, so I have no idea how they have managed to screw around so much with delivering updates so very wrong for so very long; other than the suspicion they are not interested in truthfully sharing what is actually going on. |
|
|
|
Post by earlparvisjam on Jun 1, 2015 3:09:54 GMT
There was nothing inherently wrong with the daily updates. The problem was that they were not followed by frequent updates to the code (whether on opt-in or the main branch). This caused most of the daily messages to turn into airy fluff that told the general community nothing. The same thing can be said about every weekly, every two weeks, or even once a month. There has to be some form of output for us to relate all the talk and we've never gotten it.
22Cans has no clue how to produce frequent updates. Their concept of Scrum is all talk and no substance. The worst part is that it just points out that every facet of this project is badly structured, poorly planned, and understaffed.
|
|
|
|
Post by hardly on Jun 1, 2015 3:52:16 GMT
There was nothing inherently wrong with the daily updates. The problem was that they were not followed by frequent updates to the code (whether on opt-in or the main branch). This caused most of the daily messages to turn into airy fluff that told the general community nothing. The same thing can be said about every weekly, every two weeks, or even once a month. There has to be some form of output for us to relate all the talk and we've never gotten it. 22Cans has no clue how to produce frequent updates. Their concept of Scrum is all talk and no substance. The worst part is that it just points out that every facet of this project is badly structured, poorly planned, and understaffed. Imagine I take you on a mystery rode trip, I blind fold you and I don't tell you where we are going. You don't know any of the locations or landmarks between where we start and where we will finish. Every hour I update you on what we are passing but I give you no other information. You also don't know how many kilometres per hour we are travelling but from your point of view it appears slow because we have been traveling for many days. How long before you get upset? Would the updates be helpful? What about if under the same scenario I tell you where we are going, I estimate how long it will take to get there, I tell you some of the landmarks we will pass on the way and I give you updates on how fast we are travelling. Now software development isn't as predictable as a road trip but that only makes the case for better communication. Passengers need information on the destination, milestones and rate of progress, if they don't have this information they will get restless. The daily updates were predictable frequency wise but with no point of reference, no objective measure of progress and no knowledge of the destination, the information contained was useless. Frequency of updates is neither here nor there as to their usefulness or the reception they will get, their usefullness is related to the roadmap they report against and we have no roadmap. |
|
|
|
Post by mindless on Jun 1, 2015 4:05:54 GMT
22Cans has no clue how to produce frequent updates. Their concept of Scrum is all talk and no substance. The worst part is that it just points out that every facet of this project is badly structured, poorly planned, and understaffed. It's hardly a surprise when you consider the inexperience of the staff who have been left to pick up the pieces, and is yet another signal to us that this project has long been & continues to be mismanaged. |
|
|
|
Post by greay on Jun 1, 2015 6:11:57 GMT
There was nothing inherently wrong with the daily updates. The problem was that they were not followed by frequent updates to the code (whether on opt-in or the main branch). This caused most of the daily messages to turn into airy fluff that told the general community nothing. The same thing can be said about every weekly, every two weeks, or even once a month. There has to be some form of output for us to relate all the talk and we've never gotten it. 22Cans has no clue how to produce frequent updates. Their concept of Scrum is all talk and no substance. The worst part is that it just points out that every facet of this project is badly structured, poorly planned, and understaffed. This is so common there's a term for it: Scrumbut |
|
|
|
Post by totallytim on Jun 1, 2015 11:00:33 GMT
I sincerely doubt that they even realise what scrum is or how to efficiently carry out projects.
I was sceptical when I first heard Peter talking about "iterative development". Now the term gives me shivers down my spine.
|
|
|
|
Post by Deth on Jun 1, 2015 11:47:40 GMT
Imagine I take you on a mystery rode trip, I blind fold you and I don't tell you where we are going. You don't know any of the locations or landmarks between where we start and where we will finish. Every hour I update you on what we are passing but I give you no other information. You also don't know how many kilometres per hour we are travelling but from your point of view it appears slow because we have been traveling for many days. How long before you get upset? Would the updates be helpful? What about if under the same scenario I tell you where we are going, I estimate how long it will take to get there, I tell you some of the landmarks we will pass on the way and I give you updates on how fast we are travelling. Now software development isn't as predictable as a road trip but that only makes the case for better communication. Passengers need information on the destination, milestones and rate of progress, if they don't have this information they will get restless. The daily updates were predictable frequency wise but with no point of reference, no objective measure of progress and no knowledge of the destination, the information contained was useless. Frequency of updates is neither here nor there as to their usefulness or the reception they will get, their usefullness is related to the roadmap they report against and we have no roadmap. I would have no problem with the first scenario, I believe, if the land markjs you spoke of was, the Biggist Ball of Twine, The Cadillac Ranch, or Leaning tower of Niles. I may not still know where we are or where we are going but they at least sound interesting. But getting getting told that we just passed Applebee's, a Stop-n-go and a Burger King is not as interesting no. |
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jun 2, 2015 13:02:17 GMT
I sincerely doubt that they even realise what scrum is or how to efficiently carry out projects. I was sceptical when I first heard Peter talking about "iterative development". Now the term gives me shivers down my spine. Did they REALLY need to use "22cans has an iterative, suck-it-and-see approach to Godus’ design"? www.22cans.com/godus-roadmap-where-are-we-headed/ |
|
|
|
Post by 13thGeneral on Jun 2, 2015 13:36:33 GMT
I sincerely doubt that they even realise what scrum is or how to efficiently carry out projects. I was sceptical when I first heard Peter talking about "iterative development". Now the term gives me shivers down my spine. Did they REALLY need to use "22cans has an iterative, suck-it-and-see approach to Godus’ design"? www.22cans.com/godus-roadmap-where-are-we-headed/I find that term to be very off-putting and never understood why you'd want to admit to using that kind of phrase to describe game development. Connotations to any potential negative words would not be my first choice, especially when talking to my customers. Trying things and discovering flaws or reasons it won't work is one thing, but they always talk as if they have a wall of ideas and just throw darts at it to determine what to implement. What a terrible way to work ; there always needs to be a strong idea and underlying structure to build around, and I feel they never really figured that out before adding the other parts. And now it seems it's just too far gone to go back in and repair the core. Oh, but stay tuned, because COMBAT!!! *sigh* |
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jun 2, 2015 13:42:43 GMT
I find that term to be very off-putting and never understood why you'd want to admit to using that kind of phrase to describe game development. Connotations to any potential negative words would not be my first choice, especially when talking to my customers. Trying things and discovering flaws or reasons it won't work is one thing, but they always talk as if they have a wall of ideas and just throw darts at it to determine what to implement. What a terrible way to work ; there always needs to be a strong idea and underlying structure to build around, and I feel they never really figured that out before adding the other parts. And now it seems it's just too far gone to go back in and repair the core. Oh, but stay tuned, because COMBAT!!! *sigh* That word is being used so often it might as well be code. I'm off for a little while - I have to go drop a huge Combat. |
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jun 2, 2015 15:58:07 GMT
I sincerely doubt that they even realise what scrum is or how to efficiently carry out projects. I was sceptical when I first heard Peter talking about "iterative development". Now the term gives me shivers down my spine. Did they REALLY need to use "22cans has an iterative, suck-it-and-see approach to Godus’ design"? www.22cans.com/godus-roadmap-where-are-we-headed/It's interesting... if only they could get the balance right. So far there seems to be much more sucking.. and not so much seeing.  |
|
|
|
Post by mindless on Jun 2, 2015 16:29:25 GMT
Maybe instructions got lost in translation. And the devs understood that their role was to make the game suck? This would actually explain alot if true |
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jun 3, 2015 1:28:39 GMT
That word is being used so often it might as well be code. I'm off for a little while - I have to go drop a huge Combat. Sorry about that, apparently that "Combat" took more than 10 hours...I might need to borrow one of Lord Ba'al's extra bog rolls. I've #madeagodus!  |
|
|
|
Post by earlparvisjam on Jun 3, 2015 1:44:54 GMT
There was nothing inherently wrong with the daily updates. The problem was that they were not followed by frequent updates to the code (whether on opt-in or the main branch). This caused most of the daily messages to turn into airy fluff that told the general community nothing. The same thing can be said about every weekly, every two weeks, or even once a month. There has to be some form of output for us to relate all the talk and we've never gotten it. 22Cans has no clue how to produce frequent updates. Their concept of Scrum is all talk and no substance. The worst part is that it just points out that every facet of this project is badly structured, poorly planned, and understaffed. Imagine I take you on a mystery rode trip, I blind fold you and I don't tell you where we are going. You don't know any of the locations or landmarks between where we start and where we will finish. Every hour I update you on what we are passing but I give you no other information. You also don't know how many kilometres per hour we are travelling but from your point of view it appears slow because we have been traveling for many days. How long before you get upset? Would the updates be helpful? What about if under the same scenario I tell you where we are going, I estimate how long it will take to get there, I tell you some of the landmarks we will pass on the way and I give you updates on how fast we are travelling. Now software development isn't as predictable as a road trip but that only makes the case for better communication. Passengers need information on the destination, milestones and rate of progress, if they don't have this information they will get restless. The daily updates were predictable frequency wise but with no point of reference, no objective measure of progress and no knowledge of the destination, the information contained was useless. Frequency of updates is neither here nor there as to their usefulness or the reception they will get, their usefullness is related to the roadmap they report against and we have no roadmap. What I'm pointing out, using your analogy is that we go on a mystery road trip. We get the hourly updates, and are told about landmarks. Rather than stopping for a few minutes to stretch legs and view them, the station wagon keeps going and going and going. We hear about how we just passed an amazing herd of elk. The copilot goes on about how amazing the sunset is that evening. The station wagon stops for a bit and it sounds like the people up front have hopped out. A bit later, some strangers hop in and the car begins going again. When the car finally stops for a break, they whip off the mask. Looking around, it's clear that the road signs say we're only about 10 blocks from home and we're sitting with a couple strangers. |
|
tikigod
Master
Resistance is mean.
Posts: 115 
|
Post by tikigod on Jun 3, 2015 2:24:40 GMT
I think in terms of dev updates, Gaslamp are a example of doing it properly. They aren't daily but are generally weekly for the most part with the occasional gap, but when they one is published they dive right into a specific mechanic of the game covering work being done on that mechanic, the future plans for it, their thoughts behind what role the mechanic is supposed to play and importantly they go into detail. Examples: www.gaslampgames.com/2015/05/27/fishy-foreign-faction-missions/www.gaslampgames.com/2015/05/13/i-smoulder-with-programmer-rage-ii-escape-from-new-sogwood/www.gaslampgames.com/2015/05/06/the-downward-tantrum-spiral/www.gaslampgames.com/2015/04/29/event-design-using-twine/www.gaslampgames.com/2015/04/22/the-magic-of-friendship-in-clockwork-empires/www.gaslampgames.com/2015/04/15/smart-objects-or-everything-i-know-about-ai-i-stole-from-the-sims/More examples mixed alongside other articles like release announcements etc: www.gaslampgames.com/blog/They also keep up a consistent experimental branch for build releases (With a fixed monthly release to the stable branch) throwing new ideas or system overhauls out there almost weekly often in line with the content of the dev updates to get feedback on the very thing the dev updates are covering. So key points: * Keep the dev update focused on a topic. Pick something being done, or some existing feature in the game. That's going to be the theme for the update, don't deviate, don't stray off the theme just to toot your own horn or try to damage control. Just pick a subject and cover how the feature is now, why it's like it is, the future plans for it and if it's being worked on and if not the general priority for it. * Detail is your friend. If someone tries to tell you "Most people don't want the gritty details, they just want fluffy spin and nice sounding rhetoric to make them shut up and feel important", slap them with a wet kipper then promptly ignore them! Detail is your friend, the more gritty detail you give, the more information everyone has and the less speculative hole filling and constant questions of "But what about...." being throw at you. * If something has been found to be horrendously broken, don't shy away from it. Acknowledge you know something is broken or doesn't quite mesh well with it's companion mechanics, then cover what the ideas being tossed around to addressing that are. * Stating things that never happen aren't a bad thing in itself. As long as you're honest and very clear about what is purely an idea not yet even conceptualised and keep a track on ideas disclosed and set a period to go back and cover that topic again at a later date to give a "Then and now" catch up. Meshing that together to form a loose example for a Godus update: TitleTraining Primordial chimps - Godus Follow Behaviour. ThemeEverything to do with follower AI. ContentHow the AI currently work from a detailed design perspective. What the intended scope for follower AI is moving forward. Are things current seen as done and dusted or more placeholder behaviour and missing additional aspects. If there are any elements to follower behaviour currently not hooked up to anything player facing, discuss them. How might they be used? Why followers are simple and shallow as they currently are. Is it due to requirement for significant behaviour work pending, or for some design reason where it was decided that followers were meant to be empty souless scenery to focus emphasis on god powers instead. The fate of elusive aware and reactive followers that were mentioned the start of 2014 slated for 2.0 that never saw the light of day and was never spoken of again. What isn't in the content
Excuses. Blame. Evasive tactics. BS Spin on how other things that have absolutely nothing to do with the updates theme will be super awesome and better than anything that could be said on the actual intended topic. Avoiding detail out of fear of being given feedback. Feedback is good. The quality of what you get back is controlled by the quality of the detail you provide. So stay in control. Dates. Just don't do it. Keep it to covering the topic in detail. Date announcements and other things are for other releases, not for development updates. Mention if something is being worked on or is for later on for sure, maybe even mention broad placement on a roadmap. But this isn't about drumming up release attention. It's about clean information and communicating. If something doesn't meet these criteria?
If something specific you want to say can't fall within the above scope of a development update. Then identify it as something other than a dev update. Examples: Release Announcements. Damage control and/or mini-updates. (E.G. Hey everyone the last build totally fucked over everyone's game, we're aware of this and are working hard to get it sorted soon. More news to follow) Attention grabbing BS articles (Heya Chris Roberts!  ) So keep such things away from ever being called or regarded as dev updates. They're not. |
|
) 