What happens when you add a multiplayer functionality

I’m currently continuing to build on top of my LD48 jam entry. I’m currently prototyping a two player online multiplayer version and the idea is to get a brief idea on how long this will take. I’m very aware that adding a multiplayer networking isn’t that simple… so the first step is to learn and see if a multiplayer game is even possible for me to do in Unity. And while there are fine articles about the topic (such as this: Don’t make multiplayer games) I want to test it out myself before I decide one way or another.

screenshot_2014_05_25-09_50_00

I have quite a bit of low-level networking experience (I once built my own medium-high level UDP framework), and I don’t want to do that low-level stuff again. But Unity seems to have a decent higher level network available, and so far it’s proven to be pretty good. Here’s some challenges I’ve experienced.

So, what happens when you add a multiplayer feature?
Everything changes.

I started adding 2 player multiplayer support on my LD48 jam entry and it really affects everything. For example, earlier I wanted to set a wooden branch on fire, and in the game it would happen like this: I’d call a function item.setOnFire();

And that’s it. Now I had a wooden branch on fire.

Add multiplayer, and… now only server sees fire on his local machine. I cannot just instantiate fire like that. Now I need to have networkViews, I need to call RPC functions. I realize I want server to be authoritative, so I also add RPC call for “pleaseLetMeFireThisStick” where client asks server to start the fire, server instantiates fire and let’s the client know about this.

And of course I then realize that actually, I don’t need to instantiate fire as a network object. Instead I change the fire ignition code so that we only track the “isOnfire” (owned by the server) and client instantiates particles locally, and server instantiates things locally.

And this was only about fire starting. Let’s not even go talk about what happens when I want to chop down some trees and I must Network.destroy() and Network.instantiate(…) things, and then realize client didn’t yet connect so he sees a ghost palm trunk…

I hope you get the point. And the point is this: I saw the tip of the iceberg when doing a single player game. Then adding a multiplayer means revealing the whole iceberg. There’s quite of bit of slippery stuff ahead.

And I keep going
Explaining “why” on the next blog post.

SPOILER:One reason is because of unexpected things like this

It’s okay for the Indie Bubble to pop

I don’t know what “the indie bubble” is, but for me, it can pop if it wants.

Jeff Vogel is one of the two Indie Game Dev Don/Grandfather/Grand Masters that I follow very closely. (The other one is fine gentleman Chris Harris by the way). Jeff wrote a blog post where he goes through the state of the game dev… and indie bubble popping. I have a slightly different view.

Generally speaking, I agree on most of the point but this one specific thing caught my eye:

All gamers together have a huge pool of X dollars a year to spend on their hobby. It gets distributed among Y developers. X stays roughly constant (up a little, down a little), but Y is shooting up. A fixed pool of money, distributed among more and more hungry mouths.

X dollars, Y developers. That’s all that matters.

And if X stays constant, the only way to solve the problem is for Y to go down. I’ll give you a second to work out the consequences of that for yourself.
– Jeff

The missing Z factor
There’s two factors. First one is the missing Z factor. Z as in costs of development. Cost of development has sunk for indie devs. 2 decades ago you needed to build your engine. All the libs. Rendering engine. Physics engine. You name it. It took 4 years before you could start typing a design doc.

Nowadays you pick either Unity3D or Unreal and save 4 years in development. Of course if you choose to add tons of stuff, eventually the budget of your game can go up, but the point is that Making a Doom 20 years ago required tons of more work than making doom game today.

If the costs of development gets down, then X per Y (money per developer) required gets lower. This isn’t the important factor, but thought that it’s worth mentioning.

But then the more important point
X Is not constant (aka “dollars”). X is actually made of two components:

  • Number of gamers (Xa)
  • Their parents standard of living (Xb)

Number of gamers goes higher and higher every day. Yesterday there were less gamers than there are today. Tomorrow the amount is even more. And those kids are good at asking money from their parents. So, the “dollars spent by a gamer” is also getting higher. The standard of living is getting better.

This means, X isn’t a constant. X = Xa*Xb (total money = number of gamers * money per gamer) This means X is increasing.

Which means there’s room for more developers.

I’m not sure about indie bubble popping. I see a bubble getting bigger. I see games being introduces in different areas of life. Video games are becoming more part of education, and even governments are funding development of games (which further increases the X factor).

I don’t have statistics to say one way or for another, but welcoming new developers does sound pretty fine to me.

Pop or not
I’m not sure what “pop” really means…. but I think what eventually follows is this: developers start to realize that there’s hundred million 2048 game clones, and they start to think: I will do something so niche, so amazing that nobody else in the world has done. It’s for a tiny group of people, but that’s actually great. Then big companies won’t brother to compete.

Pop or not. My forecast is: We’ll see wave of games made for a very specific type of players.

Carrying an axe… (Unity object positioning)

Positioning an item correctly to player’s hand can be a problem. Here’s one way to solve the issue. There won’t be much of code in this blog post. Everything done here is happening inside the Unity editor.

So, how do we from here:
attaching-item-axe-on-ground
an axe on ground… with physics

to here:
attaching-item-6
nicely positioned to player’s hand

The plan
The basic idea is that there will be an empty game object parented to the human mesh’s hand. When we pickup objects, we disable their collisions, attach the picked up object to the carry pivot, disable default item mesh and display alternative “picked up mode” mesh.

The “carry pivot” game object
“Carry pivot” is an empty gameobject that does nothing. Just sits there dumb on player’s hand. Here I’ve used a mesh renderer component so you can see where the pink ball is. That’s our carry pivot. That’s where things go.

I’ve simply opened the character’s bip skeleton, and located where his hand is. Often unity models seem to have something like this available — check out this.

attaching-item-carrypivot
pink ball marks the carrypivot on player’s hand

Attaching the axe
Once we have the pivot available, it’s time to attach our axe. When I pick up an object, I disable the collisions (or actually, in this case I simply switch the collision to be trigger instead of disabling the collisions).

Now that looks painful.

attaching-item-axe-physics
Auch…

Some code for attaching…
At this point, here’s some code for attaching the item. Feel free to skip this if you just want to follow the plan.

We either update item’s position on every frame, or we change its parent. I’m using “update every turn” for now, since that was the fastest way to try it out for multiplayer (for solo play, I was using the “parenting” method)

(Option A) the “update axe’s item every frame” method

function updateCarrying() { // what a silly name for a function

// "carryingPivot" is the game object to whcih we attach our items
_carryingGameobject.transform.position = this.carryingPivot.position;
_carryingGameobject.transform.rotation = this.carryingPivot.rotation;
}

Another way would be to change the parent of an object. I didn’t use this piece of code since I got into troubles with multiplayer code, and at this point it wasn’t important. Anyhow, either piece of code should be just fine.

(option B) if you don’t want to update every turn, then you can use something like this

// "attach once" -- call this when picking up an object
void attachToCarrypivot( GameObject childOb ) {
GameObject parentOb = this.carryingPivot.transform.gameObject;
childOb.transform.parent = parentOb.transform;
}

Back to the plan now…

Double-axe
I thought I could survive with 1 item that I simply attach to the hand… but this caused positioning problems. I would need to adjust the “carrypivot” in order to get an axe correct… and then what happens if I pick up a wooden branch? That would be positioned badly.

I decided to go with the following option: the axe game object has 2 meshes: one for “physical object” (that can be picked up, in the following picture it’s called “dropped_axe”) and one for the “picked up mode”. So, now it looked like here:

attaching-item-axe-physics-both
Here we have both of the axe meshes visible…

And then I simply enabled the “picked axe” object when it’s picked up, and disabled the “dropped axe”.

attaching-item-6
All done!

And there we have: an axe that works as a physical object in the game, but can be picked up. Naturally this means positioning object properly in the editor.

If I had any modeling skills, I could try edit the game object’s mesh and add there some sort of “carry pivot”, which would eliminate the need for 2 models. But since I don’t have modeling skills, this trick will do – at least for a prototype.

And it works with any asset store objects.

The Infected game is now finished

Today, I’ve done something pretty cool. I’ve finalized and released my very first physical card game The Infected card game and the mobile version for android (which also happens to be my first real mobile game).

infected-tuckbox

What’s the game about?
The Infected begun as a physical card game, and that’s the main focus.

My card game is a relatively small game (can be carried in one decent sized tuckbox that holds all the 108 cards). It’s a cooperative & competitive game for 1-4 players. This means there can be one player or up to 4 players playing the game simultaneously. Before starting the game, the players can play the game cooperatively — everybody in the same team.

Alternatively, the game can be played in a traitor mode: where everybody knows only their own team but cannot tell to which team each other player belongs to. There can be one “infected” and then the remaining players are in the “human” team.

The basic mechanics include some resource control and managing (your items, allies and such) and pushing your luck (how much items you invest to build your defences this round?) and cooperation (discussing when to use the leader skill, allies, and so on). And of course bluffing & being a good traitor (hoarding good items, losing battles on purpose, using allies on bad times, taking unnecessary wounds and so on).

The digital edition (currently available only on Android)
android-demo-screenshot-thumb
There’s also an android version available that mimics the physical version as much as possible. For starters, you need to read the 17 or so pages long rules before you can play. There’s no “UI tips” and guides telling you to “place a card there”. No, instead the digital edition simulates a kitchen table. Cards are 3d objects in a space where you can move them, flip them around, shuffle them and so on.

The game doesn’t enforce you to do anything, it just provides a setting: here are the cards, it’s up to you to play with them. The digital edition is made to give you a taste what the physical version is, and to learn to rules. It works fine for 1-player games (although I guess it might be possible to play 2-3 player cooperative “pass-the-tablet” type of games) as that’s what it’s designed for.

The digital edition assists in couple of things: the bare bones setup (location of item deck, zombie deck and so on), deck shuffling and such. But the idea is that the app simulates the physical version as much as possible.

The user interface of the physical version, in my own opinion, is pretty slick and you need only 2 fingers to do tons of things:

  • You can use one finger to drag’n’drop a card
  • While moving a card, you can tap the screen to flip a card
  • If you move a card to the right side of the screen, you get to see a nice close-up view
  • If you double tap a pile of cards, you shuffle them
  • If you touch the “table”, hold down, you get to move the camera around
  • If you use two fingers to pinch (in or out), the camera view zooms

It’s been a long journey…
I started making first version of the game several years ago. It was supposed to be a “simple card game”. Eventually it became one yes, but my eyes have been totally opened by all the requirements what physical card game making requires. Testing is totally different. Typos are totally annoying. Shipping times are totally different. Everything is very different.

But, more about lessons learned in a future blog post.

Today I’m happy to announce my card game: The Infected: 22 Cards Later. Available at the Gamecrafter store (physical version) and at the Play store (digital android version).

This is pretty cool.

Wilderness survival games

I’ve been doing some hunting for wilderness survival games, and here’s some of the games I’ve encountered. Finished or in development. If you have some games to add to the list, please let me know and I can expand the list. No zombies in this list.

Rust (Open-world, multiplayer)
rust

Stomping land (Dinosaurs survival, multiplayer)
stompingland

Miasmata (Exploration, adventure)
miasmata

Under the Ocean (Crafting, exploration)
undertheocean

Before (Tribe survival)
before

Don’t starve (Resources & magic)
dontstarve

Into the Long Dark
intothelongdark

There’s also bunch of other survival game projects. For example the project Alone seems to have been abandoned. Another wilderness survival game Strive seems to be in some sort of delay trouble too.

If you know some games that should be added to this list, please let me know.

What’s the first thing to do in a survival situation?

For the recent LD48 (72 hour jam mini-game), I created a survival mini-game Under the Shade. In a survival situation, one of the important things to do is to get an overall picture of the situation (at least that’s what the buddies in tv seem to do).

That’s what I did in this game jam: I sketched a high picture view about “what possible elements there could be in the game”. It was brainstorming, so I knew 80% and more could be thrown away… but it helped me to get some idea about the theme. I thought about weather, day-night cycles, shelter building, water, food, mosquitoes and so on.

Eventually I drew this:

One very important thing for me was to type down “what is the objective of this game”? I wrote “build a signal fire when you see a ship” in the top of the page.

Then I thought about conflict, and somehow the theme perhaps got me thinking about “shade”. “Shelter building” was something I wanted to do… so here I had the 2-3 most important pieces I could start to deal with.

By observing the situation a bit, I could get overall picture and then draft a plan.

They tell this type of assessment making works in wilderness survival situations… and I guess the same can be applied to game jamming as well.

At least this time it seemed to help me out… and Under the Shade was born.

Unity and the art of game version numbers

Version numbers for me have one main purpose: identifying the version players are playing. If somebody is playing version 0.0.1.106 and reporting a bug that was fixed in version 0.0.2.391, I can keep track of things.

I had zero previous knowledge on how to do version numbers automatic in Unity, so I did the following: I created a game object where I can type version (such as “0.2.3”) and then this tiny lil piece of code adds something like “.231″ in the end. This gives me a nice little unique build number so I can somewhat compare builds.

This system adds a build number after every time you click “play”. This means if you try playing your game in the editor 3 times, each gets a new build number.

Not perfect. Not ideal. Not even useful always, but at least bit better than just having a manual version number like 0.2.3 that one forgets to change when building new things.

Here’s the updated (thanks to Mr. Reto) piece of code. Use as you please, and if you know better ways, I’m totally listening.

Attach this piece of code to a gameobject inside your game, and it should work pretty ok.

// BuildHandler.cs

using UnityEngine;

[ExecuteInEditMode]
public class BuildHandler: MonoBehaviour
{
public int buildcount;
public string versionMajorMinorFix;
public string VERSION;

public void OnGUI() {
GUI.Button(new Rect(20,Screen.height-40,200,30), "version: "+VERSION);
}

#if UNITY_EDITOR
public void Awake() {
if (Application.isEditor & !Application.isPlaying) {
buildcount = buildcount + 1;
VERSION = versionMajorMinorFix + "." +buildcount.ToString();
}
}
#endif
}