Joomla! 3.1 on XAMPP OS X 1.8.3 PHP 5.5

Today I toyed around with Joomla 3.1. I was asked to take a look at converting an existing Joomla 1.5 site to a more recent version because it’s being hacked all the time. Soon enough I decided that manually converting the existing site to a 3.x version was too laborious to get into, so I would try to make a fresh Joomla 3.1 install and replicate the site in that.

I started out downloading the latest version of XAMPP, as that was the most recommended package for local-hosting Joomla installs. Version 1.8.3 with PHP 5.5 is the most recent at this time. It installed without a problem. Next up was downloading Joomla version 3.1 and unpacking it into the htdocs directory.

From there the Joomla installation procedure started. I pointed the browser to http://localhost/joomla_install and started filling out the required information on the PHP pages. However, every time I completed the first page of information (on admin login and the like) and pressed on to the next page, the animated blue progress bar would show forever. Refreshing the page and trying again yielded the same result every time. I switched browsers but to no avail.

After a short web-search I came up with this link:

which in turn points to the solution here:

I seems that recent PHP versions deprecated the version of the function ‘preg_replace’ that Joomla uses during installation. Copy-pasting the two new lines into my input.php file did the trick. Too bad the Joomla installer doesn’t warn you about this kind of thing. Searching for a solution like this can be like looking for a needle in a haystack.

Recap of the GGC 2013

My visit to Gotland has come to an end. Back to the drudge of daily work, I guess. Well, maybe not so much, but the time in Visby was great fun, and I hope I’ll be invited over again next year.

Ulf Benjaminsson, the mastermind behind the conference, emailed all the speakers and jurors after the event was over, asking them to write something on their experiences and take-aways from this year’s edition. So here I’d like to outline my answers to his questions, preceded by some more general thoughts on the conference and some of the games I played.

The overall theme for the lectures this year was ‘Minorities in games’, both in game development environments as well as in games’ target audiences. I attended a couple of interesting lectures, with topics ranging from ‘Organising gamejams for girls in Palestine‘ by Andrea Hasselager to ‘A breakdown of the role masculinity plays in games‘ by Derek Burrill. I think a number of thought-provoking things were said during most of those lectures, which mostly set me thinking in the direction of ‘How can I include more target audiences in my game from the get go?’.

The student games are the main reason I attended the conference. The first years students (whom I was assigned to judge) were to work with a constraint that forced them to include a non-standard input mechanism in their game. I’ve seen my share of Kinects, dance mats and even mind-control devices for another year! Three games that deserve special mention are ‘Cobots‘, which is just downright cool, artistically well-done and innovative, ‘Tribal Marathon’, with no link that I could find (if someone knows a website for this game, let me know), which is a multiplayer competitive temple-run-a-like game, and ‘Torn’, also with no link that I could find, where you build wizards’ towers using just your mind. And it even works (well, not on me, I guess my brainwaves were on the down low during my visit).

So, Ulf’s list of questions on my takeaways from the conference:

  • The new things you’ve taken away from the conference

    Not really new, but once again good to see that the first years students designed a number of very interesting, playable and very fun games using specific restrictions (non-conventional hardware). This included getting to know how to program new input devices like Kinect sensors and dance mats, something I can imagine is pretty scary in your first year of university.

  • What you’ll re-evaluate having been here

    This has more to do with the thoughts I got after attending some of the lectures. How can you broaden your game’s target audience from the very beginning of development? Also, I’ll re-evaluate what kind of communication regarding game-related events (such as gamejams) needs to be specifically catered towards girls, in order to get a larger amount of them to be comfortable to attend.

  • What, if anything, you’ll do differently

    Not something I’d do differently, but I’ve seen being re-affirmed that input-restrictions can bring about very cool game experiences (Shark Punch, Torn, Fly or Die).

  • Three things you’d like to tell our students

    - When in your first year, don’t shy away from the control restriction (I saw a number of games did that and just used an arcade stick and buttons for controls). Now you still have the chance to experiment!
    - If I could do university all over again, I probably wouldn’t sleep for the four years in school; I’d just experiment and try to build as many different games as I can. And then, I’d keel over. Make the most of your time, you won’t have this amount of freedom when you get into the industry.
    - Finish your games! Better to skip some features and polish a little longer, but make sure the user experience is complete, well-rounded, immersive and stable.

Oculus Rift – first experience

Yesterday we hooked up and experimented with the Oculus Rift VR goggles devkit for the first time. It was first and foremost very cool. I can now finally relate to a first-hand experience with the VR goggles and formulate some initial feedback on it.

Starting out

Installation of the hardware is a breeze. This is how you’d want a consumer to setup virtual reality. A USB and DVI plug into the computer, some power to the headset, set your graphics card to clone the image across monitors and you’re good to go. Major props.


We tested a couple of applications:

Epic Citadel rollercoaster
The first demo we tried. Starting off with a painstakingly slow hoist to the highest point of the track we’re launched into a high-speed rollercoaster ride. I’ve been on a couple of real ones before, and the expectancy of experiencing G-forces combined with the immersive visuals threw me off guard almost immediately. Motion sickness was moderate at some of the tight bends but all in all very cool to race around in.

Planet 1 demo
At first glance this demo struck me as a nausea-generator, but it was actually the least discomforting demo we tried. You’re navigating around on a planet surface in some kind of hover-/spacecraft while avoiding incoming meteors. You can fly in every direction, look around you while flying the other way, do 360 loops etc. It’s great to just look around over your shoulder and see the rear side of the plane. What helped greatly here (I think) is the presence of a metal frame around the view position. When you look around you always have a frame of reference (which is similar to the rollercoaster demo; there the motion sickness is not caused by a lack of this frame of reference (the cart’s there, after all) but by the body not experiencing what you think it should, based on what you see).

Team Fortress 2
Once again the experience was very convincing. Looking down to see your virtual body holding a minigun or a bazooka is particularly nice, as is the ability to change the way the headset orientation affects the HUD and camera-behaviour. TF2 also has an in-game calibration method for setting the inter-pupillary distance. Don’t skip out on that step! It changes the image to completely fill up your own vision-boundaries and ‘pulls you in’ even more.

With this game I had the most trouble, motion sickness-wise. We played around with the different configurations camera behaviour and all that changing around, combined with the higher speed of gameplay and running in different directions than you’re looking in left me pretty sick in the end.

TF2 also makes the limited resolution of the displays apparent. Navigating the game’s menus and reading the in-game interface messages is quite hard, even with anti-aliasing up all the way and motion blur and V-sync turned off. The screen-door effect is fairly noticeable as well. Hopefully that will be changed with later iterations of the hardware. I’m also quite curious to see if that would affect the degree of motion sickness I get.


I was most surprised about the motion sickness effects. In all my history of playing games I have never experienced it before, but that turns out to be no guarantee. The resolution of the displays is also a possible optimization.

All in all I think the Oculus Rift delivers a very good virtual reality experience. Installation is very easy, the headset is comfortable to wear and we didn’t have any technical trouble with it whatsoever. We will definitely be experimenting with using this headset for one or more serious game projects.

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"