Gotland Game Conference 2013

This Sunday I will depart for Schiphol International Airport to catch a flight, via Stockholm, to pretty Visby Sweden on the island of Gotland. Each year, Gotland University’s game design department ‘GAME’ hosts the Gotland Game Conference, a multi-day event featuring various speakers but that’s really centered around the department’s students showing off their projects of the past year. Steadily growing in size every year, the conference plays host to a number of national and international journalists, educators and game development professionals who review and discuss projects with students and offer feedback, and function as a jury for the best-of-show competition on the final day.

Every time I attend I’m amazed by the high overall quality of the games the students manage to create. Here the difference between full-time game design faculties and more broad ‘multi-media’ educations (where, besides game design, disciplines like audio and video production and web development are offered) is really apparent. Big winner last year was a CCG-meets-towerdefense game Little Warlock, and I reckon I spent quite some time playtesting Secrets of Grindea as well, a JRPG with a big wink to the grinding mechanic in many MMO games nowadays.

Lots of support for this event comes form both Swedish companies and those abroad. This year’s conference features as many as 13 speakers, and a bunch of industry representatives, among whom the faculty’s resident game design lecturer Ernest Adams, of Twinky fame. I’ll be looking forward to joining them for some local beers, the presentations, lectures and award ceremony and the final goodbye-dinner, a grand medieval feast set in the ruins of an ancient tower.

All things considered, GGC holds its own perfectly well when compared to the Game Developer’s Conference in San Francisco. It might not be as big but the quality and enjoyment are certainly up there.

We’ve been invited to Gotland University before to give a guest lecture about our Wii Laparoscopy training game. There’s an article on our visit on the website of GAME. If you’d like to be informed about the Gotland Game Conference you can visit the website here, or follow GGC on Twitter at @GotlandGAME.

Talk Nerdy To Me

I’ve uploaded the sheets (they’re in Dutch, mind you) for my talk at ‘Talk Nerdy To Me’, an event about advances in web-development, hosted by NHL.

Get them here.

Even though I’m not much of a web-developer, I wanted to talk about a subject that can be both interesting and useful for a large amount of IT-professionals and students alike: rapid prototyping. Titled ‘Hyperspeed Prototyping’ the presentation focussed on a number of subjects that one can improve upon in order to make the most use of the available energy and enthusiasm when starting a new project. I wanted to point out some strategies and tools that we use at Grendel Games during 10%-time (much akin to Google’s 20% time projects) and during gamejams. How is it possible that functional, entertaining and well-polished games emerge during only 48 hours, whilst some student teams seem to have difficulty getting to that same level during 5 months of development.

The TL;DR of the talk basically boiled down to this:

  • During the initial idea-phase, don’t spend most of your time discussing pros and cons. Try to make choices quickly and channel your energy into building your choices instead. It’s much more fruitful discussing stuff you can actually play and evaluate.
  • Try to get a well-balanced team together. In smallish teams of about 5 people, there’s no room for full-time game designers or project managers. Everybody should be able to contribute assets to the final product in some way. Look for roles adjacent to a person’s skills: a concept artist might be able to make 2D sprites as well; a game designer can write dialogue, etc.
  • Pick and choose technology that matches your team’s skills, but don’t stare blindly at just what you know. Sometimes new tools can be easily mastered in an hour or two that will save you tons of time in the long run.
  • Beware the desire to build everything from scratch. This generally takes lots of time and you’ll miss out on a great many available tools, libraries and assets that can do the job just as well, if not better.
  • Last but not least, keep it simple. A great game doesn’t have to bulk in features, it requires a solid and entertaining core concept, one that you can generally realize in a short timespan. Better to deliver a working and polished product than a collection of separate features.

Vasilis van Gemert, one of the other speakers at the event, posted an article on the similarities between the topics I highlighted during my talk, and his experiences in web-development. Good to see so much overlap. I hope these views can be of use during your next gamejam or hackathon.

Unity3D fullbright shader with transparency

With all the comments in there, this thing turned out to be half a tutorial on the workings of a simple Unity3D shader. Nothing here that you can’t find in the manual, but the comments may help you grasp the interaction of all the different parts a little better.

Shader "Custom/FullbrightTransparent" 
		// This gets you a color picker in the inspector
		_Color ("Main Color", Color) = (1,1,1,1)

		// This gets you a texture picker in the inspector. Supports textures
		// with alpha channel.
		_MainTex ("Base (RGB) Trans (A)", 2D) = "white" {}
		// These tags do:
		// Queue=Transparent: Render this object as part of the transparent queue, after all opaque objects
		// have been rendered first, and renders in back to front order.
		// IgnoreProjector: This object is ignored by projectors, useful for semi-transparent objects.
		// Rendertype: Enables alpha transparency rendering for this object.
		Tags { "Queue"="Transparent" "IgnoreProjector"="True" "RenderType"="Transparent" }
		// The Level of Detail property defines what hardware will be enabled to render this material. Lower
		// LODs enable cheaper/less-capable hardware. More complex shaders get higher LOD values.
		LOD 200

		// Disable z-writing, so rendered pixels are not occluded by this object.
		ZWrite Off
		// Set the specific alpha blending state. There are several states for different effects 
		// (
		Blend SrcAlpha OneMinusSrcAlpha 

		// This pragma tells the shader to execute the 'NoLighting' function as the lighting model,
		// instead of the default 'Lambert' or 'Phong'. Use the 'NoLighting' function for full-bright
		// objects, or replace it with 'Lambert' for more common lighting.
		#pragma surface surf NoLighting

		// These declarations enable us to use the inspector's color an texture as properties in the 
		// shader functions.
		float4 _Color;
		sampler2D _MainTex;

		// The input structure defines that we will use the texture-coordinate properties of every
		// vertex that is passed into the shader (you can enable position and per-vertex color data as
		// well, if your shader uses that.)
		struct Input 
			float2 uv_MainTex;

		// This function is the surface shader. It computes the surface properties for every surface
		// that is rendered with this shader. This function operates at vertex level.
		// @param IN The Input information for every vertex passed to the shader. Contains the texture coordinates
		// @param o The output structure that contains the surface's final color information.
		void surf (Input IN, inout SurfaceOutput o) 
			// We retrieve a texel (using the tex2D function) from the texture (_MainTex) at the passed UV coordinates
			// (IN.uv_MainTex) and store the color in c.
			half4 c = tex2D (_MainTex, IN.uv_MainTex);

			// Multiply the texel color (c.rgb) by the inspector color (_Color) and store as the diffuse component of
			// the final surface color (o.Albedo).
			o.Albedo = c.rgb * _Color.rgb;

			// Copy the texture's alpha color (from the alpha channel) and store it as the surface's final surface 
			// alpha.
			o.Alpha = c.a;			

		// This function defines the lighting model. This specific implementation strips all lighting information
		// to make all rendered pixels full-bright (useful for in-game pickups/glows and the like). This function
		// operates at pixel level.
		// @param s The SurfaceOutput information from the 'surf' function.
		// @param lightDir The light's direction we can use to calculate light-surface interaction with.
		// @param atten The light's attenuation factors (attenuation is complex, outside the scope of this shader. Lots
		// of information on the webs).
		fixed4 LightingNoLighting(SurfaceOutput s, fixed3 lightDir, fixed atten)
			// Declare the variable that will store the final pixel color,
			fixed4 c;
			// Copy the diffuse color component from the SurfaceOutput to the final pixel.
			c.rgb = s.Albedo; 
			// Copy the alpha component from the SurfaceOutput to the final pixel.
			c.a = s.Alpha;
			return c;
	FallBack "Diffuse"