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
}

Unity & lurking in the shadows

The key feature for my Under the Shade (LD48 jam entry) was to make player be under a shade. I used two strategies. There was areas called “shade”, which were meant to provide decent shade. Not optimal, but something that stops dehydration (a feature that never got in the game due time limits…). This type of shade could be found under the trees or near big rocks. Another type of shade that I called “good shade” in the game. The “good shade” would be possible if there’s “something on top of a character”.

First I had trouble figuring out how to determine “if I’m under the shade”, but then I figured out a very simple solution: I clicked “create sphere”, and made the “collider” to be a “trigger”. Then I placed the shadearea to the place where I wanted to be. Here for example, I placed the area where the shadows are:

After that I placed a script called shadearea.cs to each shade area game object. For my purposes, I didn’t want this object to do anything except to inform when something enters or exits. So I basically wrote this (with the silly IF-statement, that should be got rid by for example ensuring that “player” is the only gameobject that can collide with the trigger).

public class ShadeArea : MonoBehaviour {

	void OnTriggerEnter(Collider other) {
		if (other.gameObject.tag == "Player") {
			other.gameObject.SendMessage("enterShade");
		}
	}
	void OnTriggerExit(Collider other) {
		if (other.gameObject.tag == "Player") {
			other.gameObject.SendMessage("exitShade");
		}
	}
}

After this, I could do something with the information (like make it so that player’s hydration value would be changed).

Naturally this approach was done for a jam entry, and there’s some obvious issues:
- If the position of the sun changes, the shade area should move. This could be done by checking out the central point (when the sun is highest) and then rotation/moving the shade area. Or we could just ignore this. Or we could do something else.
- Collision could inform “gameplayManager” or something like that, instead of the player. And the gameplayManager then could tell other objects that “player is in shadows” or not. This would be needed if there were other people in the game.
- I placed the shade area manually. Since I had only 2 of them in the game, I could handle. But if I was to create a random scenery or have 100 locations, I would definitely need to make the shadearea part of the gameobject.

And probably other issues too.

Since I didn’t have the time to make use of the feature (I dropped away ‘hydration’ feature since I had no time to test it), so the ‘shade near objects’ feature was dropped. But at least I learnt something when doing, and now perhaps this blog post helps somebody else in their projects.

18 hours later…

I finished my Ludum Dare entry “Under The Shade”. I once again had huge ambitions on what kind of game it would be. I drew an island, trees, rocks, thought about fishing places, fire system, cliffs, rescue signals… and realized that this would take 48 months or so to complete. (and not 48-72 hours as the contest requires).

So I did it anyway.

I know that ludum dare is a prototyping contest, where graphics should be… cubes and whatnot. Of course I didn’t want to have just grey cubes. I used some free assets in the asset store, and some assets I had lying around in my computer. To me it was important that the game also looks something else than cubes.

I did three things correctly:

I wrote a todo list
Since I had very limited time, I needed a clear plan on what to do. I made a brief list and moved things around. I divided my TODO into about 10 item lists, and wrote to each section “why” or “what’s this about”. Here’s a some of my todos…

It’s a huge motivational factor and keeps you focused on what I’m going to do.

--------------------------------------
TODO: you can start a game play it 
-------------------------------------------------------------

DONE - map: island (terrain, sea, some random trees)
DONE - map: collectable branches
DONE - terrain grass
DONE - item: matches on the beach
DONE - item: axe on the beach
DONE - make it possible to gather dead wood
DONE - possible to start a fire (needs small wood pieces)
DONE - place palm tress so that you can also collide
DONE - check what items there should be


-------------------------------------------------------------
TODO: Better torch & fire system
-------------------------------------------------------------
- get stick on fire by placing it to a campfire: if stick is "carried" and is "on fire", then we generate a fire to one end of the stick and it becomes a new fire. Fire won't spread otherwise, only when you carry it away from the campfire
- flame system: 3 size of fire, small, medium, big
- flame system: palm leaves make fire "smoky"
.
.

I playtested my game…
First I thought the game would be more about survival under the sun, but I had such a fun time trying to make a nice shelter that I eventually gave bit more attention on that. I had planned so that you could lose the game, but that didn’t feel right in the very last moments of the challenge… so I took it away.

Now the game is about building as good shelter as possible, and then doing a signal fire when you want to end the game.

I cut away majority of the features
I had planned the gameplay a bit, so that there would be more choices to be made. Alas, those features simply didn’t make their way to this minigame. There’s no beasts that hunt you. There’s no more hunger (although banana plant and a banana can be found on the isle). There’s no fishing. There’s no finding water. There’s just the shelter building so that you can get under the shade.

There really wasn’t any other option since I had no time to add those features.

I was persistent
Yesterday I was very tired and I slept 21-24 or so and woke up. I was thinking that “LD ends in 3-4 hours, I need sleep… I’m not going to release this”.

I got up and thought… “I can finalize this game in one hour, and it’ll be good”. I pushed myself to get to coding. After 2,5 hours I was done & uploaded the game. (And still got nice sleep between 3am and 7am)

I have mixed feelings about the entry. It does not have the “make meaningful choices” aspect in the scale I wanted there to be. There’s quite little “resource management”. It has bit of “exploration” and bit of “shelter building”.

And… there’s “fire making”. Sort of.

Over and out
The first 16 hours or so making this game was pure fun. I tweeted, I posted pictures, even put lil bit of Unity code out… so that alone made it worth participating.

The last 2 hours to submit the game to the contest was not bad either.

I didn’t collect all the achievements, but I think this was pretty ok gig for me.

Under the Shade is available at the ludum dare site (windows, mac, linux, web versions).

LD48 jamming: auto-screenshot taker

// script name: ScreenshotHandler.cs
// how to use: make a gameobject and attach this script into it
// now every time you launch your game, it takes 
// one screenshot after 5 secs have passed

using UnityEngine;
using System.Collections;

public class ScreenshotHandler : MonoBehaviour {

	private void capture() {
		Application.CaptureScreenshot("screenshots/screenshot_"+System.DateTime.Now.ToString("yyyy_MM_dd-hh_mm_ss") +".png");
	}

	private bool _takeStartScreenshot;

	// Use this for initialization
	void Start () {
		_takeStartScreenshot = true;
	
	}
	
	// Update is called once per frame
	void Update () {
		if (this._takeStartScreenshot == true && Time.time > 5.0F) {
			// take a screenshot after 5 secs have passed
			this.capture();
			_takeStartScreenshot = false;
		}
		if (Input.GetKeyDown(KeyCode.F12)) {
			this.capture();
		}
	}
}