Navigation
User login
Upcoming events
Recent Events
- 43 weeks 2 days ago
- 46 weeks 1 day ago
- 1 year 3 weeks ago
- 1 year 5 weeks ago
- 1 year 5 weeks ago
Newest Games
Search
Who's online
CAoleslaw 0.01, no fun at all
this is so much a work in progress it's not even funny, or fun.
So one year "rince"'s entry in the Obfuscated C Contest (I'm not your damn Google, but see http://www.ioccc.org/1993/ , the "rince" files) was a program called CABBAGE, Cellular Automata Based, Beautifully Abysmal Game Environment. I'm taking an inspiration but not an implementation (on any level, and probably losing most of the elegance) from him and trying to do something similar in java. If it works you can share really lame games just by cutting and pasting strings and I have all sorts of weird debugger ideas in mind but right now it's just a heap of Java bleh. Download and fire up processing if you want to see it; I'm posting it here to try to kick my butt into finishing it, and so I can download the file instead of having to carry it around with me when I do want to work on it.
| Attachment | Size |
|---|---|
| CAolslaw.pde_.txt | 4.68 KB |
Comments
Aww, it doesn't do 3x3->3x3
Aww, it doesn't do 3x3->3x3 transitions. You should make it do 3x3->3x3 transitions.
Are you planning on adding a proper editing interface to this?
Also, you should have random number events in addition to keypress events. User-definable events might be nice, too -- I'm imagining implementing Pac-Man with scoring, and without that, you'd basically need to add "score guns". Which would actually be a neat effect, if a colossal pain in the ass to implement.
wow, you actually went ahead
wow, you actually went ahead with playing that??
I am planning to do an editor and all.
I was toying about an almost KotM use of A B C variables that can be incremented and decremented.
For the 3x3; I'm tempted, but am concerned that execution order, how I iterate over rows and columns seems so important, and that if I go with my plan of using a buffer you can get "unexpected" and ultimately unworkable results,
Mostly I just looked at the
Mostly I just looked at the source. But yeah, my frothing demand increases.
For variables, I really think it would be cooler if all the state were visible, and you had to set up rube goldberg contraptions to increment numbers on the screen and stuff.
Mark my words: The difference between 3x3 -> 1x1 and 3x3 -> 3x3 will be the difference between farting-in-an-elevator awkward and having-unprotected-sex-with-a-sheep-in-front-of-a-packed-football-stadium awkward. I guess it'd only work right if you double-buffered, though.
Also you should get to draw little graphics to stand in place of the ascii characters, maybe. Maybe not. I'm just dreamin', here.
I think a buffer makes it
I think a buffer makes it easier to 3->1 and harder to do 3->3. With no buffer, it is what is, each square knows its environment right now, but you get weird side effects like something able to zip all the way across the world in a single turn as each set is evaluated in sequence. WIth a buffer, though, you get something more like "race" conditions...
Not sure about graphics. Maybe color blocks though? But I like ASCII, just because of the nethack connotation..
I've been thinking about
I've been thinking about this. You're probably right, 3->3 will be a lot more fun, just easier to get a grip on what the interactions are, visually, and you won't have to do 2 formal interactions for one "thing" (i.e. with 3 to 1 moving the player would be one interaction to remove the player from the old location, and then one saying the player is showing up in the new location)
The interesting thing, for both the coders in CAolelsaw and me as a metacoder, will be a step-by-step debugger. Two modes of step, actually: going through each square, and then going through each rule for each square.
Maybe there should be a boolean that says "stop evaluating rules for this square if this is a match".
one thing i want to keep thinking about is what characters are allowed; I might need to reserve some as wildcards, and others as some kind of delimiter. Having very robust "program listings", the strings that totally describe a game, is important to me; and I'd like not to use tab or return as a delimiter because of that.
Maybe there should be a
Maybe there should be a boolean that says "stop evaluating rules for this square if this is a match".
I wonder if this shouldn't be the default behaviour. Or else, "don't evaluate rules that would {modify | ask about} a character that has already changed"?
You definitely need to reserve a "don't care" character. (A "don't character", if you will.) User-defined wildcard groups would be pretty wicked, too.