Development news: the increment

ID:2577372
 
Jun 5 2020, 9:38 am
Bugs are winding down in the 513 beta and some issues that needed finalizing before closing the beta series have mostly been taken care of, so I believe 513.1526 is still on track to be the new stable build. I have a couple of items open that I need to button up or where I was waiting for test cases, but I think I'm mostly ready to finish those last couple issues. A few very minor ones remain, basically much older issues, that can be handled in maintenance releases. I think the beta is going to close next week.

Because I was in limbo on a few things for 513 this week, though, I decided to pull the trigger and start progress in earnest on 514. I already had some partial code for particles which is still progressing, but this is my first official work on new features by touching existing code. Specifically, I wanted to start on low-hanging fruit like some new operators for the language, and I'll probably look into return types for procs shortly. I don't know yet how far I'll take return types, whether it'll be the basis for something bigger or if it will only be used as a way of applying the . operator after a proc call. For some projects, the latter will be useful enough. It also occurred to me that it'd be awesome to be able to get a type for other expressions if possible, such as (a?b:c).

A very big item on my list is coming up with a syntax for particle sets. I'd like to be able to build particles as a basic inheritable structure that you can modify and therefore refer to it easily with a type path, but also I want that structure to be very flexible. So it needs some kind of easy syntax for setting initial conditions that may be random. For instance, velocity: I'd like ot specify several ways of handling the vector, including a random spread of the x and y components (and z), but also a way of handling this by direction and speed would be good too. And for any value that may be set, there should be two ways to handle randomness: either a range that can be chosen with uniform probability, or a mean and standard deviation (and upper limit on deviation) for a modified normal distribution (bell curve).

So right now, exciting changes are going on already for 514 even while 513 prepares to close out the beta. And I'm grateful to all of you who have made that work possible as Members, donors, or on platforms like Patreon. Thank you all so much for your support.

Nice weather is finally upon us, but still no grilling for me. Go enjoy a good steak while you can, and make the most of summer. At least once everything reopens.
Jun 5 2020, 11:13 am
O.O
Jun 5 2020, 4:07 pm
/o/
Jun 6 2020, 3:48 pm
^.^
Jun 6 2020, 9:22 pm (Edited on Jun 6 2020, 9:29 pm)
My recent thoughts on particles, which turned out to apply to new features in general, out of concern for how most big new features have turned out in the past:

This is the most important thing:
What does the "ideal" system that is easy for a typical developer to understand and work with, look like?
It should have a low skill floor and a high skill ceiling.
In other words, it should be straightforward for any developer to get started with,
while still allowing them to make what they want to make.
Aside:
If it's not easy, only skilled developers will know what it is, why it's important, and how to use it.
Eventually, some less-skilled developers will catch on if enough skilled developers show off their work
(like they have been in show-off threads and Discord).
That's not how feature usage should be spreading.
They don't know what they're missing.
They don't want to know. It's too hard.
"My game doesn't need it anyway. It's been perfectly fine without it."
("Therefore, it provides no benefit"..? They already gave up on it.)

So, what exactly is what they want to make?
The answer to this requires research, like getting real feedback from game developers.
(And seeing how existing games/game engines go about it.)
Otherwise, who are you making this for?
How do you know when it's ready?
What prevents you from wasting time on features that no one actually asked for?
Aside:
I haven't seen much constructive feedback for anything on the forums, Discord, Patreon, etc.
Don't you have any direct design questions for us?
You keep telling us what you're up to,
but if we're not actually involved at all,
do you gain anything from that?
What do developers gain from you gaining nothing?

How do you get real feedback on something that doesn't exist?

Make it exist. Badly, if necessary.

Why not release the first most basic iteration of the feature, as soon as possible?
Call it experimental, be explicit:
"Expect this to break in the near future as this feature is developed according to community feedback."
It should be something simple enough for anyone to get started with.
It would also serve as a starting point for future developers to learn.
The sooner you do this, the sooner this happens:
  • Developers get their hands on something simple to mess with.
    You can't know it's usable until it's available.
  • Feature requests come in, inspired by actual use cases.
    This is the real feedback that tells you where to go next.
  • Bug reports come in. As a bonus, they're focused on the one new thing.
    This helps you make sure it works.
  • Future developers don't end up with a feature that is not easy to use by the time it's too late to make it any easier to use.

Also, if no one's talking about a feature, you can assume it's too hard to use and no one's using it, so you should try to find out why.

Usability improvements should be an ongoing effort. Forever.
Making those changes always gets harder over time.
You need to make the necessary changes as soon as possible.
But, again, you can't know what changes to make until the feature is available.
You can't know if it's easy enough to use until enough people are refusing to learn it.
A feature shouldn't be locked down (for backwards compatibility) before everyone who wants to use it can use it easily and effectively.

How do you make features easy to use?
  • Avoid premature optimization.
    If features are coming out more obscure due to any optimization at all, your priorities are flipped.
    If it's hyper-efficient, but no one's using it, it's dead code.
    If it's inefficient, but people are using it, that's perfect.
    If people want more performance out of it, then optimize it.
    Just don't make it harder to use for the sake of performance.
    Don't forget that DM is object-oriented.
    Enough global junk and primitive obsession. Self-document the path tree.
    Serialize objects however you want to for the purposes of network communication or whatever,
    but spare us the details.
  • Don't just listen to feedback, get feedback. Also, listen to it.
    Just because it's easy for you, doesn't mean it's easy for anyone else.
    This doesn't just mean listen to feedback, because clearly there hasn't been enough feedback to listen to.
    You'll also need to more actively ask for feedback,
    otherwise all we can do is complain or go with the flow
    after it's already too late.
Jun 6 2020, 9:39 pm
Sounds like your're recommending Lummox get on the agile train.
Jun 6 2020, 9:53 pm
BYOND Enhanced Edition - Wishlist
  • Particles
  • Shadowcasting
  • No Ads
  • Being able to attach /atom/movables together so they all either move or don't.
  • client.KeyDown("Z+CTRL+SHIFT") would return TRUE if Z+CTRL+SHIFT is being held down.
  • Being able to have some sort of input displayed on the map without using winset()
Jun 6 2020, 10:48 pm
In response to Kozuma3
You forgot compile2exe heathen.

You can already do the KeyDown thing with the Any Macro... it's pretty easy too.
Jun 7 2020, 4:43 am
What Kaiochao said, In a nutshell, BYOND has always lacked the "CEO Mentality" and it's been always driven by engineers that ignore basic, CHEAP TO FREE, marketing and branding advice for years.

I remember writing about it a few years ago, a short analysis of multiple years of updates that never actually pushed what BYOND seems to be about forward.

It wasn't until I wanted to donate to BYOND that Tom hadn't even thought(openly) of putting up a donate button instead of just selling memberships.

If Lummox sat down for a day and thought about the business side of things maybe the positive changes that have happened could be noticed.

Why has there never been any form of a Roadmap? Because there has not been a Vision for where to go, a Mission on how to get there and the Values to make it happen.

Then Ideas for features are thrown out there sometimes, rarely, and all there is is silence about them. How can people understand what ideas are possible or simply not accepted when ignoring them is the status quo? Then people that rarely even communicate or have yet to do so will not want to even bother.

It's been at least 18 months since 512 stable. I can't be the only one that thinks a stable version should be no longer than 6 months, right?
Jun 7 2020, 9:35 am
Modern day practices recommend much shorter release cycles (weeks not months) and the value delivered is incremental. Goal is to get the feedback (usages/interest/issues) loop as Kaiochao suggested as short as possible. Doing so makes you "agile" and lets you freely pivot as market/customer priorities shift.

With that said, Lummox does release often and with release notes so he's most of the way there. Seems the concerns are around the early stages of planning and design. Imagine this topic comes up at every major milestone.

Might be an opportunity to host some design sessions for developers (customers) that would help bridge the gap. Could get them involved a little during the planning/design phase using something like Zoom. You can record the session for those that can't make it. Provide a list of backlog items and see how they prioritize them (whiteboard voting) and why. With the items prioritized, maybe they can help flush out the early designs. It wouldn't (shouldn't) be a one time thing. Something like that could happen every couple of months where a couple big ticket items are planned and then released incrementally over the next two months. They call it getting on a release cadence. See Scaled Agile Framework for how this works but at scale of course.
https://www.scaledagileframework.com/agile-release-train/

Having a public backlog (Trello/GitLab/etc) could be a good start.

I don't have any major concerns but I also don't push the limits of what BYOND can do. Meaning, I'm not as critical about what comes next and how. I can certainly understand the frustration of needing certain things but being at the mercy of someone on when and how you get those things.

It would be interesting to pick the brain of lummox to see how he visualizes the business and it's customers.
Jun 7 2020, 3:57 pm
From a SS13 dev standpoint, we definitely like hopping on beta releases / new features soon after they come out. Kaiochao's comments above about hopping on the agile train definitely resonate with me.

I do like the idea of more frequent stable releases as well. It's kinda annoying having to tell people to download the latest beta constantly.

A roadmap would definitely be nice. Even just a basic one, "features for next release" or something would be great.

I was reading your particle writeup on Patreon, and some of it was a bit confusing. I don't think you really need to model a lot of that stuff with differential equations, you can just solve for velocity in the physics equation. Like: shorturl.at/cfwEV

If you're gonna calculate changes in velocity iteratively because drag is velocity dependent, that's a solvable problem and you can still model it continuously. The repulsors could throw a slight wrench into it though if there's 3+ bodies.
Jun 7 2020, 8:34 pm
In response to Zewaka
I could probably handle continuous drag if attractors weren't in the mix, although it would definitely be more tedious to solve. But with attractors, I think if I include drag at all it'll have to be the cheapo discrete calculations because attractors would have to be done that way anyway.