Real Robots Live - multiplayer real life robotics game - call for ideas

FIRST General Forum
#1

Hi guys,

Just wanted to make you all aware of a new project, and gather your ideas.
The project is called Real Robots Live and will make it possible to log onto a live robot over the internet and drive it around a remote arena.
You’ll have full control over the robot via the software and will be able to see the camera images that stream from the robot’s perspective. It’s a high res, low latency feed on the robots and around the arena.
Lots of these robots will be playing in the same arena - a real life online multiplayer game!
We want robots to be able to construct structures, destroy them using weapons and interact with the arena (opening doors,etc.).
Once online, we want to setup RealRobotsLiveTV so everyone can watch live events.

This is a call for ideas. This is a game with the real world as it’s engine. What would you like to see in this?

Check out our videos: website
Follow us on twitter and
facebook

In 2-3 months we are aiming to crowdfund the project.

Cheers,
Lewis

#2

How will you handle the case where number of users >> number of robots? It seems incredibly possible for there to be at least 10x more users than robots. How will you attract and keep me engaged as a user when I have to wait hours for a 10 minute time slot?

#3

Hey,

Thanks for the reply.
Well originally this could occur, so we want to create live stream for others to watch the gameplay unfold.
With the demand we will do our best to build more arenas so more people can play. We’ll also geographically locate these so latency is minimized.

What features do you think would be really cool on this game?

Lewis

#4

You could use quadcopters/tricopters as 3rd person cameras.

How varied would the robots be?

Is it PvP? Cooperative?

#5

Cool! Drones are definitely something we could work into the game.

Well each robot could have a specialism such as speed, maneuverability, additional servos to pick things up and construct things. What types of robot would you like to see?

Games will be both PvP and cooperative, different slots will be different game types.

Thanks for the response.
Lewis

#6

This is one of those things where the dream version is absolutely amazing, but reality tends to get in the way. I hope this works out, and have a couple thoughts off the top of my head. I will use some references to games, as that is what this is.

  • How are you funding this? It will only get more expensive to maintain and grow this as it goes forward, and with good design/everything else, you could easily get more traffic / demand than you can pay for.
  • You probably will want to monetize somehow, but in a way that doesn’t drive away your playerbase. This is very hard to, and bad pay-models have killed many games and projects. Cosmetics are pretty safe: “$20 gets you a golden robot” is less alienating than “$20 wins you ever match”
  • How many people do you have onboard? Do you have advertising and PR? Do you anyone with game design experience?
  • Consider the comparative complexities of MOBA type games and FIRST games. Dota 2 has >140 items, >110 heroes, different jungle camps, scaling creeps, roshan, runes, towers, barracks, buyback, catch-up mechanics, a meta, hundreds of skills, multiple hero roles… an FRC game tends to have 1-3 game pieces and 1-5 scoring mechanics, but can get away with it due to the innovation in actually building the robots. Obviously your game will fall somewhere in the middle, but mechanics such as currency, upgrades, dynamic environments, non-player entities, and so on will up the ante in terms of strategy and player retention. No one would want to play remote Recycle Rush, for example.
  • Keep in mind various levels of play. Some people will want to hop on, drive a robot into some walls. Others might want to chat with teammates and try to win. Others still might want to form a team and compete in tournaments. Social features are what make multiplayer games successful; for proof, see WoW, Dota, League.
  • Larger robots could be controlled by multiple people - either “Star Trek” style, where each person does a different task, or “crowdsource” style, where everyone’s actions get averaged out. (The crowdsourced one will work better for robots that work over long periods of time, so that people can cooperate.
  • Quality over quantity with your game modes and robot types. I would rather have 5 interesting, solidly built robot types on 2 different maps than 10 trivially different robots on 20 trivially different maps.
  • Consider progression / stat tracking: people will want an account that allows them to queue with friends, keep track of scores, earn a reputation (see: Elo), and chat on forums.
  • If you want people to take it seriously and to have any significant player retention, there needs to be incentive to winning. Some examples, in particular order: Monetary; either real or in-game. Levels; you get access to new robots/loadouts/color schemes as you rank up. Ranking; Elo, MMR, division, etc. Cultural; make people want to win for the sake of winning and getting better (this one’s hard).
  • Community involvement is great. New robot / map contests, events, etc. keep people interested.
  • Consider carefully the scope of your games, especially the pvp ones. What are the win conditions? How many players per team, and how many teams? Do games take 10 minutes, or an hour, or 24 hours? Are the player’s social networks more like ‘stacks’ of 4-6 people, or clans of dozens? Do you expect players to play matches from start to finish, or will they be pickup style? These questions determine the “feel” of the game, and subsequently the behavior of your players. If you expect players to stay an entire game, and penalize them for leaving (CS:GO, MOBAs), the playerbase will take the game more seriously across the board and actually attempt to win. A pickup-style game will result in a TF2-esque situation where the vast majority of players are just messing around.
  • I mentioned it earlier, but generating a deep enough game to have a competitive scene would be AWESOME. Imagine, teams of 10 or so, 3 in a command bot and the other 7 in various types of smaller robots. Strategy, tactics, surprises, twists! I would watch this so hard.
  • You need to consider how you are going to deal with abuse. You will run into 2 types of abuse: reckless robot use and bad manners (often called BM). People WILL drive robots into walls, push arms on a weak axis, flip robots, etc. etc. They need to be very well built to not take damage despite 24:7 use. If a robot flips, will a person come right it? Does it get left there? Either way, the flow of the game gets interrupted. As for BM, what do you do if 3 people gang up on another and pin them in a corner? Will there be moderators, either staff or community? How do you prevent moderators abusing their power? What are the consequences for BM? (Examples: ban, low-priority queuing, time-out, mute, warning system)

Sorry if it is a little rambling. I’d be interested to hear your answers to any of these questions, and discuss them, but really I am suggesting these as things to consider long term as you build up the system of your game, as establishing yourself and keeping players onboard are something very few games succeed at.

#7

Wow thanks for contribution! You’ve given us a lot of good advice. The gameplay ideas were really useful.

How are you funding this? It will only get more expensive to maintain and grow this as it goes forward, and with good design/everything else, you could easily get more traffic / demand than you can pay for.

First of all the Kickstarter will help us build our first arena. From here we are contemplating a token based system, where the value of tokens will rise and fall with demand. If possible, we may operate of an advertisement model, and make play free. The advertisement would be on the live stream or in the arena (like a football match). We could also use in-app purchases similar to what you mentioned. What do you think is the best model?

How many people do you have onboard? Do you have advertising and PR? Do you anyone with game design experience?

Primarily it’s the 2 main inventors of the project, although we do have some media contacts. This is a big area of concern, we are launching Kickstarter in August and need all the help we can raising our profile.

What are the win conditions? How many players per team, and how many teams? Do games take 10 minutes, or an hour, or 24 hours? Are the player’s social networks more like ‘stacks’ of 4-6 people, or clans of dozens? Do you expect players to play matches from start to finish, or will they be pickup style?

Each game type will have a different win condition, we currently have Capture the Flag, Destroy and Conquer (biggest team score wins) and Free Play (everyone for themselves, highest score wins). Teams will be around 2 -4, with 5 - 10 players each. Play is divided into 5 minute timeslots, games can span multiple timeslots. Average game time will be about 20 minutes.

If you want people to take it seriously and to have any significant player retention, there needs to be incentive to winning. Some examples, in particular order: Monetary; either real or in-game. Levels; you get access to new robots/loadouts/color schemes as you rank up. Ranking; Elo, MMR, division, etc. Cultural; make people want to win for the sake of winning and getting better (this one’s hard).

All great ideas - winning additional play tokens is something we want to do. Access to robots is a cool idea. We are going to add high score / rank tables.

You need to consider how you are going to deal with abuse. You will run into 2 types of abuse: reckless robot use and bad manners (often called BM). People WILL drive robots into walls, push arms on a weak axis, flip robots, etc. etc. They need to be very well built to not take damage despite 24:7 use. If a robot flips, will a person come right it? Does it get left there? Either way, the flow of the game gets interrupted. As for BM, what do you do if 3 people gang up on another and pin them in a corner? Will there be moderators, either staff or community? How do you prevent moderators abusing their power? What are the consequences for BM? (Examples: ban, low-priority queuing, time-out, mute, warning system)

There will be someone actually manning each arena, to deal with situations like this. They also be electronically moderating play to deal with BM, this will probably be dealt with in the following order: warning, time-out, ban.

Thanks a lot for the input and enthusiasm. Be interesting to see how people think we should raise the word for the Kickstarter (August 1st!)

#8

Before you go any further, I strongly suggest that you (plural) spend one full week (24x7, no breaks) pretending that you are “live”.

Have an arena, make it out of cardboard boxes and chalk outlines. Have robots (RC cars, whatever). Have batteries. Have simulated user-activity bursts and droughts. Have real people be a simulated mix of clueless, knuckle-headed, mischievious, chatterbox, whiner, apathetic, know-it-all, complaining, trash-talking, trolling, non-English-speaking, etc. users. Have to seamlessly roll out new software into your robots and other computers during the week. Have members of your team all want to be elsewhere on two days to Christmas and Thanksgiving. Have one or more of your simulated users constantly posting negative comments on the Internet about every mistake you make, and making up negative comments just to be a jerk(s). Have one field gameplay and/or field-reset mechanism malfunction at random intervals.

Etc.

Do this so that your Kickstarter requests and commitments can be based on RRL- and user-experience predictions and estimates that are as accurate as you can make them.

Blake

#9

Absolutely - it’s pretty complex the project so they’ll be in-house, alpha and beta testing before we fully launch. We’ve certainly done a lot of testing so far on the platform and technology but of course there will be more to come.

#10

I’m not sure what you mean by launch - My suggestion was to do the simulation, before using Kickstarter tp ask other folks for money. If that is what you meant also, then we are in synch.

#11

This.

While I’m at it, here’s a few suggestions from the mechanical side:[ul]
[li]can simulate the ability to look around by replacing all cameras with fisheye lenses, and processing the image accordingly in the software[LIST][/li][li]client-side zoom and direction controls mean that multiple people can look in different directions from the same camera simultaneously[/li][li]no additional hardware complexity, so no more things to break[/li][li]this would work great with VR headsets, BTW[/ul] [/li][li]add a “commander” bot[ul][/li][li]stationary turret[LIST][/li][li]mechanical option: 1 or 2 servo motors --> can look around, but that’s it[/li][li]software option: see fisheye suggestion above[/ul] [/li][li]also able to pull up teammates’ video feeds[/li][li]a few possible special abilities:[ul][/li][li]EMP[/li][li]air strike[/li][li]supply drops[/li][li]be able to pilot a “UAV” for a limited time to get a better view[LIST][/li][li]could be quadcopter, but doesn’t have to be[/li][li]could be simulated with a gantry, skycam, or boom arm[/ul] [/LIST] [/li][li]special user interface: full console, multiple “screens”[/LIST] [/li][li]spectators can choose what they want to see[ul][/li][li]one or more stationary view(s) available[/li][li]mobile overhead camera[LIST][/li][li]gantry/skycam/boom arm is probably better than quadcopter for this application; no batteries to worry about![/li][li]movement is slow and graceful[LIST][/li][li]possibly based on average input from all spectators that are watching this feed[LIST][/li][li]with the fish-eye camera suggestion, both zoom and direction can be client-side (avoids “bad manners”)[/ul] [/li][li]alternatively, the mobile camera could be controlled by the field master for that arena; that’ll at least give them something to keep them busy[/LIST] [/li][li]for simplicity, this same system could be temporarily hijacked every now and then to provide commanders with their “UAV” functionality[ul][/li][li]during this time, the commander would have complete control --> movement should change to be much more quick and responsive (within reason, of course)[/ul] [/LIST] [/li][li]direct feeds from each bot[/LIST] [/li][li]give each player a heads-up display[ul][/li][li]game stats (score, time left)[/li][li]personal stats (score, health)[/li][li]minimap (with icons for self and teammates)[/ul] [/li][li]bots with omni drive would be useful for special effect purposes, even if the user doesn’t have omnidirectional control[ul][/li][li]think of an “explosion” pushing you away, or of sliding out-of-control down a “slippery” surface[/li][li]unlocking omnidirectional control would be a great incentive for competitive play: really cool to have, and helps a bit during gameplay once you get used to it, but doesn’t automatically mean that you’re going to always beat everyone[/ul] [/LIST]I would also love to see this game incorporate augmented reality. This would open up a whole host of possibilities, including some that could be done IRL but are more convenient, and also some that can only be done with the help of AR. Here’s what I could come up with off the top of my head:[ul][/li][li]see a floating flag icon above the bot that’s carrying the flag[/li][li]watch a “laser beam” shoot across the arena, and see a puff of “smoke” emanating from the impact point[LIST][/li][li]same goes for the “nuke” from the preview video (looks more like an EMP, based on what it did to the opponent)[/ul] [/li][li]“sparks” arc over the surface of robots that are temporarily disabled[ul][/li][li]the affected player should get some kind of static effects overlaid on their camera feed as well[/ul] [/li][li]project a virtual “barrier” that prevents bots from passing through[ul][/li][li]barriers could be server-controlled as part of specific game modes[LIST][/li][li]for example, to block the view of the other side of the field and give each alliance enough time to plan and set up an ambush before the match starts[/ul] [/li][li]alternatively, smaller barriers can be given as power-ups[ul][/li][li]opponents can “ram” these barriers repeatedly (or hit them with some other kind of weapon) to damage them and bust through[/ul] [/LIST] [/li][li]objectives appear as tall glowing beacons[ul][/li][li]commander-set objectives can be invisible to the opposing alliance[/ul] [/li][li]deploy an “oil slick” that causes bots to “slide” down ramps and interferes with maneuvering[/li][li]deploy “glue” that dramatically slows down any wheels that are touching it[/li][li]“flood” part of the stage, so that bots under water move sluggishly (low top speed and limited acceleration), but are hard to spot from above the water[/li][li]permanent or temporary “safe zones” in certain game modes, surrounded by a translucent “barrier”[ul][/li][li]could be team-specific (blocks opposing bots)[/li][li]could also be general (all bots can enter/exit, but weapon effects are blocked)[/ul] [/li][li]“x-ray vision” that allows a player to “see” other bots behind walls[/li][li]new game types could easily be added in software without the need for new game pieces and additional field reset work[ul][/li][li]real soccer with real robots, but a virtual soccer ball? sure! get yourself a reasonable physics engine and figure out how to drive the bots’ wheels to convincingly simulate pinning the ball against a surface, and you’re golden.[/ul] [/LIST]Thoughts about implementation (with respect to the AR idea):[ul][/li][li]not at all easy, but soooo worth it[/li][li]requires the server to have accurate real-time knowledge of each robot’s position in the real world, as well as a detailed understanding of the layout of the arena[/li][li]two options for rendering AR resources:[LIST][/li][li]relay all pertinent info to the user client (including all players’ positions & orientations), and rely on the end users’ computers to render and clip all SFX appropriately[LIST][/li][li]hardware-dependent: some users wouldn’t be able to enjoy the game as much, or at all[/li][li]more data transferred --> more bandwidth required, both on your side and the client side[/li][li]all changes require client updates --> version control is important[/ul] [/li][li]beef up those servers, and do all the rendering in-house for each camera feed[ul][/li][li]upfront co$t for hardware[/li][li]this game is uniquely well suited for this approach, due to the limited number of camera feeds[/li][li]fewer changes require client updates --> version control less important[/ul][/LIST][/LIST][/li]

EDIT:

Wow, that’s one heck of a wall of text. Hope it didn’t ramble on too much for you!

#12

Wow Skywalkar - thanks a lot! Some really great suggestions. My favourites are:

Fisheye camera - this adds some great functionality
EMP is a great idea for a weapon - similar to our “Nuke” currently.
We have already developed a heads-up display for each clients, but I like the suggestion for a top down map.
A gantry camera that can be controlled, great idea!
Augmented reality is top of our list for our next feature and you have demonstrated very neatly as to why!

As always, more suggestions are welcome!

#13

I must really like this idea, because I keep coming back!

Here’s a few more power-ups / abilities / special events that don’t necessarily require AR, while I’m at it:[ul]
[li]Time warp: slows down other bots.[LIST][/li][li]Implementation: decrease max speed of motor outputs for the affected bots.[/ul] [/li][li]Hurricane: “pushes” all bots in a given direction.[ul][/li][li]Implementation: Map “wind” vector onto each bot’s facing direction, and add that value to motor outputs. Bots facing sideways will “hang on”, but bots facing into or out of the “wind” must fight against it or they will be “blown” about. Best if accompanied by appropriate sound effects and wind direction indicator on minimap.[/ul] [/li][li]Magnet and/or repulsion field: localized effects, similar to “hurricane” above but centered around a single bot and limited in range.[/li][li]Signal jammer: bots’ controls are scrambled.[ul][/li][li]Implementation: either reverse all inputs, or randomly map them to other inputs. Best if accompanied by “static” effect on video and audio feeds.[/ul] [/li][li]Flat tire: dramatically slows down a single drive motor for a limited time or until the problem is “fixed”.[/LIST]And a couple of possible game modes:[ul][/li][li]Soccer: a single large ball is placed in the arena, and teams of bots must attempt to score this ball in the opposing team’s goal.[LIST][/li][li]Best with a fairly open playing field.[/ul] [/li][li]Jewel thief: one team is tasked with guarding a hoard of objects of varying shapes and sizes, and the other team is tasked with stealing them. The win goes to whichever team has the most “treasure” in their possession at the end of the match.[ul][/li][li]Variant: free-for-all. Same as above, but with only one guard and multiple thieves acting independently. Extra fun because thieves may turn on each other during the course of gameplay.[/li][li]Best if bots have magnets on front, and treasure is magnetic.[LIST][/li][li]Improvement: bots have electromagnetic coils to momentarily counteract the permanent magnets and release anything they are holding.[/ul] [/li][li]If many small objects instead of few large ones, then I suggest embedding scales in the floor of each home base to make scoring easier.[/LIST] [/li][li]Laser tag: self-explanatory. (Pew! Pew!)[ul][/li][li]Best with omnidirectional bots for peeking around corners.[/ul] [/li][li]Relay: each team has a large, irregularly-shaped object (a football, perhaps) that they must take along a winding path from point A to point B.[ul][/li][li]Option: the two teams could perhaps be walled off from each other, and only allowed to interact indirectly-- for example, by triggering a gate to close and forcing the opposing team to take a longer route.[/ul] [/li][li]King of the Hill: play in special arena with raised platform. Several variants possible:[ul][/li][li]Rack up points whenever you are the only bot on the platform, and the win goes to whoever has the most points when time runs out.[/li][li]After a certain period of time has elapsed, any bot not on the platform is eliminated. Match continues until only one bot is left.[/ul] [/LIST]And finally, the coup de grâce:[ul][/li][li]Sumo bots: see the Lightning Robotics Sumo Bot Competition for inspiration. (You would want to leave out the part where some of our students have equipped their bots with pickaxes and spinning blades of doom, but the rest of the game mechanics would work just fine for your purposes!) As a longtime participant and member of the LRSBC Game Design Committee, I would be happy to answer any questions you may have on the subject.[LIST][/li][*]Example A: in our most recent competition, we played an interesting variant of the king-of-the-hill concept. With our traditional “tabletop” playing field several inches off the floor, the quickest way to eliminate an opponent was to push them off the edge of the field and onto the floor. Alternatively, players could (literally) take the high road by instead choosing to dominate the elevated platform at the center of the field; after a certain period of time had elapsed, any robot not on the platform was eliminated. The match would then continue indefinitely until there was only one bot left on the platform; in practice, this “sudden death” period would never last very long, so we could run a huge number of matches in a short period of time (perfect for those growing-pain situations where you’ve got a long list of people waiting to play).[/ul] [/LIST]

#14

I’d urge you not to have them fight. Even with the best modern architecture, latency will be a big issue. So too will money. Why not have a game where damage is minimal?

I don’t have any idea how you’re going to make this compelling enough to raise the funds needed for uptime yet keep it cheap enough to afford in the first place.

That’s the biggest issue with any physical robotics events (Battlebots, i’m looking at you), at a certain point, the fans are left wanting more and the robot damages are eating away at your wallet.

#15

I agree with you 100% about this! I apologize for not making that more clear. I did not mean to suggest that they copy our model word-for-word, but rather that they could take some inspiration from our past game designs and adapt them for this application.

I would indeed strongly discourage the inclusion of weapons of any sort-- even a slow forklift-type weapon could easily break if leveraged in the wrong way! Instead, I would suggest that they stick with the same exact super-durable-box-on-wheels bots that they’ve already shown so far. That way, the most harm that can come to a bot is falling a grand total of 2-3 inches to the floor-- something that I expect them to be able to handle just fine.

#16

Someone is trying to make a go of giving remote users control over competing robots.

They might want collaborators - They might not.

See Robodub at https://lnkd.in/etn3vEr

Blake

#17