There Needs To Be Fire


Made with Unity3d. Code by me. Mixamo Fuse characters art & animations. Island asset from the asset store & free unity assets.

There Needs To Be Fire (online multiplayer version) – a spin-off of an ludum dare entry. Two shipwrecked players must build a shelter, survive on an deserted island and eventually make a signal fire. The main goal of this project was to prototype Unity’s online multiplayer networking capabilities.

View on Youtube


Very, very early coop testing screenshots

Alpha 1 build 915 screenshots

I’m prototyping my wilderness survival game. The game is aimed for 2 players, and my first goal is to create an island scenario where two lads have to survive for several days. Players will have to make choices about what they’ll do with limited time. Will they recon the island to find a better place to set up the camp? Will they hunt? Find water? Collect firewood? Players need to work together and decide what’s the most important for survival right now, and keep in mind they gotta build a signal fire to get spotted.

I’ve been using a same character 3d model for both players and I wanted to bring some new 3d models in the game. The 3d models are more high poly than I will eventually have (since the rest of the game will have lower poly models), but they’ll do for now. Here’s the first character.

I have to figure out a way to reduce the amount of polygons this guy has, now he is at 18 000 tris

I haven’t corrected item positioning for all items… and this type of things just happens. At this point I’m not too worried about fixing every item, since they are subject to change. I’ll positioning some items correctly (like the axe) just to see that positioning works OK. If it works fine for couple of items, it will work fine for the remaining similar items too.


Why bring high poly chaps in the game now?
Currently my game has a few important gameplay features: collecting items, fire crafting, shelter building. Tons of important gameplay related features are missing: rain, hunting, boiling water, inventory, packback, ropes, game related events, signal fire. All of these features will require quite a bit of time to make a playable scenario.

So, why bother with the character models when I haven’t even tested if the game is fun to play? Why there’s no simple cubes flying around?

There’s couple of reasons…
One pretty important reason for me is that I’m a sort of a “visual developer”. I like seeing some graphics as they kind of make developing more fun. Not that I’d hate boxes and whatnot, but it’s cool to see actual items and not only cones and cubes here and there. I’m very much in favor of having cubes in prototypes, but there’s some additional benefits when using actual 3d art.

I’m an Unity newbie
I’ve been using Unity now more actively this year, and I’m learning the engine. By adding 3d art I get to see all sort of issues my game has. I see drawcalls getting higher. I can see FPS ratings changing. I can learn about how terrain and rocks could use blending. I notice how my terrain texture is very blurry. I probably wouldn’t notice all these with simple objects with a shared sample material/texture.

I get to test how fast the game runs
Since I’m an Unity newbie, I have no clue how fast the game runs. By having something different than cubes and whatnots, I get more idea about how visuals affects speed. Here’s something I tested yesterday: by adding 40 guys (2 different) on the screen, my old machine went from solid 60 FPS to 30 or so. (My buddy’s computer had solid 60 FPS all the time).

Gotta figure out why framerate drops with these fellas on the screen

It just is cooler to playtest when there’s two different models, one for server and one for the client.


Now the basics of networking and items are done, and I get to continue adding gameplay elements.

Stay tuned.


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.


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:
an axe on ground… with physics

to here:
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.

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.


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…

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:

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”.

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: 22 Cards Later


Made with Unity3d. Code by me. Art by Anton Brand, music (Android version) by Kevin MacLeod 

The Infected is a cooperative card game featuring hidden traitor. A group of human survivors are fighting for their lives and gathering supplies to make an escape. One of the group members has been infected and is attracting nearby zombies. The Android version mimics a physical card game version but is playable only with one player. The physical version allows 1-4 players.

Play on Android (Google Play)

Physical card game on The Game Crafters store


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).


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)
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.