Sir Quizalot wrote:

There is currently a reliable source for learning to plan right.

I sure hope that source isn't downloaded from 4shared and the like.

Any particular courses?

I mean it's pay-walled at more per month than a BYOND membership is for a year, and people struggle with that, so I dunno how credible this is for people here, as a learning resource.

And you are using this set of methodologies for your current BYOND project, are you?

How far away are you from a first release of your game?

These are pretty old, sufficiently so that I'm hoping WANO doesn't mind my sharing them as they don't seem to represent well the game you'd play today.

But in a way that goes to demonstrate some of the point, because the outlay for these docs (and whatever associated dev was done) can't have been a spry 10 minutes a piece. Here is to hoping my drive permissions are okay:

https://docs.google.com/document/d/ 1Di2yfeoFYhcfoM2vb3_kAK6Q7n7IY6N9qfWoFzCABpg/ edit?usp=docslist_api

https://docs.google.com/document/d/ 1PVo_7z5l1kPE6g0TxHCH0d_D-u7zU2KxUFYpVpqb9qY/ edit?usp=docslist_api

https://docs.google.com/file/d/ 0B3uu_tK9aLXvMTJGMjFCQUY1OTk1OTEyNDowLjE/ edit?usp=docslist_api

Certainly, Shadowdarke outlaid a reasonable amount of actual development work on the clustering mechanism (and to be fair, if you actually needed that for your game, a little bit of design isn't bad, but also maybe you shouldn't be using BYOND as your platform then). Given it appears to be single server currently (or single + DB?), 2010's design efforts definitely feel like a waste. The date of the documents and their comparison to what you see in their fairly shallow mechanics (favouring roleplay instead now I guess?) also tell a bit of a story in itself, about the benefit of their design process on the end product. And Eternia is the success case!

Apparently all I'm sporting from emails in the Naruto Universe department is source code, and not their (kid you not) 100 page game design document. That project was in 2010, and essentially killed team members, in the productive sense, and ... well, wasn't formally ever released. The source code achieved ... 20% of what the doc laid out? Fairly organised code too, compared to other stuff I've seen.

What both of these neglected to grasp, basically, is there's a technical part, and a creative part to games. And in BYOND, the engine covers 95% of the technical part for you, meaning most of your work likes in the creative part. The part where once you try an idea out, you determine if it's fun or not in your overall game context, or if it impedes the fun, or distracts ... and you refine it, throw it entirely, whatever.

Doc heavy approaches inherently don't lend themselves to that tight requirements feedback loop and creative process, where customer stakeholder, dev AND manager are all probably the same person, and the vague 'fun' requirement is the only one really safe from revision and rewrite.

And when you're in soft requirements territory, TDD goes out of the window (not withstanding BYOND's unit test framework deficit), as it's trying to nail down stuff that will almost certainly change at the requirements level on/after play-test by people. Hence TDD is more exception than the norm in game dev, and where used, is usually platform related.

My particular issue here, is you seem to be shipping these things a la 'cargo cult engineering'. Like ... you've read that XYZ is important or useful from a source (and if we were talking big business systems, a fairly okay source)
... but not really understood the context of when that applies, and when it doesn't. There's emulation, without deeper comprehension of pros and cons.

BYOND forums suffer from an unhealthy tendancy of stealing buzzword-filled sentences from (often) reputable sources, in a show of attempted intelligence under the guise of being 'helpful' or trying to 'win' a discussion.

Programming is not a deeply philosophical phenomenon at the level you're operating at during game design on BYOND. You're not being 'academic', or an 'idealist' or anything like that. You're not commanding a team of 80 developers, art department, storyboarders, QA and trying to satisfy executive deadlines.

Post questions with as much effort as you would like the response to contain. Be concise: Check whether every sentence of your post is necessary or adds value to the discussion. If it does not, axe it. Be critical of yourself: Are you communicating what you set out to? Be informed: Find out what others think. Don't just skim some buzzwords on the back-cover of a programming book. You have to understand the material/concept!

The OP does none of this. It is reminiscent of a stray thought, not a topic worthy of discussion. This post is, as a whole, an example of the above criterion. It took 20 minutes to write. Many sentences were axed or re-phrased. Excess fluff was trimmed.

Same concepts no fluff. Anyway am I being graded? Iv'e seen some BYOND user's requirements so my question is answered. But if you willing to reveal more I could have searched out please do.

Fluff? I wonder about that.

Fun is always engaging not all engagment is fun. Watching a saw about to go through your arm while your forced to just watch could be engaging but not unless you like the feeling of intcipating imminent pain would it be fun. Yet fun is always engaging. I watched their episode on fun and what makes a game a game. I know what they're talking about.

Yeh I do.