I've been looking for something like the game that is described in the post for awhile. The kind of complexity that comes out of having N different damage types and M arbitrary, incompatible equipment slots is fun, but it's not nearly as intellectually rewarding as the complexity that comes out of simple rulesets like Newtonian Physics, programming, or genetic algorithms. Some use of GAs was attempted by Lord British with Ultima MMO games.
Yes, of course. Actually, I'm planning on people running into problems like these. The "VM" (in quotes because it's very loosely a "VM") the user-written scripts will run is also the same one running the monster AIs. Pieces of user-written scripts will mysteriously find their way into the gene pool! ;)
The whole point is to have a world of chaotically produced djinns whose aims are not yours, produced by a force you can't control and not meant to be easily comprehended by human brains!
An alternative view of the lesswrong essay is given criteria A B and C and you only pay attention to the simple obvious A, once A meets some kind of obvious engineering limit, the other criteria (which might be totally surprising) become the dominant selection critera. And that might make an interesting game mechanic. Once the hunters reach some engineering maxima of hunting, they will end up being selected for something else. Awesomeness or who knows.
This is interesting. Seems we've found another way to crash the server!
EDIT: We will have fun looking at the logs tonight.
EDIT: Found it already. Doh! I need to use a channel for the chat 'outbox'. Chat will crash the server!
EDIT: Have chat disabled for now. NOW let's see you crash it! :)
EDIT: Smartasses! Okay, I'll have to figure this out now.
2014/06/03 16:51:32 http: TLS handshake error from 208.90.57.196:48955: tls: unsupported SSLv2 handshake received
2014/06/03 17:04:18 http: TLS handshake error from 54.80.180.161:54227: tls: unsupported SSLv2 handshake received
EDIT: And, it would seem some enterprising fuzzer has found yet another way of freezing up my server. I should have that fixed in a day or two. (So thanks again!)
What a super nice idea! I love it how you've thrown all these elements into one pot, lit the stove and let the 'market' solve the harder problems. Elegance!
No implementation problem. Right now, only ~80x24 grids are life grids, and they aren't yet connected. I am planning to implement a "Life Field Emitter" which will give you a ~240x75 area for your Life formations. That should be enough space for interesting formations, but this will prevent infinitely growing formations from crashing my server.
>> No implementation problem. Right now, only ~80x24 grids are life grids, and they aren't yet connected.
> That is disappointing.
Okay, I feel like this is some weird negative spin here. You will be able to have as large a finite area as you want. A single "life field generator" will support ~240x75. You will be able to have as many "life field generators" as you want. You will have to invest in in-game resources, though. It won't be pay to win. But it will serve to throttle the number of occupied grids.
"As large as you care to have" is fine and generous, I think. If you want "effectively and effortlessly infinite," I'll just leave that for someone else to pay for the server time.
> I think you could find other, more creative, ways to prevent infinitely growing formations from crashing the server.
Hey if you want to volunteer an implementation in Go, this is well travelled territory. You can look those algorithms up and implement them yourself. That's not my main focus, so I'll not spend the time right now. As for a game world, it's fine to let people mine resources and stake out as large a region as they care to. I'm going to do a Life-world sort of as an art project/portfolio piece. The Ultimate Shared Life World is just not my present goal. But who knows? We'll see where this leads.
> Okay, I feel like this is some weird negative spin here. You will be able to have as large a finite area as you want. A single "life field generator" will support ~240x75. You will be able to have as many "life field generators" as you want. You will have to invest in in-game resources, though. It won't be pay to win. But it will serve to throttle the number of occupied grids.
So with multiple LFGs you can create a larger linked active area? If so, color me no longer disappointed.
> Hey if you want to volunteer an implementation in Go, this is well travelled territory. You can look those algorithms up and implement them yourself.
I have been planning on doing just that (not in Go though). I want to play around with updating each cell on an as needed basis (e.g. cell at time T only needs it's neighbors to have been updated to T-1, and their neighbors only need to have been updated to T-2) and then making that outwards sandpiling of update-ticks a commodity/game mechanic in the game. Perhaps something similar to your LFG, but instead of enabling a fixed neighborhood size, it would simply push out update-ticks at an established rate to limit processing load.
EDIT: DDOS has ended now. Apparently my server stops out at ~150 players in a single grid. (Though I have an idea why, and know how to make that number much larger.)
EDIT: I think there's a different DDOS happening now.
Thanks. I've been wondering recently if I shouldn't just make an MMO game entirely based on Conway's Life. Most of the maze would be gone, and you'd mine resources in order to be able to form the Conway Life patterns and make yourself a comfortable home.
Generally, it runs into problems like these:
http://lesswrong.com/lw/l8/conjuring_an_evolution_to_serve_y...