Multiplayer online programming game

Started by
6 comments, last by swiftcoder 13 years, 6 months ago
gr1d.org

Following in the tradition of Robocode CoreWars etc, and attempting to combine elements of d&d, MtG and planetarion-like games, gr1d.org is a persistent multiplayer online programming game, designed to be fun for professional, hobbyist and student programmers. (more)

gr1d.org is a browser game, in which the goal is to amass the most resources (gr1d nodes). Players take on the persona (rpg-style classes) of a futuristic cyberspace user, and spend their time coding and releasing their agents into The Gr1d.

Agents

These agents are written in any .NET CLR compatible language that can create static types that implement an interface (excludes Iron* for the time being)
Agents act as intelligent creatures, which are able to claim gr1d resources and enter into combat. The number of programs is based on the character’s level and the variety of actions they can perform is based on skills

Players

Players can directly claim resources from the gr1d, or raid them from each other. Players can also defend other players or sectors of the gr1d. Players can create clans which let them share code and write collaborative agents to attack juicy targets

Players are isolated into different sectors of the gr1d, and receive defensive bonuses for defending neighbours, to encourage natural formation of alliances

Feedback

The game is far from finished and I’m seeking some critique on the concept (a game where you have to program?), or even some limited play-testing for any developers amongst you (I’ve scored 2 complete strangers who are giving great feedback, but the more the merrier)

In particular:

Target market – it’s very niche, can it get enough players?

Endgame – I’m considering making it “round based” where people sign up for a round of play, and the winner of the round (most resources at 12pm on the DD of the MM yyyy). Do "round based" games work well? What are the common challenges with them?

This has the potential to be turned into a business model one day, where people pay a nominal amount for a round, and the winner gets an actual prize (ipad?) while the difference is left to run the hardware or reinvest in the business

Place – geographic location currently serves as a player attribute, and affects how much warning other players get of pending raids your launch on them. It also attempts to group players into neighbourhoods. Could/should place be used for something else?

Thanks,

The gr1d.org development team
Advertisement
I see two major problems right off the bat:

1) Malicious Code:
If players are able to upload their own .net code, then it will be possible for someone to write malicious code that could infiect your's or other player's computers with malware.

2) Coding:
If I am going to sit down and write sophisiticated AI code, then I probably will do it for a job and not want to have to do it for fun too.

A solution to both these problems is to change the way players code the AIs. As the game is supposed to be set in the future then it also makes sense to change the coding interface as well.

There is an opensource project called: RoboShips ( http://roboships.sourceforge.net/ ) that uses a drag and drop coding interface. The code you can make this this system is just as sophisiticated as you can do with a source code interface, but it is much easier to understand (and thus more accessable) and it allows you more control over the security of any code written.

The way you can impliment this in your game code is each program is a linked list of Command Objects, where each object in the list is a program instruction which links to 1 or more (for branching statements like if/then/else commands) Command Objects. The code excecute the "code" from the current Command Object and then passes on to the next command object in the linked list.

If you incude a Command Object that is a container for a Command Object linked list, then you can include functions and such that allow player to encode and encapsulate more complex functionality (and players can trade these Command Object Containers allowing greater player interactions).
Thanks Edtharan. Number 1 is a massive risk, number one in the design document. In theory .net or java both provide functionality to make this 'safe' but I do unfortunately forsee that it will be an ongoing war between game coders, and those that want to do harm. Hopefully we win the war, but I don't expect us to win all the battles.

Number 2 is close to my concerns about it being too niche. We have two enthusiastic players from off the street who seem to enjoy it, I do wonder how rare those people are.

Thanks for your feedback!
Quote:Original post by gr1d
Thanks Edtharan. Number 1 is a massive risk, number one in the design document. In theory .net or java both provide functionality to make this 'safe' but I do unfortunately forsee that it will be an ongoing war between game coders, and those that want to do harm. Hopefully we win the war, but I don't expect us to win all the battles.


Keep it very simple - create your own scripting language, one that can be written in using drag and drop of blocks.

The reason for this is twofold:

1) Makes it easier to play - you don't have to be a coder, just merely interested(Could get people in year 8 playing!).

2) There is an absolute ton of stuff to do, not just to make the code secure, but give it equal processing time etc.

You either get a good language and cut it down to nothing, or you start simple and build a customized one that fits your needs perfectly.
Why not just use a sandbox scripting languages like &#106avascript or Lua?
Thanks to all for your feedback!

Quote:Original post by Edtharan
If you incude a Command Object that is a container for a Command Object linked list, then you can include functions and such that allow player to encode and encapsulate more complex functionality (and players can trade these Command Object Containers allowing greater player interactions).


I like your thinking - there are heaps of opportunities for crafting and trading. There are challenges around managing the fact that tradeables can't be locked "in game", as a good algorithm is privately transferable via e-mail, or publishable in a blog post. This is addressed in the design document, which mentions "leasing" craftables to people to give the player an in-game incentive for not publishing too much awesome code, and possible ongoing evolutionary changes to the game mechanics to make the "uber agent" quicly redundant

Quote:Original post by NPSF3000
1) Makes it easier to play - you don't have to be a coder, just merely interested(Could get people in year 8 playing!).


We want people to have to be coders! This has obvious cons around the size of the possible player base and general accessibility, but also some non-obvious benefits, lots of OOC reasons to communicate and collaborate, perhaps the Python players will form a clan and tease the c# players, etc, and the bonding experience of joining quite an elitist environment.

Quote:Original post by NPSF3000
2) There is an absolute ton of stuff to do, not just to make the code secure, but give it equal processing time etc.

You either get a good language and cut it down to nothing, or you start simple and build a customized one that fits your needs perfectly.


This was a really key decision we made upfront, and is a tough one and possibly a line call.

The challenges in a custom language are in terms of security (odd parser bugs, encoding challenges, etc), and possibly more complex in terms of scheduling processing time etc as we would need to roll all this stuff ourselves.

At least with mainstream tools we're able to call API calls like GetThreadTimes, differentiate between kernerl and user mode time, use threading primatives and have platform support for sandboxing and different trust levels - and there are two good open source implementations to look at, such as Robocode and .NET Terrarium, which have both addressed these issues.

With a custom language we also need to create tools/editors that support things like intellisense, autocomplete, syntax highlighting and the like.

Quote:Original post by adrix89
Why not just use a sandbox scripting languages like &#106avascript or Lua?


This is possibly the best technical solution, as tools, parsing etc are all looked after. However I think rightly or wrongly the decision to use either a .NET CLR language or support a variety of JVM languages was a given, as I think there is something almost magical about supporting multiple languages and a heap of OOC opportunities for discussion to help build community. .NET seemed easier than JVM languages and is quite accessible these days via mono.

Aside from implementation details, are there any thoughts on the actual viability of the concept, or on possible ways to market and recruit play-testers? We have a fairly stable experience for people in production, and are looking to iron out usability and balance issues.

[Edited by - gr1d on October 19, 2010 3:36:54 AM]
Quote:Original post by gr1d

With a custom language we also need to create tools/editors that support things like intellisense, autocomplete, syntax highlighting and the like.


Would you?

If your going after some pretty hard core programmers (people who know their stuff and want to spend their free time on it) you could leave much of this up o the diffrent 'factions'.

However you do it, try to keep it fun and unusual - don't reproduce real programming.
Quote:Original post by gr1d
With a custom language we also need to create tools/editors that support things like intellisense, autocomplete, syntax highlighting and the like.
The number of 'hackers' who would be seen dead with intellisense/autocomplete is surprisingly small. If you are going after hard-core programmers as your target market, then you are targetting the vim/emacs crowd, not the Visual Studio crowd [wink]

Random notes: You need to invest in some AJAX, so that the skill-points screen doesn't refresh after every button press.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

This topic is closed to new replies.

Advertisement