FreeGameDev

Hi guys! My husband (cco3) and I are releasing the version 0.2-- code name Basil-- of our game Mutant Marionette, and we're hoping people here might be interested in playing (or helping with development).

Mutant Marionette is an RTS set in a post-apocolyptic environment. You control your swarm of mutants by programming small AI's in python. What distinguishes this game from similar programming games Battle Code, RoboCode, Infon Battle Arena, etc.) is that your character is persistent: you can get xp, level up, and earn new unit types. Currently, there are only two, but we plan on having a functionally diverse set of unit types, which will each warrant writing a new AI.

Our code is under the Apache v2.0 license, and the art is CC by 3.0.

While this project is still in its infant stages, our goal is that it will inspire programmers to hone their skills, and non-programmers to learn the basics of coding. We'll eventually write programming tutorials aimed at non-coders, explaining the basics of coding through our gameplay.

If that sounds like your kind of thing, we'd love it if you checked it out at http://www.mutantmarionette.com.

I've done a lot of game programming but I've never played programming games. I'll try and find the time to check it out :-)

Interesting project i'll try it tonight

The first thing I thought when reading about this was: "hm... user-uploaded creature sprites..."

... and now I have a quick idea how .. the strongest can be determined:
1. allow users to upload themes (all graphics need to be replaced)
2. display either random or default theme to each.. person (ip/24h?) loading http://www.mutantmarionette.com/
3. have a big 'change look' button at the top
4. if the player presses it, randomly change the theme
5. count amount of time spent with each theme and add the time to the theme's global rating

Sorry for going so off-topic..

Failed to make it work.
log.txt : http://pastebin.com/Ai9QL8M2
I used example code from the website in __init__.py
I did "marionette run . ." from within the folder.

Fatal error message like this should not be in the log, they should show in the terminal and stop the execution.

MCMic: thanks for trying it out!

First, you're right about the traceback that's printing in the log, that should be somewhere else. Second, when I ran the example __init__.py code from the website there *was* an error, but a different one than the one you got.
Line 5, "if self.inventory['grutonium'] > 0" should say "if self.inventory.get('grutonium', 0) > 0". Since your error was a generic "couldn't import Toad", this might fix your problem too.

If you need more help, we also hang out in #inkylabs on irc.freenode.net.

Hi MCMic, sorry about that. We'll update the docs tonight and let you know when it's fixed. (Also sorry that we've been busy and it's taking a couple of days...we are really excited that someone tried our game and want to fix everything for you, haha.)

Concerning the log visibility, I don't think it's quite as simple as "All fatal errors should be printed to the screen and stop execution". That makes sense when it's you playing against yourself, but what about when you are playing against someone else with bad code, or just playing a bunch of random people against eachother? To clarify, you can do `marionette run 1 2 3 4` where those values are user ids. The program check the website for git urls and then clone the other players.

I was thinking we could log to the terminal by default if the code is local (the argument is a file path as opposed to an id). Then, one could do --log 1,2 to turn on logging to the terminal for 1 and 2 or --nolog 3,4 to turn off logging to the terminal for 3 and 4. Do you think that sounds reasonable?

The documentation should be fixed. Basically, just don't use the "idle" action for now (we have fixed the issue and will make a bugfix release in the future).

I've also added a --log option that will be available in the future. If you are running code that you have locally, all the logging will be sent to the console. You can change the amount of logging for any player by doing --log 1:NONE,2:INFO which would be for user id 1, turn of logging to the console, for user id 2, log everything >= INFO to the console.

Does it work for you if you change your __init__.py to what is now listed at http://www.mutantmarionette.com/docs/intro/ ?

cco3 {l Wrote}:I was thinking we could log to the terminal by default if the code is local (the argument is a file path as opposed to an id). Then, one could do --log 1,2 to turn on logging to the terminal for 1 and 2 or --nolog 3,4 to turn off logging to the terminal for 3 and 4. Do you think that sounds reasonable?

Hum, I don't know, maybe a more simple solution like having "marionette" for real match and "marionette-test" for testing (or "marionnette --strict" for instance) would be simpler.

It still does not work.
See my init and log.txt:
http://pastebin.com/n65dppu5
http://pastebin.com/uturYw8Z

Hmm...that's surprising. What OS are you on? Maybe it's specific to the version of python or something.

Also, just to clarify, you have an __init__.py and a settings.json in the same directory and from within that directory you run `marionette run . .` correct?

cco3 {l Wrote}:Hmm...that's surprising. What OS are you on? Maybe it's specific to the version of python or something.

Also, just to clarify, you have an __init__.py and a settings.json in the same directory and from within that directory you run `marionette run . .` correct?

I use ArchLinux.
We've got python3 as "python" and python2 as "python2" commands.

I do exactly this, I attached the folder I use.

Ah, thanks. I've figured out the issue.

We import your directory like a typical python package so using the directory name "marionette" conflicts with the package "marionette".

If you rename your directory to something like "mycode" everything seems to run fine.

I'll come up with some fix for this that we can put in another release.

I don't think your code should have to check if the imported package is named "marrionette". I think it would suffice that you document that players should not name their ai packages marionette. Otherwise, you'd have to create similar methods for checking if built-in package names were used for ai package.

The fix I have in the works is creating a temporary directory with a safely named symlink that points to the users code directory. This would happen regardless of what the directory name is. The actual list of scenarios I'd have to document would be quite hairy.

* You can't name the directory the same as any module/package you have installed, including marionette
* You can't play two different directories against eachother that have the same name
* You can't name your directory u[0-9]+ (because that would interfere with the directories names used for syncing opponents code)

Clever. You could solve your second point by deriving the temp directory names by using the absolute paths of the imported packages. That is, if I am trying to play one bot, located in ~/bot against one named ~/marionette/bot, then they would be named "home_username_bot" and "home_username_marionette_bot" respectively.

Actually, I'd venture to guess it would solve all three cases. Just a thought.

This game looks like fun, but I stink at python.

aspidites {l Wrote}:Clever. You could solve your second point by deriving the temp directory names by using the absolute paths of the imported packages. That is, if I am trying to play one bot, located in ~/bot against one named ~/marionette/bot, then they would be named "home_username_bot" and "home_username_marionette_bot" respectively.

Actually, I'd venture to guess it would solve all three cases. Just a thought.

Yes, that would solve all 3 cases as long as none of the code directories are in the root path. I've already named the symlinks in the temp directory to "l" + userid. (If the user doesn't have an id, I make one, so there is no issue there).

ctdabomb {l Wrote}:This game looks like fun, but I stink at python.

The goal for the distant future is to have a really nice set of tutorials that teach you python through playing this game.

cco3 {l Wrote}:

ctdabomb {l Wrote}:This game looks like fun, but I stink at python.

The goal for the distant future is to have a really nice set of tutorials that teach you python through playing this game.

Then I hope time speeds up!