Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / game / Unity

Weaver

5.00/5 (13 votes)
14 Nov 2013CPOL13 min read 62.1K  
Multi-User game for AIO where players build their own spider's web

This article is an entry in our AppInnovation Contest. Articles in this sub-section are not required to be full articles so care should be taken when voting.

Application Name: Weaver
Category and Platform: Games (All-In-One Platform)    

Image 1


Weaver – a webtastic game 


Weaver is a touch-enabled game which is designed to entertain families while taking advantage of large touch screens. Each player controls a spider and builds a spider's web around leafs, twigs, and other objects on the screen to catch approaching insects and to collect points. The game stands out by it's easy to learn and fun to play multiplayer gaming in combination with appealing graphics and convincing physical simulation of the spider's web and insect behavior.  

The game and the whole development process – from creating the game concept to writing the code – was especially adjusted to Lenovo's AIO Horizon 27" and designed exclusively for this competition. In just under 6 weeks, we managed to put our idea to completion.  

The article describes the game itself, and the goals we followed during the development process to make it a successful game on Lenovo's All-in-One PC. It further describes the reasons to implement Weaver, and finally provides some insights of the development. 

Weaver   

In Weaver each player controls a spider with their fingers to build a web around fixed objects in the scene. Approaching insects might become entangled in the player's web. While the insects are caught, they can and should be eaten as soon as possible, otherwise they might free themselves, destroy parts of the web and fly away. Every eaten insect increases the number of points for the player. The player with the highest score wins the game.  

Players can choose between three distinct levels, all of them with amazing graphics, but different in their appearance. The first level is a scene in woods, where the players weave the webs between leaves and twigs. The second scene shows a snow-white landscape with some snowbound juniper berries, while the third one is a scene of an attic with clothesline, chairs, and nails to fix the web in the game.  

Image 2Image 3Image 4

The game further implements a complex web building mechanism: Due to the lack of spider web building skills in human's experience, we integrated an algorithm to automatically form a more naturally looking web from the user's input. Therefore, we analyzed webs of real spiders and the physical behavior of strings when they get connected. The result is a much more natural experience. 

Image 5 

Goals     

Before we started the concept of the game, we have agreed on a set of goals for the final application. They provide the foundation for the following stages and ensure the best possible user experience for a large touch screen by focussing on a gripping gameplay, intuitive interaction patterns, and awesome graphics.

  • Dynamic Player Number and parallel playing. The whole family should be able to enjoy the game together and in parallel. While there are physical restrictions (the space around the tablet) and technical restrictions (only ten fingers can be detected simultaneously), we wanted to design a game without further limiting the player count. Hence, the gameplay needs to be suitable for one and up to ten players. 
  • No Interface Orientation. Opposed to applications on a normal display where we know top and bottom according to the user's perspective, the players stand around the table (see figure below). Hence, we need an application which is orientation free and can be perceived in the same quality from every side of the tablet. Obviously, displaying text is getting more complicated if not impossible. Another problem we need to tackle is the perspective of scene objects since the game should be three dimensional.   
  • Avoiding Interface Elements. Another goal is a highly intuitive game without disturbing interfaces to plainly display information or giving hints to the players. Necessary data like score or remaining time should be illustrated by other methods integrated in the gameplay. 
  • Game Modes with different Types of Complexity and Timings. Our game is supposed to be for everyone, including small children with their parents or more experienced players. As a result, the game needs flexible mechanics to motivate beginners to play this game, while keeping it interesting for more advanced players. 
  • Intuitive Touch Patterns to control Game Objects. That's surely a logical consequence of designing a game for large touch screens, however, we want to mention it here because it is one of the points everyone of us is keeping in mind during development process. Our goal is a grade of intuition which does not require any additional instructions to play the game. 

Image 6
Views of the tablet from different perspectives 
Views of the game from different perspectives. We do not want a fixed orientation, so no player is visually handicapped. Therefore, elements like text have to be used sparingly or not at all.
 

Decision for Weaver  

At the beginning of the design process (a couple of days before the first round's deadline), we collected some ideas for a suitable game on Lenovo's Horizon Tablet, ranging from games of skill to real world simulations or some kind of finger twister. Finally we discussed ten different game ideas. The final decision was made for Weaver since most of our goals were reflected in this idea, as further explained in chapter "Gameplay". 

Weaver suited best for our goal of a game where the whole family can come together to play: It is easy to learn due to intuitive gestures and it is independent from people's location around the table, since the spiders which are controlled by the player can move all over the tablet. Additionally, any number of players can participate by adding more spiders and insects to the game. Finally, it was a game which does currently not exist in this form. 

Image 8 
Gaming scenario. All family members can play together - there is no upside-down GUI in the way, Weaver is playable from every side of the AIO, one can even easily change location while playing. 

Design & Development  

This chapter reports about us as a team and our progress during all phases of development. The main development platform was Unity3D with its easily accessible graphics and asset framework.   

Team 

Our team consists of three people. Two of us each have five years of experience in the field of game and interaction design, one of us is a developer and software architect for seven years. We all have deep knowledge in development of mobile apps and responsive software in general, especially using novel interaction schemes and creating experiences for our customers.    

Examples of our work include: 

  • MohWorld (multiplayer gaming universe for smartphones utilizing device sensors), yet unreleased 
  • Metaworlds (interactive athmospheric world building) 
  • Iterazer (generative art for Android, multitouch, multiuser) 
  • GyroDroid (most popular Android sensor framework for Unity3D) 
  • Lichtbar/Raumfrequenzen (projection mapping with public collaboration using a multitouch control interface)  

Concepts   

Concepts are the results of our ideas under consideration of our goals. Not all of them are reflected in the final game, but they build a suitable set of ideas to tackle some main issues of the game. Most of them are created by hand on a piece of paper in dozens of sketches. This section displays a few of them to provide an idea how we started to work. 

Interaction Patterns  

Menu

To start a game, the players must specify three parameters: the difficulty level, the time, and the number of players. The figure demonstrates some thoughts about the selection, which can be done by every player around the table without preferring any player by an orientated interface. 

Image 9 
The players can move their favorite spiders to the center. The level can be chosen by swiping left and right.  

Spider Web 

The spider web should behave in a realistic manner. E.g. if silk is attached to an existing string, the existing string becomes bent. Hence, we are able to create more realistic webs than by just attaching the strings 

Image 10 
Bending the web when a new string of silk is attached. 

Gameplay  

Level Cycle 

The players have a set amount of time (default is 2 minutes) to construct their web and catch approaching insects. Depending on the dimensions and structure of the web, some insects are caught, others just pass the web, and yet others destroy parts of the web. Inbetween, they have to make sure to repair and extend the web. When the time is running out, which is visually shown by a day-night-cycle, a results screen is shown and the winner is selected. 

Depending on the length and difficulty of the level, we plan to have multiple types of insects. Some of them are weak and easy to catch, others are huge and give additional points. 

The spiders have a limited amount of silk to build webs. This is regenerated slowly, however, each eaten insect gives a little amount of additional silk to build more web. 

Eating Caught Insects 

Image 11
Process of treating a caught insect. The player can move the spider to the insect which gets eaten (maybe the spider needs to wrap it in silk before and wait some time). If the web is to weak or the player is to slow, the insect can free itself and destroys parts of the web.  

Design

Graphics 

One of the most important issues in a game are the graphics. This section discusses some approaches we made. 

Spiders 

Spiders are the most important unit in the game, since the game is all about them. We tried to make them perspective free, to be able to give them emotions (for expressions like "eating foul insects", "starving", "dying", or "winning"), and let them walk smoothly. The following sketches demonstrate some approaches to fulfill our requirements: 

 Image 12
Some first approaches to design the spiders.

Image 13 Image 14
Image 15

Modeled spiders which can be personalized by changing the body part sizes and colors. The position of the mouth and the eyes are a useful tool to express emotions as demonstrated in the video. Also, different eye configurations create different emotions.  

Sound and Music    

To create a great game, good music and sound design is essential. We got help on this side from Christian Freitag, multimedia and sound designer. After we talked with him about the base mood (very light, cute music), he created several different versions from which we selected the most fitting one. He refined it and created a menu loop as well as songs for the different levels and sounds for game events, such as winning. 

Image 16

The Weaver theme, composed by Christian Freitag (Link to Midi file

Development 

This section provides an overview of some problems we had to tackle during the development process.

Installer 

An instruction to install the application in Lenovo's Aura Environment was given by Intel and Lenovo for Visual Studio. We decided to use the Open Source Installer NSIS, since it is convenient to use, small and free. It isn't rocket science to follow Intel's instruction set, however, we got some issues since we're not doing these things frequently (e.g. finding the HKLM for 32bit applications on a 64bit system). In case you want or need to use NSIS for your project and you need the scripts, just drop us a message.

Application 

We are developing the game itself in Unity3D which is a powerful tool for scene creation. It enables us to manipulate the game elements very fast and to evaluate prototypes, also we can easily export them to Unity's Web Player which allowed us to let remote testers try out new features and give direct feedback. 

Using Unity3D in combination with PlayMaker   

We used finite state machines for handling the more general parts of application logic. PlayMaker is a Unity extension which allows for rapid development and yet is as extensible as it needs to be. The gameplay elements (web building, spider movement, ...) however are implemented directly in C# inside of Unity. 

Building our own Shaders 

Unity has a lot of integrated materials, however the look we were going for wasn't really possible with them. That meant that we had to implement parts of the shaders ourselves, achieving effects such as rim lighting, lighted leaves or adapting the time (day/night) by using postprocessing shaders.  

Creating 3D Models, Animations and Textures with Autodesk 3ds max  

All scene elements are modelled and textured using Autodesk's 3ds max. Special attention was made to ensure realtime compatibility of the models, reducing the polygon count down to the visually needed minimum.  

Building The Web  

The web attachment algorithm is supposed to create a web which looks as natural as possible. We splitted the silk string on the newly attached position and pull into the direction of the new string, depending on the length of the three interbreeding strings. An example can be seen here. The colored spheres represent the spiders and can be moved via mouse clicks. The white spheres represent the insects which can currently not be caught.  

Image 17
Click on the image to open a playable version 

The web building uses a combination of verlet integration and custom made algorithms to achieve a realistic look and feel. By modelling a string as a connection between knots and careful handling of all edge cases (knot-string, knot-knot, knot-branch; cancel weaving, split strands, end weaving and so forth), we have achieved a very intuitive way to weave a web. But the algorithm had not only to work for creating realistic spiral webs, but also if the user decides to i.e. just zigzag around and still stay robust.

Although implemented and technically possible, we decided to not use animated end knots (for example, silk strands attached to moving branches) for performance reasons. 

In the game options can be selected whether a created web can be conquered by another player. This can be achieved by the player attaching to an existing strand, which creates an interesting twist of gameplay.

Here's a (slightly reduced) code sample of the different modes and cases of web creation: 

C#
public class Strand : WebPart {
	// strand is always connection between two knots
	public Knot a;
	public Knot b;
	
	// ...
}

public class Knot : WebPart {		
	public bool isFixed;
	public List<Strand> strands = new List<Strand>();
	
	// ...
}

public class Web : MonoBehaviour {
	public List<Knot> knots = new List<Knot>();
	public List<Strand> strands = new List<Strand>();
	public Spider owningSpider;

	// update knots and strands and their constraints
	void FixedUpdate () {
		foreach(Knot k in knots) {
			k.ResetForces();
		}
		foreach(Knot k in knots) {
			k.RunFixedUpdate();
		}
		foreach(Strand s in strands) {
			s.ConstrainKnots();
		}
		foreach(Knot k in knots) {
			k.UpdatePosition();
		}
	}
	
	Knot SplitStrand(Strand s, Vector3 point) {
		// create knot in the middle, replace strand by two
		var k1 = CreateKnot(point);
		var s1 = CreateStrand(s.a, k1);
		var s2 = CreateStrand(s.b, k1);
		
		knots.Add(k1);
		AddStrand(s1);
		AddStrand(s2);
		
		RemoveStrand(s);
		
		return k1;
	}
	
	public Knot Connect(Strand s, Vector3 point) {
		// remove strand, create two new strands with knot in the middle
		var k1 = SplitStrand(s, point, newParts);
		var k2 = CreateKnot(point);
		var s3 = CreateStrand(k1, k2);
		
		knots.Add(k2);
		AddStrand(s3);
		
		return k2;
	}
	
	public Knot Connect(Knot k, Vector3 point) {
		// create new knot and a strand between them
		var k2 = CreateKnot(point);
		var s = CreateStrand(k, k2);
		
		knots.Add(k2);
		AddStrand(s);
		
		return k2;
	}
	
	public void RemoveStrand(Strand s) {
		// remove strand from knots, remove strand
		s.a.strands.Remove(s);
		s.b.strands.Remove(s);
		strands.Remove(s);
		
		s.Destroy();
	}
	
	void AddStrand(Strand s) {
		// add strand to knots, add strand
		s.a.strands.Add(s);
		s.b.strands.Add(s);
		strands.Add(s);
	}
	
	public void RemoveKnot(Knot k) {
		// remove knot and all attached strands
		knots.Remove(k);
		for(int i = k.strands.Count - 1; i > -1; i--)
			RemoveStrand(k.strands[i]);
		k.Destroy();
	}
	
	public Knot Connect(Vector3 point1, Vector3 point2) {
		// connect two points with a strand, create knots at the ends
		var k1 = CreateKnot(point1);
		var k2 = CreateKnot(point2);
		var s = CreateStrand(k1, k2);
		
		knots.Add(k1);
		knots.Add(k2);
		AddStrand(s);
		
		return k2;
	}
	
	public Knot EndConnect(Knot k, Strand s) {
		// split the strand and end the webbing here
		var k1 = SplitStrand(s, k.transform.position, newParts);
		return EndConnect(k, k1, newParts);
	}
	
	public Knot EndConnect(Knot k1, Knot k2) {
		// find strand for k1, remove strand, keep point k0 that is not k1
		// add strand from k0 to k2, return k2
		Strand s = k1.strands[0];
		var k0 = s.a == k1 ? s.b : s.a;
		var s1 = CreateStrand(k0, k2);
		
		AddStrand(s1);
		RemoveStrand(s);
		knots.Remove(k1);
		k1.Destroy();
		
		return k2;
	}
	
	public Knot EndConnect(Knot k, Vector3 point) {
		k.transform.position = point;
		
		return k;
	}
}   

Slightly reduced code for web building which shows the different modes and cases happening there.  

Achieving High-Performance using the dedicated Graphics Card 

The Lenovo AIO platform is, from a technical point of view, a laptop: it contains both an integrated graphics card (Intel HD4000) and a dedicated graphics card (GeForce GT620M). By default, the integrated graphics card is used, which is not bad, but way less powerful than the dedicated one. So we decided to implement automatic profile generation, which means that on the first start, Weaver creates a NVidia settings profile to enable the dedicated graphics card. This about doubles the framerate and helped us to achieve effects such as depth of field and fullscreen color correction. Of course, power consumption is higher, although we found that about 2 hours of use remained. 

Testing 

The complex algorithms of web building and spider movement were thoroughly tested with different settings to cover as many edge cases as possible. It's still not bug-free, but the remaining problems are quite minor. 

Like for any project, we need to ensure that our original design goals are met, that the user interface is easy to use and players actually like the game. Especially for Weaver, we had to additionally make sure that the game works for up to ten players.

For this, we made numerous tests with both people who already know the game and people never having seen it before. The portable nature of the AIO platform was of very great use for that - whenever the opportunity was there, we asked for genuine feedback and, probably more importantly, observed usage patterns and deducted what we had to change from an interaction point of view. The final version was successfully tested with a group of eight random people without any introduction at all.  

Known Issues   

  • Spiders can be dragged on neighbouring levels in level selection view. 
  • Very seldom some strands "explode" and visually obscure the screen when more than six players simultaneously weave. 
  • If spiders are sitting very near to each other, touch inputs may not be assigned correctly to them. Clicking somewhere on the own web causes them to move there and thus fixing the issue.
  • Insect's movement isn't very appealing, there might be more different flight patterns.
  • More types of insects with different capabillites.  

 

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)