Category: Game – Cluster

Posted on

Saturday, January 4, 2020

Continuing to read and watch Blender training information.

Blender

Getting a bit distracted by pulling in blender 2.8 build source code. I’m now a bit curious about the internals and may let myself be distracted by that now and again. Certainly planning to see if I can run a local build on Jabberwock…Chaos upstairs has path issues that I’ll need to resolve before I can do much on that front. One of the nicer things about having more than one build-capable machines around.

Unity

Looking at a few things in the immediate future

  • Get text working. Hover text labels over stars that always face the viewer with at a minimum the name of the star.
  • Build star gate model(s) in blender and import them into unity and then place gates in the view.
  • Build a simple information viewing panel in game and support star selection where the information for the selected star shows on the panel.
  • Build a simple mechanism for saving game and loading games. Need a persistence format for game data.
  • Look into adding simple feedback sounds to the game. At least a noise when a selection is changed in the star display.
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

Unity Stars and Textures

This weekend, Malcolm and Sam came over for a day to move our various Unity investigations forward.

Malcolm made some very nice pieces of furniture and architectural bits. I think the end result has much more feeling of place and I’m moving forward from there.

The Cluster Control Room

Sam was working on his own project and looking at getting his motion working properly on Daydream with the Daydream controller.

I added some interactivity to my prototype. Attaching a ‘stick’ to the controller and hanging a small sphere with a collider attached makes it straightforward to select objects by touching them with the stick. It took a surprisingly long time to find the appropriate code to implement haptic feedback when a star is touched. I’m still looking at adding a short positional sound queue on touch as well.

The code lives on my github account here. This supports Vive only (I think) at the moment. It certainly supports Vive best. At some point I’ll likely look at making this work with DayDream and flat screens.

Some Sample Textured Spheres…

I grabbed some textures from around the house and yard and slapped them on some random spheres and capsules. Those are here and there are separate branches for DayDream, Vive and flat screen (master). The Vive version looks much better than the DayDream version and I expect that is to be expected.

I spent some more time chopping up texture tiles. Not a lot of time to clean them up though. I really need to better understand the impacts of the various extra texture functions that are available. I think there are some options missing from the default material such as displacement maps that can genuinely move vertices. Lots to learn along the way and getting there with the Vive is pretty cool.

Posted on

Working Through the Technical Side of Unity

Sam, Malcolm and I have been diving into the more technical side of Unity development for the last couple of weeks. I expect this will go on for a while to come as well. There will probably be items on this side now and again as the Cluster game hits plateaus along the way and there are graphical bits and game play decisions to talk about.

Currently the technical content is being written up on my career blog. Perhaps a less than ideal naming choice as it gets most of the hard technical content yet I’m never likely to take a job in the games industry.

I’m currently working out a new scheme for partitioning up the pieces of the game and making the cross platform support (Daydream VR, Vive VR and flat screen PC) workable. I’m also likely to rebuild some of my spaceship assets as run-time created prefabs rather than manual prefabs.

Posted on

Cluster Game Description

Inspired by SPI Stellar Conquest but with a somewhat different spin as this is computer mediated.

I’m looking to keep the game rules relatively simple so only a limited number of tech options, a few ship types, a couple of planets per star (tops). If all of this comes together well, I might add a few embellishments to the thing later on.

  • Multiplayer (up to four initially, likely two in early development, more possible later)
  • Semi three dimensional star placement.
  • Three kinds of warships along with scouts and colony transports.
  • PC screen, daydream vr and vive vr support initially. Might look at direct web interface as well (three.js perhaps) at some point.
  • Industrial production system.
  • Build ships.
  • Develop technology.
  • Grow populations.
  • Goal is to dominate the star cluster.

The Rationale

The ancients built massive stargates capable of flinging ships far across the universe to places far beyond the reach of conventional warp drives. The cataclysm that ended their presence in the galaxy may have destroyed their planets but their gates remain, orbiting stars amid the rubble of their shattered worlds.

No one understands why but these gates open at times for a short span providing access to distant parts of the universe. Many of the younger races station small colonization fleets near known gates in order to colonize the far flung places that a gate opening gives access to.

When the gates open, several gates generally connect to the same target area. Only a few ships can make it through before the gate closes so each race engages in a scramble to dominate the new star cluster before the others can gain a foothold. The gates only allow limited technology through (whether this is an inherent limitation or a security feature, no one knows) so the initial task force consists of a few simpler vessels.

Nothing prevents the construction of more capable ships and equipment once established colonies can produce the necessary infrastructure. This adds another facet to the struggle as each species works to enable use of the technologies they brought with them, in this new place.

In the end, the victor will eventually build the tools to force the gate open to their home galaxy and re-establish contact and trade. By the time this task is complete the control of the cluster will have been long ago resolved and a thriving web of colonies established.

Posted on

Spent some time looking at game rules last night…

I spent some time looking at miniatures and wargame rules last night (and bought a discounted Unity book from Packt that I’m hoping will give me more insights into areas of interest).

I need to take the next step on build-out of my ‘Cluster’ game in the next few days and generate a population of stars from a prefab and then get hit-testing of mouse clicks to star working. I think I have most of the bits in had to carry this off, but I need to test it out.

In the initial pass, I’m not looking to implement anything overly fancy in the star generation and positioning code. I may even simply walk them around the board with reckless abandon at first.

I found some examples here that seem to show how to take a mouse click position on the UI and hit-test the viewport normal from that position. This code even does (or suggests) the zoom function I was thinking about implementing in order to view individual systems.

I expect in the longer run, there will also want to be various control panels supplied with information that is more classically UI style to make managing the overall effort easier. Ideally this could be done without these, but I’m not quite sure how to get there at this point.

I think I may set up the board game tonight and look at running a few turns solo just to get back into the feel of the game. If I do, I’ll post pictures of the board with counters on it and related items.

Proudly powered by WordPress