So I decided to finally scrub out all the API keys or other wacky/sensitive stuff from version control and make an orphan branch of Arx on github in case people wanted to tinker with Evennia or use any code ideas for their own projects. I'll probably update the branch there with major updates, like any new system we add.

I'm okay with pull requests/opening issues there if people are so inclined, though I don't really wanna spend the time going through the hundreds of open feature requests in our helpdesk system and moving those to issues right now.

Anyhoo, here it is: https://github.com/Arx-Game/arxcode

The next time anyone bitches about lack of documentation for Arx I'll threaten to hire Chet to write it all.

My work story can be summarized with the quote: "Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing."

So the team I joined was just a teensy bit lacking when it came to rigor. The entirety of their testing consisted of one QA person who had a regression test suite that would hit endpoints on our staging environment. That was it. The whole thing. So I tentatively kept asking about 'Have you heard the good news about our lord and savior: Unit Tests' and they kept kinda brushing me off, saying that they didn't have any idea how to get django's test runner with Oracle, and even if they did who has the time to write unit tests, amirite?

Undeterred, I decided to both get the test runner working with Oracle, and then write extensive unit tests for the core models of our app when I was doing a major refactor. Yay, we have tests, everyone's happy! I mean, I don't particularly enjoy writing tests, and am far from an expert in the subject, but sure, great.

Then it devolves into some guy who's a pal of the team having a Jenkins instance that he was randomly running some security scans on our software images, and they ask if I can get the tests hooked up to there. Okay, sure, I've never used Jenkins before but I guess I can spend time doing that.

Fast forward to now and I'm somehow responsible for managing every aspect of our Jenkins instance and constantly trying to open cases with our IT department that actually owns the global configuration and can change fucking plugins that never seem to work right. I absolutely hate devops with every fiber of my being and somehow I've become our designated devops guy. Also, I'm still the only member of the team who even knows how to read tests much less write them, so I'm stuck with constantly letting people know when they'd break the goddamned build.

@carex said in Development Thread: Sacred Seed:

It really doesn't matter how smart, wise, or powerful a woman is because she can make more people. If she is powerful, people will demand she make more powerful people. It's just a matter of survival. If you have a good thing, make more of it.

Things might have been a tad different in those societies if the people in question had the ability to turn someone into ashes with their mind. Fantasy worlds provide the opportunity for speculative historical fiction rather than just going 'medieval Europe, but with eye-lasers'.

One thing I didn't expect from our own game is that if you decide to break from a strict historical analogue to have a more progressive society how much pushback you get over it. Like saying 'oh, it's an egalitarian society, sexism isn't really thematic' seems simple, but HOO BOY, people will try to undermine that constantly. It requires you to be extremely explicit in help files and culturally have the playerbase on board with correcting misconceptions constantly. Some players are really, really married to the concept of calling other players whores in their pretendy freetimes.

I am willing to die on the hill of toopul.

So in the 'Earning Stuff' thread, there was a digression about the difficulties that can be created when player expectations and the reality of managing a game don't properly align. Players tend to want agency and for their actions to matter, but can have wildly different expectations for scope - on the most toxic end, you have players who are incredibly unhappy when any other player gets some recognition or anything that makes them special in some way, whereas probably the most benign examples would be players who want their efforts to help support the stories of other players to be registered at all.

What I'm curious about is the approaches that people might take to try to address the problem, if they think it's one that can have a solution at all. Should it be done culturally, with help files, onboarding of new players or the first time they participate in some staff-run plot, or something else that informs them to manage their expectations? Should it be something coded, where the scope of impact they could hope to achieve from some given action would be clearly delineated? Should it only be addressed on a behavioral level by talking to players who are clearly outliers? Or something else entirely?

@sparks said in Arx on github:

@tehom said in Arx on github:

@wyrdathru said in Arx on github:

Now, what about tabs or spaces, camelCasing or PascalCasing, Li-nux or Lin-ux and more!

LET THE BLOODSPORTS BEGIN

Guido might have retired, but that hasn't stopped the violent gangs of devotees who lynch developers for flagrant violations of PEP8. Not a day goes by that you can't find a new victim's mangled body with a sign on them saying 'USED CAMELCASE FOR VARIABLES' or the like. I might disapprove of their methods, but I agree with them in principle.

Even PyCharm itself will yell at you for PEP8 violations!

I am confident that this is the only reason I am still alive.

@lemon-fox said in Coming Soon: Arx, After the Reckoning:

@apos said in Coming Soon: Arx, After the Reckoning:

I'm not above anyone humming loudly and pretending the code doesn't exist either if that's not their jam, but hopefully I can keep trying to get it more intuitive and friendly as time goes on.

I don't know if this is true for anyone else, but the biggest issue I had was trying to get retainers to work as helpers on investigations. The code there was...awkward, I guess? Everything else worked pretty well once I actually understood how it was supposed to work--support tasks took a long time for me to grasp, for example.

Yeah, not my best work. Too much abstraction is a hell of a drug.

@three-eyed-crow said in Arx: @clues:

Given that part of the theme is rediscovering lost knowledge, I don't know how thematic clue deterioration would be. I feel like, once it's uncovered, it's back in the wider world. I do wish you got a certain number of 'free' clue shares a week (kind of like your Teaching stat gives you free trains a week) but if I were to isolate the systems on Arx I think are semi-broken, clues would be fairly low on the list.

My hate-on for orgs that just bank a bunch of clues for people to brief themselves on with no context is vast and I think it leads to problems in terms of people RPing some real whack-a-doo things, but making clues harder to share individually and without scenes would just make this worse.

Requiring clue briefing from orgs (and possibly from individuals) to require bundling clues into theories in order to provide context is on the to-do list. It's a little more annoying to implement than it sounds, so it'll probably take a little while, though.

The next time anyone bitches about lack of documentation for Arx I'll threaten to hire Chet to write it all.

There's a number of tutorials in Evennia. I tend to also favor the "just dive in" approach, but you could also try a book like "Automate the Boring Stuff With Python" which tries to teach python by letting you write various scripts for different tasks. A lot of them are kind of contrived but I think it gets the point across.

As others echo though, general python knowledge might be a prerequisite for Evennia, but that's in itself just a starting point. Evennia is a framework built on other frameworks, so there's some deep tribal knowledge there that there's no way around than just looking through it.

My feeling is if your game concept can be done in Ares, then it really should be - the amount of work that needs to be done to get an Evennia game up and running is pretty daunting right now, even with code samples from Arx or elsewhere. Hopefully that's not always the case, but as is I'd endorse Ares for anything that fits it reasonably well.

If your game can't and you do want to try Evennia, I'd be happy to answer any questions you might have, though.

@Derp said in Getting Young Blood Into MU*'ing:

@Apos said in Getting Young Blood Into MU*'ing:

But most people honestly don't.

Bull.. Shit.

Most people see this kind of behavior all the time. They've just never worked in the environments you mentioned before, which teach you to actively recognize and respond to it. They're happy to go on ignoring it like they never noticed, but I don't believe for a second that they've never seen it, or that those maladaptive behaviors are not the norm.

Pick up pretty much any kind of psychology book and you'll see why this statement doesn't hold an ounce of water.

I'm reasonably sure that "any kind of psychology book" won't disprove the notion that people encounter different things based on their environments. Most people are intellectually aware that people do bad things, yes. We're all aware that snuff videos of ISIS decapitations exist, child pornography, and the like. Yet we don't have to see it on a daily basis because we're not Facebook content moderators: it is not the norm for us.

Similarly, I'm aware that many people in this hobby behave badly, and people display the same bad behavior in real life. Yet I do not see such behavior in my professional environment, because in that environment there would be severe consequences for behaving similarly.

@Griatch said in Getting Young Blood Into MU*'ing:

@Tehom said in Getting Young Blood Into MU*'ing:

The early announcement of an upcoming new proprietary programming language called 'Dark' made me immediately think of how it could apply to MU*. It's designed from the ground up to be a language based around ease of deployment - it requires you to be in their own editor where code is sandboxed in an environment in prod, with built-in versioning via feature flags. The notion of built-in controls for how someone can change an environment with massive guard rails that prevent anyone from breaking the build and dead-simple deployment was made with enterprise-scale deployments in mind, but it's hard to imagine something easier for people to engage with for hobbyists.

The downside is if the company ever went out of business they'd take your entire game with it, and it probably wouldn't be free to use. Still, some of the ideas from it might be worth trying to adapt into other languages.

This may be going a bit off-topic I guess, but ...
Requiring to be in their own editor sounds a bit iffy to me. As for ease of deployment, I reckon in an embedded mode, none of these embedded languages would be something the end user would install and configure on their own ... it would most likely come as a component for another system, so deployment is less of a concern in that respect (even though it's nice for the core dev of course).
How does Dark improve on, say Lua, which is an existing language commonly used for embedding and which, as far as I understand, is also reasonably sandboxed in that form?

My understanding is it's intended to be a full backend solution with built-in deployment - they even intend to handle database migrations in it. Here's the hackernews thread with the link to the medium article: https://news.ycombinator.com/item?id=20394166

Getting people to give up the code editors they love will be kind of a hard sell, but it did make me think that in many ways the ease of deployment and controls on modifications by a team that might not be super cohesive has some appeal for MU* development. After all, one of the biggest challenges with requests for softcode in Evennia has been trying to figure out exactly what sort of permissions you grant people: you can't just let them eval() arbitrary text and so on. Maybe adapting their notion of built-in feature flags for everything might be some approach that'd work.

The early announcement of an upcoming new proprietary programming language called 'Dark' made me immediately think of how it could apply to MU*. It's designed from the ground up to be a language based around ease of deployment - it requires you to be in their own editor where code is sandboxed in an environment in prod, with built-in versioning via feature flags. The notion of built-in controls for how someone can change an environment with massive guard rails that prevent anyone from breaking the build and dead-simple deployment was made with enterprise-scale deployments in mind, but it's hard to imagine something easier for people to engage with for hobbyists.

The downside is if the company ever went out of business they'd take your entire game with it, and it probably wouldn't be free to use. Still, some of the ideas from it might be worth trying to adapt into other languages.

@Griatch said in Getting Young Blood Into MU*'ing:

Could you elaborate on what you think should work differently (apart from adding a RESTful API as a new input in the first place)?
.
Griatch

What I was more thinking about was the response rather than the request, if that makes sense. Evennia does support using input_funcs out of the box to call commands: but those commands do not currently have a generalized way set up to generate a response afaik, it assumes that the only meaningful output needs to take place in-game. If we're assuming that the text response is just one type of View, that's not necessarily the case - we want any sort of action to generate some sort of JSON response which we'd pass along to wherever. So what I was picturing was commands calling methods in objects that'd return some dict-like structure that could be converted to JSON for web responses, though you could do the same thing with commands directly as well.

@Griatch said in Getting Young Blood Into MU*'ing:

Ditching Commands altogether is not a self-goal in my opinion however. Commands remain in use (also outside of MU*) because they are highly efficient ways to tell the computer (game) what to do. Some things can be offloaded to buttons in a GUI, and that could get you some part of the way, but only for very simple inputs without arguments. Trying to replicate complex command functionality with a GUI will quickly build up complexity in that domain instead.

I'd agree with this, but I think what might be a good evolution in the far future is to make commands into very thin text interfaces for model methods/utility function calls, which would then be accessible by web interfaces. Text commands are largely analogous to text-based Views that perform some task and output text, and ideally they'd be solely responsible for validating input and presenting text output, where all the real meat of what's being accomplished is handled elsewhere and could be called independently by whatever - text commands, web views, RESTful API calls, celery tasks, scripts, etc. You could even have shared validation by using serializers/forms in both for a very DRY approach, but would sadly greatly increase the barrier to entry.

@Griatch said in Getting Young Blood Into MU*'ing:

I think there are a lot of improvements that could be done here (certainly on the part of Evennia). But I also think that there is a limit to how much a game engine can help you ('you' in the general sense, not you in particular). We are not anywhere near said limit yet, mind you. But I don't think it's realistic for people to expect to be able to run a multiplayer MMO from scratch without having any technical skills or willingness to pick up such skills. "Just" being creative is all fine and dandy if you have someone else doing the coding, but if you are setting out to make a game on your own you must be expected to actually learn the craft, IMO.
.
Griatch

I think the willingness will usually be there if the barrier to entry is low enough. One thing that struck me recently is an informal poll of web developers that showed a pretty significant number of them got their start by modifying html in Neopets or similar games. The key there, to me, is "modifying" - adoption is far higher if they can easily find existing code and change it to produce a result rather than try to create something from scratch.

For example, in Evennia, you currently generate typeclasses that are stub child classes of Evennia's parent classes. You could do the same thing with commands, and have docstrings in the modules that either contain or link to tutorials on where to find the parent classes and how to modify/replace their code in the children in their game directories. Parent classes that are used by default when generating the gamedirs could also be based on prompted values during initial setup: based on their choices, you use one contrib or another. I'm a little ambivalent there: copy and pasting the code in its entirety would probably be easier on people than dealing with inheritance, but would also mean they'd get completely out of date from upstream changes in Evennia. Maybe explicit super() calls with comments that always explain what that means?