Is it a good idea to talk about game plans now?
Thursday, April 12, 2012 - 01:25
Hello,
Is it a good idea to start talking about our game plans? I don't know if we should keep our ideas to ourselves or discuss them. I already have some ideas of what I want to work on, and it's always fun to see what others are planning on doing too.
I've seen that if you talk about game plans, you can get great ideas. For example, I talked about doing an HTML5 game like BrowserQuest, and Bart mentioned that since BrowserQuest itself is open source, I could use it as starter code.
HTML5 Canvas Old School RPG
Ah, yeah, that is a good point. I was thinking of a multiplayer capture-the-flag kind of game, but with programmable bots playing as well as human players. So part of the challenge is good old fashioned melee fighting action, and the other is tweaking the library of scripts of your robot army's code for the best fighting unit. The tricky part is making appealing to coders and non-coders alike.
Edit: Here's my github repository for the project: https://github.com/Metalmeerkat/Facktor
Hey that sounds like a really fun game Metalmeerkat, am i picturing it right when i say you'll be controlling a 'leader' and all your units will work out what to do based on 'orders' from a script you've set them - like an archer might be told if it detects an enemy to keep a certain distance and fire it's ranged weapon while a knight would charge right in?
as a non-coder i'd say your best bet at making it non-coder friendly would be to use a layering system - let advanced users write (and upload) modules which do things like 'detect enemies' or 'formation charge' but make it so less-advanced users can simply join the modules together flowchart style in an internal system - so i drag in 'detect enemies' then link it to 'if health is over x%' then 'charge' or else 'flee' - that way a novice user will be able to have the same ability to make ideosyncratic armies and behaviours which suit their style of play without having to learn to code -who knows, maybe once they've got the hang of the game it'll inspire them to play around with some programming...
just a suggestion, i'm looking forward to trying out whatever you make regardless :)
That sounds really cool. You might like to consider creating a visual logic editor for the bots so that non-coders can use it.
You will have to "dumb down" the programming a bit, but I think if you use pretty icons and controls in the logic editor it will work really well.
Yeah, I plan to have the players do scripting on top of the existing AI system. There will be multiple squads for each player, each squad having it's own governing AI. The default would be to have some teams tweaked to be more aggressive and some more defensive. The idea being that players can modify, add to, or override the existing AI. For example of overriding, a player might use the code "override squad $red: stalk(who=player, method=defend)", and the squad with this code would follow the lead of the player instead of running off doing their own thing. An example of adding to the existing AI frameworks would be like "add point-of-interest quadrant(x=2, y=2)". The idea being that the player might spot an area of strategic importance that the default AI ignores, and this code would add to the decision making process of securing this. The nice thing is that once this code is in place, the player doesn't have to explicitly tell them to leave or stay, the AI is still free to decide if something like defending the home base under attack is higher priority. In other words, the player doesn't have to micromanage everything.
These are more of simple commands. A more complicated example is to surround a weakened enemy. Like this psuedocode "groups = partition(who=squad $red, how=[0.75, 0.25]); for i in groups(1): i.stalk(who=enemy, method=passive_aggressive); for i in groups(2): stalk(who=enemy, offset=pathfind(start=enemy, finish=enemy.base).steps(5), method:aggressive)". The gist is that 3/4s of the squad randomly go around the enemy, and the other 1/4 tries to get between the enemy and the shortest path to the opposing base, in order to cut them off. And this code could be put in a function that's triggered when a large friendly squad detects a lonely smaller enemy squad. All the things like how to stalk a position or player, how to find paths, etc are left to the underlying AI machine, so the player is free to work with higher level concepts without worrying about the lower level implementation. So the point is to allow a very easy learning curve so non coders can use it with great effect, but be very flexible and extensible for coders to improve upon. Something like "add point-of-interest quadrant(x=2, y=2)" is something a non-coding gamer could figure out how to use easily.
I plan on the default implementation to be that the bots have two primary decision trees. The first one is a global decision tree shared amongst a squad that governs over direction and behavior. For example, determining how to go through the overall map, whether or not to retreat to defend home base, stuff like that. The second tree is local and per bot, determining how to respond to immediate threats, how to transverse with the local terrain, and how to handle events like friendly bots dying. The previous example commands would be to add nodes, modify nodes, or remove nodes. Stalking the player would remove all global tree nodes and add a node for following the player, while the local tree would just be slightly modified for defending the current position (ie changing the node weights). Something like adding points of interest would just add an extra node to the global decision tree, that's pretty straight forward.