Posted on

An update from Foo

2020 has been a crazy year.  We knew pandemics would be inevitable.  In a globally connected world the eventuality for a contagion to spread like wildfire was just a matter of time.

COVID-19 has affected us all.  We all know someone who has been directly impacted by COVID.  At the same time we see the sum of decades, and centuries of frustration and anger swelling up.  

COVID threw us for a loop too.  Our plans this year have been impacted, but we haven’t lost sight of our objective.

Throughout the years Foo Games has had one primary goal:  To enhance multiplayer game play.  For many people multiplayer games provide a basis for their social network and opportunities to meet new like minded people, and most importantly – to have fun and discover new aspects of the world not readily accessible.

Ingress has been one of those expansive games we’ve discovered.  Since we started playing in 2014 we’ve discovered a fantastic world of gamers from all walks of life.  The experiences we had in Ingress grounded our reserve and highlighted the need for information and communications technology to be enablers of person.  To enable people to come together to tackle modern day challenges.

But in 2020 – Calvin bounced his ball, and here we are with COVID.  COVID has shown structural cracks in our very foundations of society.  From supply chain management to the effects of massive unemployment, lack of basic health care and the slow trickle of collaborative science, COVID has affected the lives of millions upon millions around the world.

Here in British Columbia, Canada, we’re pretty lucky our Government took steps early on to “crush the curve”.  By reducing resource utilization within our hospital system and buying time to implement protocols to support a population with no immunity, the government has bought us time to help us when we do get infected.

Early on we hoped COVID would be a wake up call. We firmly believe that for a global economy to function well there must be local sustainability while taking on the best aspects of global trade.  There need to be streamlined processes to support global trade for entrepreneurs on the ground.  Support for entrepreneurs and cottage businesses that provide great value to their communities, but when hampered with the day-to-day maintaining house, home, education, and overall well being – the cracks in the system hamper progress.

We know we certainly can’t fix the problem – we’re a small team, and change in society takes generations (as we can see through policy shifts and changes in public perspective throughout the world) – but we do see this vision as being the future.

With that in mind, we are continuing our work – albeit slowly.  We’re looking for supporters, partners and ultimately funding to help us achieve our goals.  If you’re interested in hooking up with us – drop us a note through our contact form here: https://foo-games.com/get-in-touch/

From all of us at Foo Games.  Stay safe, and keep the good games rolling.

  • Foo
Posted on

Shard Games

Avenir Shards are live (the Map) – a new global shard game in X-Fac mode! This is pretty cool, and reminds us of an old X-Fac shard game proposed by the Enlightened League of Operators back in 2016.

The game mode was pretty simple – agent controlled beacons for ornaments, RES and ENL. The idea was circulated between regional Resistance and Enlightened Communities – one such idea went something like this:

  • Select a play area and appropriate targets, ones that might see res action during the session. Use ENL/RES beacons to identify targets and beer beacons for shard spawn sites.   
  • Use Zello, Glympse and TG (or other chat utility) to track and communicate with agents on the ground. 
  • Light target beacons prior to shard spawn time.  At/before start time, move agents to target portal to collect keys. The need to collect lots of keys should be stressed (frakk if you have to).  Give keys to runners or bikers to get out to agents in the field.  
  • Appoint a “shard operator” to select where a shard jumps to if it is not linked to the target within the window.  The shard op will communicate to the team op where the current location of the shard is. Everyone must pay attention to communication her because the beacon will still be on the original site.  Spawn sites are pre-selected, but a designated agent on the ground will light them as they see fit (or as instructed by the “shard op”). The team operator(s) should not have prior knowledge of spawn sites (or targets).  Adjust the spawn sites and area as needed considering the number of agents.
  • Agents should be clearing a path from shard to target when they spawn.  
  • Consider having a “rogue” agent (might be the same one lighting targets and shards) make unexpected blocking links or flipping target portals.  This simulated unpredictability is important especially if res activity during the practice session is limited.
  • Depending on the number of agents, consider assigning agents to zones and expand the number of operators.  An operator would be in charge of each “zone,” with a sector op helping to give directions.

We think this would be a pretty nifty local play! Depending on agent numbers and mobility – zoning out a 2.5, 5, 10 or 15 KM radius could be a pretty interesting competitive event. We think we’ll add this to our wish list for IITC plugins 😉

Posted on

Geo gaming recruitment

As community champions and game masters, we understand many of the challenges communities face both in the real-world, and online.

For the past couple of decades, we’ve had a passion for connecting people throughout the world. We know what amazing possibilities become real when we bridge the digital divide by providing spaces that help foster relationships through team-based play and friendly PVP play. In growing these support networks – players become more connected, and most importantly – are able to access even more opportunity.

Back when we started playing Ingress – we resurrected some old concepts we used working on digital divide projects, to provide support for Ingress communities. As our first step, we sketched out some pretty basic principles based on what we perceived as being real-needs in order to accomplish global team work within a fractured, decentralized network of varying communities and lone wolves.

We saw these goals as being central to one of our core pillars: To help bring people together to accomplish new goals, take on new challenges and enhance their skill-sets.

Back in 2014, Ingress was much more of a tactical kind of game. We immediately saw the need for strategic intelligence sharing to gain mind units over opposition team territories. Times have changed a lot, with more and more players looking for more opportunities for field art and a less hard-core approach to playing the game (much of which is thanks to the hard work of agents in cross faction circles around the globe that have helped bridge relationships). But we wanted to take a stroll down memory lane to look at the tools of the trade-craft back then.

The concept of belonging to a team, and having a role in the team’s success.

  • New agents weren’t being engaged quickly enough. Agents get bored. Opportunities for rapport building and getting them ‘hooked’ on team-style play dwindle quickly if they’re not engaged right away
  • Limited resources for recruitment. When we started, it was a small number of players handling so-called recruitment, and they wanted to make sure we weren’t the enemy trying to infiltrate, or an alt, or a general risk.

Using successes we’d learned working on the non-profit volunteer space, we developed a general recruitment and registration system that empowered willing volunteers to help bring new agents in from the cold. We designed the system thusly:

  • Anyone already vetted in the general community could engage and direct players to the registration site, view whether a given player had registered, and find out who had been in touch with them.
  • Members of a specialized recruiter team (ie: those who were somewhat experienced, and served as good mentors) were able to access and document observations and findings of their interaction with the new player. The system was specifically designed to help identify what areas of interest a player might have, as well as what experience they might be able to bring the team.

    We also made a fairly key decision early on in the design that we wouldn’t let agents “take” a particular recruit – a decision that wasn’t overly popular – but one that we felt was the best approach to making sure agents weren’t being recruited on a 1:1 basis (after all, we were looking for members for our overall community – social circles could form out of that afterwards).

We also built the system into several layers as well, since we also had to manage a number of social media channels:

  • G+ (defunct, sadly)
  • Local hangout(s)
  • Local and neighboring regional slack(s)

With different managers covering different channels and regions, the central recruitment system used in our metropolitan area Ingress community was setup to allow for multiple vetting and status reporting for new agents depending which medium they were looped into. And since COMM based communication across multiple S2 cells often led to our having an out of towner show up, we also needed a way to refer agents to well known Ingress communities outside of our region’s coverage area. Thus, the system also supported a concept of agent referral- in that we could refer an agent to Vancouver Island, Alberta or elsewhere ensuring we didn’t drop the ball on our faction getting someone engaged, and leaving the agent out in the cold.

In implementing these processes, teams were able to recruit, track and support new agents through mentoring, connecting them into groups of interest where they could excel and be part of the bigger picture.

And with game genres, continuing challenges in volunteer recruitment and the ever increasing globalization of game communities we’ve taking that concept to version 3 to help foster even even stronger communities.

Foo games provides game masters with management tools and support to build healthier, more engaged communities, and to provide opportunities for gamers to further their game play, art and passions. To find out more, get a hold of us via [email protected] or give our lead operator a shout at +1 778 819 1298

Posted on

Trip down memory lane – the great Steampipe Update of 2013 and custom models

It was a dark and stormy night..

Back in 2013, Valve released the massive steampipe update. It was a pretty awesome change over all – differential updates were pretty important, but various changes to the VFS happened, and an annoying quirk that came out of it was the model chooser in HL2DM – it didn’t work anymore – and still doesn’t!

Way back in the day – Foo hacked up a quick work around for the Half-Life model chooser problem in Sourcepawn – sm_modelchooser_hl2dm.sp

In designing the interface for the plugin, we also wanted to make it super easy for players to change their model. We added a menu to the Sourcemod !settings menu, but also (and somewhat elegantly even) added support to make model setting even easier. Rather than worrying about players or admins needing to know exact model file names etc, we coded the command handler to search for partial matches within the array of models:

new String:Models[19][70] = {
	"models/combine_soldier.mdl",
	"models/combine_soldier_prisonguard.mdl",
	"models/combine_super_soldier.mdl",
	"models/police.mdl",
	"models/humans/group03/female_01.mdl",
	"models/humans/group03/female_02.mdl",
	"models/humans/group03/female_03.mdl",
	"models/humans/group03/female_04.mdl",
	"models/humans/group03/female_06.mdl",
	"models/humans/group03/female_07.mdl",
	"models/humans/group03/male_01.mdl",
	"models/humans/group03/male_02.mdl",
	"models/humans/group03/male_03.mdl",
	"models/humans/group03/male_04.mdl",
	"models/humans/group03/male_05.mdl",
	"models/humans/group03/male_06.mdl",
	"models/humans/group03/male_07.mdl",
	"models/humans/group03/male_08.mdl",
	"models/humans/group03/male_09.mdl"
}

This way, players could simply choose a team to play on using something like this:

!model female
!model male
!model combine

But if they wanted to be super-specific, they could use:

!model male_01
!model female_03

instead. All in all, we were pretty happy with the easy work around for the problem of models back then, and looking back on this plugin – we’re still amused it’s alive and kicking 🙂

Posted on

Configuring custom weapon modes on a per map basis

We were recently asked how to go about configuring a multiplayer Half-Life 2: Deathmatch server to support different game modes depending on maps. 

The owner wants to offer varying environments for players to play in, and luckily our weapon manager plugin was designed with this specific goal in mind!

We elected to use the most excellent mapconfigs plugin by bcserv to handle the actual task of setting which set of weapons maps would use.  In this case, we set it up so that maps prefixed with “de_” would use sniper weapons only, with remaining maps using default weapons.  

First things first though:  Deciding which weapons players would spawn with and whether other weapons would be allowed.  

We setup defined two weapon modes:

“default” gives shotgun, crowbar, pistol, smg1, slam, 357, crossbow, frag, physcannon.  For giggles, we set the 357 magnum to allow firing under water – we were curious to see who figured out they can snipe with the fishes!  

“sniperxbow” – my personal favorite, the perfect combination for a neo-style fire and forget physics weapon, and a 357 magnum for those times when you’re sneaking in the bushes.  For this mode, we set the option to not allow weapon pickups from the map.  

"default"
{
  "options"
  {
    "pickupothers"  "1"     // 1 - Players can pick up any weapons they find on the map.  0 = deny pickups of other weapons
  }

  "weapon_shotgun"
  {
    "default"       "1"     // Make the Shotfun the default weapon
  }

  "weapon_crowbar"
  {

  }

  "weapon_pistol"
  {
    "p_underwater" "1"    
  }

  "weapon_smg1"
  {
  }

  "weapon_slam"
  {

  }

  "weapon_357"
  {
    "p_underwater"  "1"     // Primary attack fires under water

  }

  "weapon_crossbow"
  {

  }

  "weapon_frag"
  {
  }

  "weapon_physcannon"
  {

  }
}


"sniperxbow"
{
  "weapon_crossbow"
  {
  }

  "weapon_357"
  {
    "default" "1"
  }
  "options"
  {
    "pickupothers"  "0"     // 0 - can't pick up any other weapons than those listed here
  }
}

With these settings added to addons/sourcemod/configs/weaponmanager.cfg it was now time to setup the sniper maps to use the sniperxbow weapon mode.

bcserv’s mapconfig plugin is pretty simple to configure.  mapconfig looks for a configuration file for the current map in based on map prefix, so if we’re playing a map named “de_xyzzy” – mapconfig will first try to read “de_.cfg”, then “de_xyzzy.cfg”.  More technical information about the mapconfig configuration and plugin can be found on the AlliedModders forum.

In this case we set it up as follows:

From the hl2mp server folder, create:

cfg/sourcemod/map-cfg/de_.cfg

and add the line:

sm_weaponmanager_defaultmode sniperxbow

With this in place, every map that starts with de_ will run the sniperxbow weaponmode.  The best part is for specific maps (eg: de_xyzzy), if we wanted to add a slightly different configuration (lets call it “xyzzy” mode, we could create a new weaponmode that grants the crossbow, 357 and crowbar!

"xyzzy"
{
  "weapon_crossbow"
  {
  }

  "weapon_357"
  {
    "default" "1"
  }
  
  "crowbar"
  {
  
  }
  
  "options"
  {
    "pickupothers"  "0"     // 0 - can't pick up any other weapons than those listed here
  }
}

Then in we would create a new mapconfig file named cfg/sourcemod/map-cfg/de_xyzzy.cfg

and add the command:

sm_weaponmanager_defaultmode xyzzy

We can also add extra commands too, so that only de_xyzzy runs them.  For example:

sv_gravity 600
sm_playerspeed_infiniterun "1"

would adjust the gravity for this map only and also let players run infinitely without recharging.

Easy peasy!