I’m a developer, ex-physicist, and occasional game designer. I’m interested in history, society, and the sciences of human behaviour, as well as technology and programming.
This is going to be a more technical series of posts. I’m going to look at what’s going on under the hood in Delugional, and some of the approaches I took to keep the code manageable.
Outside the world of games, the longstanding best practice for building a user interface is the ‘Model View Controller’ or ‘MVC’ pattern. This pattern has spawned many variants, but the basic principle remains the same. You have a ‘model’ layer, the raw information that your application is concerned with. (Eg, this puzzle has water here and some huts here, and this many hexes, and so on.) You have a ‘view’ layer, which is responsible for showing stuff to the user, and accepting input. And finally you have a ‘glue’ layer which is responsible for passing information between the model and the view. The golden rule is that the model knows nothing about the view layer, and the view layer knows nothing about the model. The ‘glue’, implemented in various ways and known as a ‘Controller’ or a ‘Presenter’ or a ‘View Model’, exists to allow and enforce this separation.
The advantage of this approach is simple and profound: you can make changes to your model without changing your view layer, and vice versa. This isn’t such a big deal in the early stages of development, but it saves you a huge amount of pain on a large project.
Does this pattern transfer to game development – or, specifically, to Unity3D development? I admit it must be tricky to apply to, say, a 3d shooter, where the ‘model’ (eg, the game physics) and the ‘view’ (eg, Unity’s rendering) are closely intertwined at an engine level. But for something like Delugional – a puzzle game with a turn-based mechanic – it’s eminently achievable. I’ll explain how I did it. Continue reading “Model-view-controller architecture in Unity”
After a long and patient labour, Delugional is released today for Android! You can download it right now from the Google Play Store.
If you like solving puzzles, or you like waterfalls, or if you like killing a few minutes on your phone from time to time, I invite you to try it out.
Heartfelt thanks to everyone who helped make this game a reality: Monserratt, for the lovingly hand-painted graphics; Yasamine, for the beautiful music and sound effects; and Rami, for his enthusiastic evangelism for the game. I’m indebted also to all the people who provided feedback at every stage of development, and particularly to the intrepid beta testers, particularly Chris, Myriam and Mark.
When time permits (and another recent release is demanding much attention), I’ll post more about the development process. Until then, try Delugional!
Delugional for Android, a handcrafted puzzle adventure, is now in beta! This means we’re looking for testers.
Screenshot 1
Screenshot 2
Screenshot 3
To get in on the beta action, send an email to dissolutegames@gmail.com with ‘Delugional beta’ in the title. We’ll send you a link to download the beta version of the game, as well as information on how to provide feedback and bug reports. If the email associated with your Google Play Store account is different from the one you use to contact us, make sure you send us your Play Store account email. (You can check by opening up the Play Store, opening the left-side menu, and checking the email in the upper left corner.)
Beta testers will get early access to the game, a mention in the credits, and our eternal gratitude. The first 50 beta testers will also receive a free promo code for the first premium puzzle pack in the game.
Hello! Long time no blog. I’m still working on Delugional, my puzzle game. As it’s (hopefully) nearing release, I want to talk more about the creative and development process.
I apparently promised, many moons ago, to talk about prototyping. Prototyping is a crucial part of game design.
Here’s the thing. You’re trying to do something new in your game, whether it’s a new mechanic you invent, or a novel combination of existing elements. That’s important – ultimately your game’s identity is whatever you put in it that’s new.
But your cool new idea might not work. Plenty of ideas that’re promising on paper just don’t turn out to be fun in practice. The history of innovation in games is littered with noble failures.
That’s where the prototype comes in. The aim is to take your risky, novel idea, and construct the simplest, quickest test that answers the question: is this fun?
I made a couple of initial prototypes for Delugional – at the time only knowing I wanted to make a puzzle game of some sort. The purpose was to find a fun ‘core mechanic’ with enough depth to build a whole game around.
I thought it could be interesting to make a game inspired by physics simulations. The first prototype took this inspiration very literally – it was a ‘simulation’ of particles that could collide with each other, and off the walls, the idea being that you ‘won’ by finding the right initial configuration for the particles to end up in their proper places.
Here’s a picture.
The red dots are ‘atoms,’ the arrows and numbers represent their ‘momentum.’ Quotes added for the sake of my physicist street cred.
You can see I didn’t sink any time into pretty graphics. I also put barely any work into the interface. The puzzles were created directly in code, and I even ‘solved’ them by editing the code. That’s all I needed to be able to explore the mechanic.
It took me a couple of days to code the basic interactions between particles, along with a dirt-simple UI, and another day or so to play around with it and reach a verdict.
The verdict? Thumbs down. Quoting straight from my notes at the time:
What I don’t see here is ‘manageable complexity.’ This is something that good puzzle games have. Meaning that the problem is complex, but breakable into smaller parts. …
I don’t see that here. I think the problem is that the simulation component places a big inferential gap between the effect the game enables you to have, and the outcome you’re trying to achieve. Solution steps are either trivially obvious (this atom’s will hit that one) or effectively unforeseeable (multiple atom interactions and multiple reflections rapidly lead to a board situation that can’t be inferred by a player from the initial configuration; that in turn makes it impossible to reason about the effect that small changes to the initial set-up will have). The latter is compounded by the fact that (in my opinion) key simulation rules are non-intuitive.
You can see I was pretty critical of an idea that I’d initially been hopeful about. That’s what you should do in the prototyping phase: generate ideas prolifically, and cull them mercilessly.
Eventually I hit upon a prototype that had legs. That’s a story for another post…
In this series I’m blogging about the development process for Delugional, the puzzle game I’ve been working on.
There a few broad choices you can make when you start to design a puzzle game. For one, you can broadly divide puzzle games into two categories: ‘authored’ and ‘generated.’ By ‘authored’ I mean a game where every puzzle has been designed by a human. Think World of Goo, or Cut the Rope, or Kami. By ‘generated’ I mean games where every puzzle you play is a fresh creation, generated in the algorithmic bowels of the game’s code. Think of Threes/2048/etc, or Minesweeper, or Dots.
In the last post I undertook to explain why language is such a big deal in Quebec, and how it lies at the heart of the separatist debate.
Let’s start by stating the obvious: language matters. Without shared language, it’s hard to carry out the most basic of human interactions. This much you know if you’ve ever visited a country where you don’t know the language.
The second, somewhat more subtle point is that language is hard. On one level this is obvious, too. But what you don’t realise as a monolingual is that it remains hard, even once you have a working grasp. We effectively take a decades-long intensive course in our native language, without ever giving it much thought. It’s very hard to match that investment later in life. In fact to some degree it’s impossible, because our receptivity to new languages greatly diminishes after childhood. (Using a language learnt in adulthood actually recruits different parts of the brain relative to languages learnt as a child.)
Consequently, operating in a second language is a challenge. Otherwise-trivial tasks cost mental effort. You make mistakes, kick yourself for forgetting a word, misunderstand and are misunderstood. You feel like your IQ has dropped. That’s the dynamic, modulated and amplified by thousands of individual experiences, that you have to imagine in thinking about the sociological import when a group of people raised on one language face economic and social pressures to operate in a different language. Continue reading “Separatism in Quebec – part 3”
Let’s pick up the story in the 1950s. At this point Canada has become an independent country, having won internal self-government in the late 19th century and claimed diplomatic independence in the 20th century.
Quebec in the ’50s was the domain of one Maurice Duplessis, a Machine-style politician who, in the words of historian Roger Riendeau, “governed Quebec as a feudal lord rules over his fiefdom.”
Duplessis’ Quebec comes across as faintly reminiscent of Batista’s Cuba. Duplessis was a conservative who stoked populist discontent at external interference, whilst he simultaneously appeased the externally-owned corporations which dominated Quebec’s economy by fiercely suppressing trade unions, communists, and other undesirables. His base was predominantly rural. Duplessis was allied to the Catholic church, still a powerful force in the province, and he championed the continuation of the church’s traditional role as provider of education and social services, against increasing pressure for the government to take responsibility for schools and social welfare.
In some sense Duplessis was fighting back the inevitable. French Catholics were pouring from the country into the metropolis of Montreal and other cities, leaving behind family farms and seeking jobs in factories and offices. There, many found themselves on the wrong side of a lingual divide. Wealth and commerce was concentrated in the hands of rich Anglophone mercantile families, or American- and British-owned corporations. Although a majority of Quebecers were French speakers, the language of business and commerce was overwhelmingly English. Monolingual Francophones were effectively second-class economic citizens.
After Duplessis’ death in 1959, Quebec was swept by the ‘Quiet Revolution,’ a rapid and profound seachange in laws and mores. The incoming Liberal party reversed the pro-clerical, anti-union stance of the Union Nationale. The government took over social services from the church, and took control of a significant fraction of the province’s bountiful and underutilized natural resources. Within a decade, Quebec looked much closer to the highly secularized, left-of-centre society visible today.
The Quiet Revolution ushered in a strain of assertivism which has remained a dominant force in Quebec politics ever since. The key issue was twofold: to attain and secure economic equality for Francophones; and to assure the long-term viability of French Quebecois culture in North America. Separatism and federalism emerged as two diametrically opposed approaches to the same problem.
Federalists sought to convince Quebecers that their concerns could be met within the existing Canadian framework. Federalism’s early champion was Pierre Trudeau, elected as Prime Minister in 1968. Trudeau pushed through laws implementing French and English as joint official languages of the federal government. Trudeau’s ‘concessions’ were unpopular in Anglo-majority provinces (the ‘ROC’) but unsatisfactory within Quebec, a dynamic which has subsequently plagued the federalist approach.
The shores of the Saint Lawrence river were settled by French-speaking colonists in the 16th-century. The chief raison d’être of the colony of ‘New France’ was the fur trade. The locals of Algonquian and Huron tribes would bring beaver furs to French merchants on the river, who paid for them with European manufactures and sold them in Europe for a healthy profit. Continue reading “Separatism in Quebec – part 1”
Outside the world of games, the longstanding best practice for building a user interface is the ‘Model View Controller’ or ‘MVC’ pattern. This pattern has spawned many variants, but the basic principle remains the same. You have a ‘model’ layer, the raw information that your application is concerned with. (Eg, this puzzle has water here and some huts here, and this many hexes, and so on.) You have a ‘view’ layer, which is responsible for showing stuff to the user, and accepting input. And finally you have a ‘glue’ layer which is responsible for passing information between the model and the view. The golden rule is that the model knows nothing about the view layer, and the view layer knows nothing about the model. The ‘glue’, implemented in various ways and known as a ‘Controller’ or a ‘Presenter’ or a ‘View Model’, exists to allow and enforce this separation.
