Off-Topic Boards > General Discussion
Simon blogs
Simon:
Hi,
some loose rambling.
Basic tenet in open source: People are interested in how other people solve problems. You share source code obviously, but you also love to talk about what it does, and are honest about its shortcomings. You can show proudness of your project, provided you're not hiding the problems.
I'm sure the IRC regulars have grown used to "Lix does it like this, the reasons for it are A, B, C, and the source is ugly." The ugly parts ("// 9 indentation levels is way too much") come to mind much more frequently than the nice parts. Good parts don't come to mind all the time; they're simple and to-the-point.
You value public bug reports, and you value source patches even higher. Likewise, users are happy to make bug reports. (Treat users as co-developers.)
Level design shares some qualities with such development, but is different.
People don't play a pack several times. Given the abundance of great and intriguing levels today, people play your pack once if you're lucky, and zero times if you're not. Useful software is run again and again, individual levels are not.
As a pack developer, you want your users to play thoroughly tested levels. There are several approaches. You can make a closed beta. You can release on Lemmini first, where you have fewer users. Or, what I'd do -- release normally, be honest that it's not playtested, and have good faith that people won't play all at once.
I believe I'm unconventional: I cherry-pick single levels. I wait until other people praise certain levels, or, as with Icho's pack, entire level packs. Only then I invest a serious amount of time. As a result, my level diet consists of heavily playtested levels. Maybe others are like me; probably many are to a lesser extent.
Even if you choose "release publicly, and hope that some will wait anyway", you probably don't want unspoilered solutions in public posts. Most authors like feedback in a spoiler tag, or as a replay file. This way, the solutions are public, but you have to explicitly want to see them. This is exactly what spoiler tags are designed for: They don't put the solution out of reach, but only out of accidental reach.
I don't care if people post unspoilered solutions publicly for my little handful of levels. With time limits and hidden traps, I'm happy that most contemporary level designers share my views. But I won't shape discussion culture for level designers. If many like the spoiler-tagging and don't want solutions bantered in logged IRC, then following suit is the way to go.
Bonus rambling, apropos diet: The guinea pig diet consists of eating lots and lots of cucumber. A guinea pig would do the same, and they are extremely cute and obviously extremely smart, because they eat cucumber, which is tasty. Aim for at least half a cucumber per day, maybe even one per day. And cut way back on sugar drinks. Magic will happen!
<SimonN> I have bought 2 cucumbers earlier today, 1 is already eaten. Love love love
<geoo> me too :D :D :D
-- Simon
Simon:
More loose rambling. Some of these ideas, I've presented them on IRC over the past months.
namida was sad on how bugs crept up in NL1. But finding many more bugs was expected: 2015 has been a super-active year for NL level development. 2015 was also a comparatively busy year for NL playing; I played at Ichotolot's without making my own levels. And more users find more bugs (obligatory link to Cathedral and the Bazaar).
namida likes NX as the abbreviation for NeoLemmix, presumably like Fx for Firefox, or because the X is cool. NX feels unnatural when you use PascalCase for the long name. The obvious abbreviation is exactly the capitalized letters.
If you get feedback, react to it in some way. Maybe you don't want to fix issues right away, then at least list them publicly. You won't get school grades for your hobby project, so don't try to hide flaws from other people. Icho is in his 5th or 6th iteration of backroute-fixing his large NL pack. This is splendid support. namida improved on tracking NL issues by encouraging separate topics for each, even though he'd like to fix only serious bugs right now. Also great.
Porting Lix's C++ code to D, I've noticed bugs in the physics from mere reading of code. Every program is full of bugs, this is also normal. You write software, you have bugs. (You make levels, you have backroutes.) I won't replicate C++ physics exactly, only wherever they feel important and easy-to-describe. geoo proposed to reorder some physics code anyway in the most recent C++ release 2015-09-02, and there are bugs to be fixed.
Example of why replicating physics would suck: The tumbler and flingploder are horrible to replicate exactly. The tumbler (= lix that is flung) had a bug in C++ where some terrain checks were off by 1 pixel, it got stuck inside 1-pixel-high horizontal lines. This is fixed, I hope, in D. Since the flingploder produces tumblers, it can't be ported accurately, unless I wanted to keep the other bug in. And the old exploder masks aren't symmetric. And the fling speed computation is crazily complicated. Yuck yuck yuck.
On the other hand, walker, faller, and ascender physics are ported with 100 % accuracy. They are much more a part of how the game feels. Also, sometimes we run into things we'd rather preserve as they are, come hell or high water:
// Horrible function. Copied out of C++ Lix almost unaltered.
// The problem is that this function's semantics have already been
// debugged to no end, C++ Lix had lots of bugs with tumblers over
// the years. We'd have to be really smart to make this simpler.
final Collision collision()
{
...
This got way too technical and low-level again. Rambling is best at high level.
The more features your game has, the harder and longer any porting attempt will be, and the more features can come out wrong/buggy/strange.
When you rewrite, which is crazy from the get-go, continue to support the old version until the new one is done. Seen from the outside, NL does this well. Lix, seen from inside, not so much I believe >_> But other people could tell better. I've had 2 large releases in the middle of 2015, while the D port has been underway since 2015-02. I haven't included Raymanni's sets.
Over the past 4 months, I lost 9 kilograms with the guinea pig diet! (= 20 pounds in archaic units) Happy happy happy.
-- Simon
Simon:
I was fun-browsing Wikipedia about the Euler-Mascheroni constant, read one of the linked papers, and found a lovely qoute inside: How Euler, Johann Bernoulli and Jacob Bernoulli stayed motivated and productive. (source info)
* Always attack a special problem. If possible solve the special problem in a way that leads to a general method.
* Read and digest every earlier attempt at a theory of the phenomenon in question.
* Let a key problem solved be a father to a key problem posed. The new problem finds its place on the structure provided by the solution of the old; its solution in turn will provide further structure.
* If two special problems solved seem cognate, try to unite them in a general scheme. To do so, set aside the differences, and try to build a structure on the common features.
* Never rest content with an imperfect or incomplete argument. If you cannot complete and perfect it yourself, lay bare its flaws for others to see.
* Never abandon a problem you have solved. There are always better ways. Keep searching for them, for they lead to a fuller understanding. While broadening, deepen and simplify.
-- Simon
mobius:
these sounds like the "Oblique strategies" I mentioned yesterday. Speaking of which; you can buy Oblique Strategies on places like ebay... except it costs 500$ :lem-shocked:??? because it's a very rare thing supposedly.
Can you recommend some similar books and things but at a reasonable price? Or maybe website that has these things?
Simon:
No, don't know any books on aphorisms to boost motivation. My bedtime literature tends to be technical books, flower math, and books on games. >_>
-- Simon
Navigation
[0] Message Index
[#] Next page
Go to full version