Posts

Posted on

Missile Command Inspired VR

Interesting way to play with VR UI approaches if taken moderately seriously

The player is standing on the ground with a dark sky overhead. Controllers are used to cue weapons fire.

Inbounds are shown with location, trails showing previous track and various information attached as they move…possibly current velocity and acceleration vectors attached.

Player points at desired target and cues in a weapons system on that target (or targets sensors perhaps to gain more information)

Could be a fun thing to play with.

Posted on

Ideas for VR Games

On the flight out to San Diego I was kicking around some game ideas. The cluster game is already in progress and I’m leaving that one aside. Here are some of them… this is going to be a bit ‘stream of consciousness at the moment.

Human Space Invaders

The idea is that you’re standing there looking up at space invaders flying around and getting closer. You have several weapons you can fire at the attackers and they drop ordnance towards you as they fly over. There are shields above you in places that neither you nor the invaders can shoot through but all shots damage the shields if they hit them.

I was thinking of a few weapons for the player:

  • a beam weapon that you can play around like a flashlight. This would use ‘energy’ that is slow to refill and rapidly consumed when lasering. Very powerful and effective but limited availability.
  • Pulse weapon similar to the laser but much more efficient. Draws from the same energy reserve but fires blobs of energy up at the enemies.
  • Controllable weapon. Limited number per stage. After launch you can direct it with your controller and either cause it to hit an enemy or detonate it on command to throw out a spray of damage. The direction the relevant controller is held in would control the direction of flight of the round. Releasing the fire button would detonate the round.
  • Possibly a ‘boom’ round that flies directly up from where you currently are and when triggered throws out a much larger spray of damage than the missiles. Probably like a ‘smart bomb’ a limited total supply of these over all.

Hypergate Centurion-alike

Resource management game.

You are looking over a set of hypergates where your job is to send out attack craft to deal with space monsters and pirates. You get points for ships successfully transtting your gates or coming in and flying off to in-system destinations.

Items in the game:

  • Hypergates: ships and monsters enter and leave through these. When a commercial ship leaves through its designated gate you get points.\
  • Defense stations: Each station hosts a number of attack and salvage ships that you can send out to perform tasks. Stations and ships can be attacked by various things. You need to manage these resources to get your job done.
  • Plasma buoys: You have a plasma weapon that you can fire directly at targets (think ‘grid fire’ in the culture novels). Your attack power is related to how many buoys you have active and how close they are to the target location.
  • Off screen destinations: some ships (and pirates) come from or go to planets in the system that are off screen.
  • Commercial ships
  • Noncombatant military ships transiting the system. You get points for these ships getting where they’re going. They will defend themselves if attacked. They can be asked to assist with threats that don’t directly affect them but this costs points and is not guaranteed.
  • Gas and debris clouds. Obscure sensor readings. Conceal and generate monsters and pirates

More options to come…those were the first two on the list and probably the most fleshed out…also could restyle the invaders game with a less cartoony missile command approach and get something more serious and perhaps with more long term playability.

Posted on

Cluster – RESTful APIs

As part of building the front-end to the shared web side aspect of the cluster game, I’m starting to lay out the RESTful interface to the database at the back-end of the server side.

I’m looking at several main categories using query parameters to filter results on aggregate areas.

  • players
    Returns a list of player names and ids. Details of a specific player can be retrieved (and changed) by accessing the player by player id as a sub-resource. Permissions do apply here…a normal player can only view or edit the details for their own information. An administrator can view and change information for any player.
    • id (immutable after creation)
    • name – Unique, human readable user name
    • email
    • is email public
    • password (settable only)
    • active
    • date joined
    • date last activity
  • games
    Returns a list of games in the database. With query parameters this can return games containing only a selected player or players, games that are in progress and perhaps other subsets of all stored games. Details of a specific game may be retrieved by game id. For normal players, only the details that their player identity has access to may be retrieved. For developers all details are visible and subject to modification.
    • id
    • player ids
    • turns
      One entry for each turn in the game so far. All open if the game is completed otherwise only information visible to this user is present.
      • turn number
      • units list
        • unit id
        • unit type
          ship type, planetary resource type, population
        • location type
          space or system or planet
        • location
        • player id
      • technology list
        • players
          • player id
          • technology id
          • level
          • investment
      • moves list
        • players
    • current turn
    • moves submitted
      (may be part of the turns container)
    • active
    • created
    • completed
    • final scores if completed
    • stars
  • options
    Options that relate to new games being started. Global lists (start information, admiral information and such). Generally these will only impact newly created games. Selected items may affect all games.
  • audit
    Audit log recording changes made using administrative privileges.
Posted on

Cluster Game Moves

Overview

  • Turn based multi-player
  • Internet based shared state
  • Once all player moves for a turn are complete, the turn is executed
  • Strategic level
  • Non-interactive combat resolution a the end of the turn

Units

  • Scout ships
    Small, unarmed vessels with unlimited range used to gather information.
  • Colony transports
    Large vessels that only exist to transport a group of colonists to a new star. Once the colonists debark, the transport ceases to exist as its parts are used to support the new colony.
  • Escort
    Small interstellar armed vessel
  • Assault ship
    Medium sized interstellar armed vessel
  • Capital ship
    Largest interstellar armed vessel
  • Defense platform
    Small defense system dedicated to the defense of a single planet. Combat equivalent to an escort.
  • System defense boat
    Medium sized system defense vessel. Equivalent to an assault ship in combat. May be used in defense of any planet in a single system.
  • Factory
    Production facility on a given planet. Increases output of one unit of population based on the level of factory technology that has been developed.
  • Robotic Industry
    Production facility that operates without an accompanying population unit.

Basic Turn Mechanics

  • Spend on building ships
  • Spend on building facilities
  • Transfer population to colony transports
  • Form ships into fleets and break ships out of fleets (if at a star)
  • Spend on technology buys

Movement Mechanics

  • Scout ships can move independently and over unlimited distance
  • Unarmed ships that are not escorted may be destroyed on entry into a new system
  • Without hyperwave technology, fleets always continue to their destination system
  • Fleets never encounter each other in open space
  • Fleets move at the current guidance velocity for their side
  • Fleets are destroyed if they move beyond guidance range of all of their side’s beacons
  • Ships that aren’t scouts can only move as part of a fleet
  • Every fleet must have an admiral assigned to it
  • One ship with an admiral can be a fleet
  • When a fleet enters its destination system it ceases movement

Combat Mechanics

  • If fleets from different players are at the same star then combat will occur
  • Combat ends when a system contains only ships from one side in a system
  • Planets with defense platforms may be reduced by attacking and destroying those platforms or interned.
  • Production on planets that aren’t interned becomes available to the controlling player after some delay
  • The owning player may perform planetary bombardment to reduce planetary population. This eliminates one unit of population capacity for every unit of population removed. Likely only relevant if you expect the enemy to reclaim the system soon.

Posted on

Looking at database structure for Cluster

We’ve framed out the ‘Cluster’ game graphically (at least to a first approximation). Currently the cluster generation is handled in Unity and there are no game rules and no save games.

I’m in the process of roughing out the MySQL database structure that will hold persistent game data and convey it between players and looking at coding up the php code needed to manage this data and implement game turn logic and playing field generation.

Once the basics are sketched out, I expect to remove the generation logic from the Unity code-base and switch things over to use the layouts and turn management provided by the site based php code.

I’m expecting to see the database side layout break out into:

  • System Data. Things that control game operation but do not change game to game or player to player.
  • Player Data. Information about the players that is not related to a particular game. Name, picture or icon, other particulars.
  • Game Data. Information that is a base part of a particular game run but does not change turn by turn.
  • Turn Data. Turn and move data for the game.

System Data

  • Star name list
  • Planet types list
  • Configuration such as number of stars per game and other similar items.

Player Data

  • Player ID
  • Player Name
  • Player picture or icon
  • Games played
  • Wins/Losses

Game Data

  • Stars Information
    Table with color, location
  • Planets Information
    Table with type, properties, max pop, orbit

Turn Data

  • User Move
    Fleets from -> to. Scouts from -> to.
  • Resource Production
    Build Ship here, Build planetary resource here, Spend on research. Form and break fleets.
  • Combat Resolution
    Combat results. Remove destroyed ships. Resolve ownership changes.
Posted on

Experimenting with Commercial MoCap

Configuring Eye cameras here.

Playing with the evaluation version of this.

Malcolm and I spent part of Friday experimenting with an evaluation version of a commercial motion capture package. I now have six PS3 Eye cameras and my VR machine has enough USB-3 ports and controllers installed to run them.

Our initial setup had three or four cameras attached and used the room lighting (pretty bright, ceiling mounted LED lights) for illumination. Initial results weren’t great but over the rest of the day we learned a few things.

  • Need a more contrasty background and a less cluttered background. The bookcases behind the area we were using were better when covered with a piece of white fabric. The tan rug on the floor was less of a problem when the model put on black socks.
  • Hands really aren’t handled by the package. No big surprise here as hands and fingers are rather small targets for these cameras.
  • More lighting is better. I added two diffused studio lights I have around and a high intensity three light halogen light bar and things became more precise.
  • A larger and more diffuse calibration target seemed to work better.
  • Sliding the calibration beacon along the floor with periodic stops seemed to work better than touching it to the floor. This makes all floor level reference spots about equal (when I was touching it down, it took a little work to make sure we had the lowest spot in each arc).
  • Aligning the reference person with the human figure in the images at the start helped quite a bit. The tool didn’t seem to do a very good job of this without manual help.

By the end of the session, we seemed to be getting a pretty good capture of arms and legs. Feet could still be a bit twitchy.

Malcolm is going to look at 3D printing mounting clips to attach the PS3 Eye cameras to light stands for more stability.

I ordered a couple of spare cameras to ensure that we don’t come up short if any of them fail and a couple of PCIe USB-3 cards to supplement USB controller availability.

Overall things turned out pretty well and I think we learned a bit more about making motion capture without dedicated beacons work decently. The price of the package is high enough that even a short time license would need us to have some substantial amount of motion capture to get done in order to make things make sense.

Posted on

Onwards to Linux C++ OpenCV and Capturing Some Frames

I proven that the cameras can run on Ubuntu and the RPi. I found a page with classic Unix/Linux style install instructions. I’ll be working on getting this set up on my biggest RPi machine and take a look at building code to red from multiple cameras and stream the data to a host. If I can run two cameras on a single RPi then I should be set.

I’ll probably also look at doing something similar for the RPi cameras on the RPi-2 machines. That might add a couple of additional cameras to my set.

I’ll then move on to building a simple LED beacon and look at some simple camera calibration code on an appropriate host.

Trying to build the OpenCV package on one of my RPi 3 machines. I think I’m running into heat issues. I’ve switched to a board that I can keep open and has a heat sink on it. Hoping that may be enough. I’ve also dropped the build scripts onto github to make them broadly available.

Pulling packages on this machine now.

Now I’ve got a fan blowing. I see from some web pages that the RPi is supposed to warn and throttle when the temperature spikes…didn’t see that with my black and silver RPi 3…it seemed to halt completely after a short span. Keeping this one cool up front and we’ll see how this goes.

Interesting…it looks as if the scipy build is eating all available physical memory on the RPi board (882 MB of 923 total). Nothing moving on the machine…not even the mouse cursor.

Ah, reference here to bumping the swap file for the RPi.

Monday morning dawns and it appears that I have a raspberry pi that is loaded up with an installed build of OpenCV. No time this morning to test this but tonight I’ll run through a few simple tests and then probably run the same process on one of my Intel NUC machines (should go faster and easier) to get a decently powerful system up and working with the same version.

Posted on

PS3 Eye Cameras Came in and RPi Machines are Going

Yesterday my five additional $6.00 PS3Eye 60 FPS cameras arrived. I’ve pulled my RPi machines and my two Ubuntu based NUC machines out and started checking out the cameras and making sure the systems are up-to-date.

RPi 3 machines and various supporting parts.

The NUCs generally get more use and thus needed less updating. I found that using cheese I was Immediately able to run the cameras on both the Ubuntu NUC machines and the RPi boxes. Even the older RPi-2 machines ran the cameras…I’m not sure that the performance on those will be sufficient to make them useful though. They do both have RPi internal cameras connected though so that may be of interest. I’ve got to look at how to access those cameras from C++ code and see what sort of performance they have (and test them out to see what they can do).

The RPi-2 machines with attached cameras…

Here are the cameras (the one sample I bought for testing and the five others that just came in). I may pick up a couple of spares to make sure that I have what I need in the longer run…at $6.00 each that isn’t a big deal). The beer pong balls look like the perfect size for a light diffuser on an LED…I’ll have to rig up a few LED/resistor/battery sets to try that out sometime soon.

Cameras and diffusers waiting to be unpacked.

On Sunday I’ll look at getting programmatic control of these cameras. If I can acquire images from two cameras at the same time and stream the data out over a socket, I’ll be ready to rock with these things.

Still to be managed is getting the cameras rigged to mount on light stands and getting three more light stands with ball heads to set them on. If the RPi-2 boards look interesting with their integral cameras then I may need some additional mounting options, but initially three to six cameras should be a good start.

Posted on

Got the *.fbx SDK installed and my RPi machines out and booted up…

I’ve installed the filmbox SDK on my home machines so that I am in a position to play with programmatic manipulation of *.fbx files. This feeds into the motion capture experimentation I’m doing and should be generally useful at times.

I also dug out my three RPi 3+ machines last night and got one of them booted up and connected to a PS3Eye camera…without actually taking images…just observing the power light go on and no other negative effects. I’ll likely move further over the weekend to try getting actual image capture working there.

I did find a github project that claims to be able to run one of these 60 FPS cameras from an RPi. This project appears to be motion sensing related, but I expect it can act as a source of sample code for my longer term purposes…

Posted on

Sample Cameras for MoCap Experiments Came In

My sample cameras came in. I ordered two cheap webcams, a Sony PlayStation 3 Eye Camera and a Fosmon USB 6 LED 1.2 Megapixel USB PC Webcam as these were both under ten dollars and looked potentially interesting.

The Fosmon camera looks too slow and low on image quality to be useful for my purposes here so I’m shelving that one. The PS3 eye camera is challenging to interface to a PC, but at $6.00 per camera, I’m inclined to spend some effort here. There do appear to be Linux drivers out there and I’m going to look at a RPi mediated option with these (I’m willing to invest $30.00 for five more cameras to give this a try).

The other option that was presented as viable are Logitech C922x Pro Stream Webcams. I have two Logitech C930e cameras currently…these won’t run 60 FPS but have comparable image quality and a wider field of view. At $70.00 each, I won’t be picking up six c922x cameras any time soon, but I may purchase on or two if all goes well to see what they are capable of. They’re almost certainly better cameras than the PS3 Eye devices, but rather pricey.

I’m also picking up some CR2023 batteries and battery holders along with a box of LEDs and some 19mm ‘ping pong balls’ to try as diffusers.

This is all an experiment, so it may come to nothing more than an interesting diversion. The commercial motion capture options are far too expensive to be viable as a hobby thing and I’m expecting to have some fun putting this together and seeing where it can go.

I would be particularly happy to see an RPi solution work out as having one pi board for each pair of cameras (or even for each camera at a stretch) with an Ethernet back-haul to a full fledged PC for processing would be a flexible and relatively affordable solution with pretty good scalability to more cameras as well.

Proudly powered by WordPress