The scripting language defines the syntax and there are already plenty of good ones... but... the rest is specific to the game, the API, the "extensions" I add to the language, etc..  That stuff will certainly be worthy of all kinds of cheat sheets.

For example, here's a current snippet of my tree tools script:

Code:

...snip the other action definitions...

action( group:"Trees", name:"Tall Scrub Tree", type:ActionType.Block ) {

    console.echo( "Creating tree 3 at:" + it );
    if( it.side != Direction.UP ) {
        console.echo( "Trees must be placed on a vertical surface." );
        return;
    }

    loc = it.getBlock();
    
    factory = new ScrubTreeFactory2();
    factory.addTree( loc.x, loc.y, loc.z + 1, world, new Random() ); 
}

on( [playerJoined] ) {
    type, event ->

    println( "Adding tree tools to player:" + player );

    def refs = []

    ToolActions existing = player[ToolActions.class];
 
    if( playerData != null ) {          
        if( playerData.get( "grant.trees" ) != null ) {
            refs += actions.getRef( "Trees", "Simple Tree 1" );
            refs += actions.getRef( "Trees", "Simple Tree 2" );
            refs += actions.getRef( "Trees", "Maple Tree" );
            refs += actions.getRef( "Trees", "Tall Scrub Tree" );
            refs += actions.getRef( "Trees", "Clear Tree" );  
        }
    }            
    
    println "Refs:" + refs;
    
    player << new ToolActions(refs, existing)
}    

action()?  on()?  "playerJoined"?  ActionType what?  What are these things?  I'm sure there will be some cheat sheets someday.

Current plan is banning on server side.  And I've already included some tools along those lines that admins can use... this is already quite flexible, actually since nearly anything you want can be done with scripting.

There is no full-proof method for validating clients... there just can't be.  If the server requests some information then the client can be trained to return the right info.  You can make it harder but not impossible... and you turn it into a completely different game at that point.  In other words, now you are playing a "one up the cracker" game with some guy.  I have some ideas that make it harder to crack on a server by server basis but it used improperly by the admins may just escalate the game.

When you ban a user and they know it then you've turned it into a war.  They might have been annoying before but I think if they ever find a way into the server again then they will grief it on a massive scale.  So I try to concentrate on things like asymmetric banning where the player is effectively "nerfed" but would not obviously realize it.  And then being able to easily recover from their pre-nerf griefing.  So far this covers 99% of the worst cases so far.

...I do have an advantage now, though, since Mythruna is still pre-alpha, odd behavior looks like bugs and not the nerfing that it really is.

I've worked with large teams, participated in several open source project, and run four open source projects of my own... some of which actually have additional members.  Source code is managed generally through subversion and tasking can be managed through a wiki or more formally through an issue-tracker... casually through a mailing list, etc..  I don't even consider that stuff as part of the overhead.  The overhead is just in the technical exchange required to keep the source code from turning into a pile of unmaintainable garbage.

Right now, some of the code is ugly but does what it's supposed to and I fix it when I come back through.  I can rapid fire through features this way and then swing back and refactor later.  I couldn't do this on a team... I'd spend most of my time explaining stuff.

Heheh. 

Because for 20 years, ATI "hate on me!"

Yeah, I was mainly speaking syntactically.

Of your bullets, all will be possible... and hopefully some will be buildable by players in-game without scripting at all.  Of course, scripting is still an option.

Well, since I'm customizing the Groovy through operator overloading and clever mix-ins... perhaps when it's done we can say that it's "Mythruna-script (based on Groovy)".

Flipping this around the other way...

What features would you like to see in a scripting engine?  What is your motivation behind having me write a custom one for mythruna?

Just wait... groovy is very powerful.  I would never in my right mind write my own scripting language these days with all of the really excellent options out there... and groovy is so customizable that I can make it feel custom anyway.

To directly answer your post, selling+profit is the prerequisite for a company... even in your story.  No matter how many guy or guys there were.  But more on the underlying point...

I have a lot of experience managing teams and trying to work on them at the same time.  There is a lot of overhead involved.

Usually, if two developers are "made for each other", ie: they are just perfectly in sync somehow and can complete each others sentences then you can expect this to add about 10% overhead.  So, if I'm working on the game 25-30 hours per week then I will spend 2.5-3 hours of that coordinating work with someone else.  That presumes that I've already done about 80 hours of work properly laying out a design that we both can follow.

For most, that number would be closer to 30-50% of my time spent keeping the other developer productive and making sure their code wasn't breaking things and my code wasn't breaking their things, etc..

And that's just for one other dev... every additional dev adds another 10-20% until you have about 5 guys and I'm doing nothing but managing everyone else.  I don't really get to code at all anymore unless it's drilling into why something isn't working for someone.  Throughput has increased but now so has schedule.  For a big project, you gain a lot of positive "corporate-like" things like redundancy, not burning your people out, etc... but you generally _increase_ the length of the schedule by adding people.  The old saying about how "9 women can't have a baby in one month" isn't the whole story because 9 women also can't have 9 babies in 9 months... you'd have to find 9 pregnant women right off the bat.  Realistically, if you wanted 9 babies it would take you at least two years.  But I digress...

Right now, all of the systems are in partially built stages.  I can keep a lot in my head and leave comments for myself in the code so I sort of know where I'm going.  I also have a ton of design documents written "just for me" that I can pick up and know what I was thinking.  I can also change my mind and turn on a dime, refactoring entire sections if I choose.  For while I have lots of experience working in teams, I also know what works for me as a "cowboy coder" working on my own. 

There is a point 'real soon now', where these systems start to come together in a way that I could let other people work on them without issue... but that is also the point where they are ready for some published modding specs.

And there is also the issue that I can't afford to pay anyone or promise anything to anyone who contributes (having a company is also the prerequisite to promises by the way)... and voluntary contributions are awesome but can't be counted on in any way.  Life overtakes someone or the wrong word is said in a heated design discussion and suddenly motivation/time dries up and I'm left to start a piece over from scratch.  There is considerable risk for me here, especially considering the overhead costs mentioned above.

I super appreciate all of the offers.  I honestly do.  It's actually one of the things that keeps me going... knowing all of you who believe so much in the game that you want to help.  I just feel like I'm not in a position to field them properly at this point.

Currently, I feel like my best plan is to keep knocking the critical or risky systems down until I have something solid.  I'm in a better position to accept help at that point... and not coincidentally, that's also when the modding support will be pretty well fleshed out and I will feel really comfortable talking about "what's next" because the risky systems have been completed. 

I hope that all of you who are eager to help will take that as an opportunity to build cool things.  That's also when I switch from full-on, head-down development mode, to creating an official online presence for the game and really trying to get the word out.

Man... sorry to ramble on so long.  I hope I didn't upset anyone.

Company comes before revenue.  Revenue comes before team.  At least in the formal sense.

Heheh... I'm not going to write my own when there is a perfectly awesome one (groovy) already written that lets me tweak it to feel like my own.

Thought I'd post this here, too...

This is the photoshop mock-up of the property management UI:
http://www.facebook.com/Mythruna#!/photo.php?fbid=263407133681812&set=a.218418391514020.54331.204533646235828&type=1&theater

Not sure how much will survive when converted to a real user interface but I thought it might be interesting to some of you.

Heheheh.  Well, hopefully you'll be letting NPCs build some things by that point so you can earn some gold from your townspeople. 

Yeah, it's trademark that I'd have to worry about re: the name.  And really, since it's a word I completely made up and had 0 google hits prior to my securing the name, another company would have trouble sniping it.

Registering a trademark is not free and will come after I setup the company... as I'll need to trademark the company name as well.  But these become assets and I'd rather park them with the company than myself.

Mythruna can use any JSR-223 compatible scripting engine but the extra API goodies I've been writing have all been in Groovy.  It's a very nice scripting language especially for us Java folks.

According to google, there is a JSR-223 compatible lua binding but it uses native code so may have some overhead.  I mean, any scripting language is going to have overhead so that doesn't worry me but one of the nice things about lua on the C side is how fast it is but called from Java it's probably on relatively level footing with something like JavaScript or Groovy.

I like Groovy because I can redefine some language elements to make it easier to do certain things... ie: customize the language a little.  And because it's essentially Java otherwise it is easy for me to learn.