Better define project goals

[traverseda]

I'd like to get into what goals people have for this project a bit more.

I'd like to see this project ultimately end up being the "django" for voxel/roguelike/tile games.

I'd like it if there was only one real client, and most of the customization happened "server"-side. In the backend, whether that's network transparent or not. I think asking people to do graphics programming to make a game is asking too much. They should be able to ignore most of that, and focus on gameplay.

I'd like to look into gurps for ideas on how our default world fundamentally works. How to handle hitpoints, stamina, etc. It has a proven record of letting multiple settings work well together.

I want people to be able to implement things like dwarf fortress. Incredibly realized worlds with amazing depth.

I'd like it if eventually we got to the point were you could do something like

INSTALLED_APPS = [
    'base',
    'base_worldgen',
    'cyberpunk',
    'spellwords',
    'fantasy_races',
    'industrial_cities',
]

To get something like the shadowrun campaign settings. Or any other combination. Find the medieval base, add in steampunk. Whatever.

If I had to shorten my vision, I'd say that we need to enable fully-realized worlds, and make it easy for people to mix and match them.

---

But I'd like to hear what other people want to get out of the project as well. That's only one approach.

[agentultra]

Neat idea!

I think it would be implementable with some compromises/clarification.

The concept of an "app" in this sense, I think, would be a convention for a path layout with data, textures, sounds, etc. Since Python doesn't have strong/any sandboxing capabilities it would be best to avoid asking users to run untrusted code on their servers. We can get enough behaviour out of data to make it something akin to writing a GURPS module.

The Simulation instance loads all of the defined data in "INSTALLED_APPS" and starts ticking updates. The Server component manages client sessions, batches updates, sends inputs, and (de)serializes data over the wire.

I assume that the Client will have to make an initial connection to a server in order to get the data needed to render the simulation, negotiate protocol issues, etc. Then it sets up its snd/rcv sockets and does whatever it wants as long as it speaks the protocol. (ie: ASCII clients? DX12 client? etc).

[traverseda]

The concept of an "app" in this sense, I think, would be a convention for a path layout with data, textures, sounds, etc.

Data only mods/apps might be reasonable, but people already run "untrusted" code on their minecraft servers, and their django servers even. I'm not sure how much of a concern it is.

The bigger concern is untrusted code in the client, and that's where need need to keep things as declarative as possible.

[agentultra]

People run untrusted code on Minecraft servers because that's the only option to mod it, no? Besides it's much easier to sandbox the JVM than Python and not reviewing the source to every mod you install means you'd be risking some module calling:

os.unlink('/')

I'm not sure how risk-averse people are to that sort of thing but it's a possibility in Python and I've never seen a managed interpreter that performs well and still catches everything. It might not be a concern here but I bring it up because it might prevent people from being able to host this in certain situations.

The other concern is constraining run-time performance. How would the Server respond to a callback taking 2s to update? 3? What if the user installs 20 modules, each only taking 0.3s in total for all the callbacks they hook into? Is the Simulation in the correct state if we skip a callback that takes longer than X us? Data-only mods can give us plenty of flexibility but would skirt complex scheduling issues like this.

On the other hand if users realize that 'more mods = lower fps' they might be fine with making the trade-offs themselves.

A fully "dumb" client that just runs shaders and possibly some user-defined scripts for modifying UI is great.

[PythonJedi]

I'd like to point out Greenspun's tenth rule of programming:

Any sufficiently complex program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of common lisp.

Even if we were to only allow 'data only' apps, the kind of data required to create new worlds and creatures would end up forming a programming language anyways, but in that case, our configuration/app loading software is its interpreter. Given the choice between some ad-hoc python implementation of a language and the official python interpreter, I'd much rather use the latter.

To combat running arbitrary code, having a repository of 'verified' apps that can be installed via something equivalent to a package manager can be put in place. For an example, look up void-packages here on github. That's an entire linux distro's package collection handled by a git repository. There are a half-dozen senior developers that authorize packages to be included, but anyone can package and submit PRs for review. I think such a mechanism could work for pycraft as well, once the concept of app or package has meaning for pycraft.

As for my thoughts on what I'd like to see pycraft become, I absolutely stand behind that idea of avoiding graphics programming to make games. I want to make explicit the potential implied idea that pycraft should make as few assumptions as possible about what game is being played on it. For instance, the assumption that the world consists of sectors that contain blocks is fine, because pycraft is a voxel engine. Assuming that the particular block 'Stone' exists, or what its durability is, or even the concept of durability is less desirable.

The game creators are going to be creating universes that follow arbitrary rules. The more arbitrary we can make the rules, the more vibrant and diverse the ecosystem that develops around pycraft.