The next time anyone bitches about lack of documentation for Arx I'll threaten to hire Chet to write it all.
Posts made by Tehom
-
RE: Mercenary Entrepreneurship
-
RE: Need Python Code Projects
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.
-
RE: Hello!Project's Mysterious Game Project Thread
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.
-
RE: Getting Young Blood Into MU*'ing
@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.
-
RE: Getting Young Blood Into MU*'ing
@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.
-
RE: 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.
-
RE: Getting Young Blood Into MU*'ing
@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)?
.
GriatchWhat 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.
-
RE: Getting Young Blood Into MU*'ing
@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.
-
RE: Getting Young Blood Into MU*'ing
@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.
.
GriatchI 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?
-
RE: Getting Young Blood Into MU*'ing
@Griatch said in Getting Young Blood Into MU*'ing:
I'm not sure a single killer-game is something realistic to achieve, at least not one decided on-by-committe. But I do think that breaking out of the legacy command syntaxes, making sure to always have proper tutorials and offering more quality-of-life features specifically aimed at newbs would go a long way, regardless of genre. Maybe one could make a framework for this that people could easily plug in and fill with their game-specific info. It's something I could probably add to (in my case) Evennia with relative ease, coming to think of it.
.
GriatchI have a few things on my wishlist for the far off future.
I would love to have something sort of similar to django-cookiecutter but for game templates out of the box, but even more accessible than that: some sort of wizard where someone who has absolutely no programming experience could enter a bunch of values to customize a game experience out of the box. Ideally we'd configure their settings file for them, then apply some fixture or database seed values for a game genre, and then the rest is up to them. For example, selecting 'medieval fantasy game' might add a 'contribs.fantasy_template' to INSTALLED_APPS which would more or less be what Ainneve is supposed to be, automatically adding relevant commands, etc.
I think the biggest hurdles coming into this hobby are getting started as a game-runner and getting past the text-based interface for a player. Ares is making great strides with both areas. I think it's unfortunately very rare for most people who want to make a game to have both boundless motivation to do both heavy lifting of creative writing work and want to tinker with deployment/configuration/coding on the technical side. Anything that makes either area easier probably would increase adoption proportionally to how painless they are, imo.
-
RE: The Work Thread
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.
-
RE: The Esports thread
My best was barely scraping into plat 5 for two seasons, but I haven't played much in years. I'd be really lucky to be able to hit silver now, I think.
-
RE: The Esports thread
LCS fan here. I've watched League of Legends from the start, which means I'm a long-suffering fan of North American teams even while we're consistently dumpstered by every other region. God I hope TSM can get it together before playoffs. Missing worlds last year was terrible, and it feels like they're imploding again - even Bjergsen isn't playing great, and that's pretty worrying when he's been the only consistent performer on the team for years.
-
RE: A fully OC supers MU
@Atomic said in A fully OC supers MU:
I am presently learning python for work, but just getting started. Long term, Evennia will probably work for me, if I can find a python coder to carry me until I can make things and not break everything.
To stick with M&M as the system, I'll have to generate a die roller, charsheets, chargen, and point trackers. I'm guessing most of the standard utilities are repo'd out there somewhere.
If you decide to go with Evennia, they have a pretty lively IRC that's connected to a Discord channel, and people are usually pretty fast to answer questions. I'm also happy to help with questions about python/django if you're stuck on how to implement or fix something - I can be reached either by messaging here or on Discord (I'd show up in the mods list of the Evennia discord channel).
-
RE: Meg's Playlist
@Meg said in Meg's Playlist:
it was short, i'm back. doing much better. udated; hmu if you wanna chat.
Welcome back!
-
RE: Accounting for gender imbalances
@Sparks said in Accounting for gender imbalances:
Putting on my "hi I have hiring responsibilities" hat, I can say that while a sizable gap in work history would earn a raised eyebrow from me, that's easily made up for—at least to me—if you have side projects out there you can point to. Especially side-projects that are open source and on Github. I love those! Please include things on Github in your resume! Then I can see your coding style! I can see if your commits are nicely separated into bite-size updates or if you have giant commits touching the entire code tree at once encompassing like two weeks of work! (Why do people do this?? That's not how source control is supposed to work! It wasn't how it was supposed to work even before git's distributed model!)
I feel so called out right now for --squashing my commits.
-
RE: Meg's Playlist
@Meg You'll be missed. I'm wishing you the best and hope things get better for you.