Game DesignPosted by Anders Højsted Tue, September 02, 2014 12:11
I've uploaded a small aMAZEd
"gameplay aperitif" - it's a small level to show one of the different gameplays in the game.
Gameplay isn't about how you play the game, but how the game plays you.
It is meant to whet your appetites and maybe leave you wanting for more.
You can get it here:
The picture is interactive :)
It is unfortunaly an EXE-file so your computer needs to be able to run those.
Bon Appétit :)
Game DesignPosted by Anders Højsted Sun, October 24, 2010 14:12
Isn't it beautiful?
Game DesignPosted by Anders Højsted Fri, April 16, 2010 14:27
I'm working on a small game in GameMaker called "Try/Fail".
It's a small non-commercial art game about a philosophical/existential issue. I won't reveal to much about the content of the game; you'll have ample opportunity to play it yourself when it's released.
(...and art shouldn't be explained; - it should be experienced and interpreted. Interpretation is an important part of this game).
Instead I want to talk about game development.
From all I've learned that best way to make games is to do rapid prototyping. Most games have some sort of essential experimental feature - usually an rules-mechanic or a game-mechanic - and it's important to test ASAP it you can make it work and if it's fun.
So step one is to define that feature, build it and test it. To do so rapidly, you can make a bare bones prototype with placeholder content and one the minimal amount of interaction implemented.
The essential feature in Try/Fail is that the avatar changes as you progress in the game. This is really, really simple and should be easy to make.
I'm tried to make a prototype a while back, but soon hit a wall of incompetence. No matter how I did it, the avatar wouldn't change. I posted on the GameMaker forums and got a reply. Except it didn't work. So I started doing something else instead (<- this is in some way that story of my life). Not being able to make it work made me mad and made me feel incompetent.
A while back I got annoyed by the lack of progress that I looked at it again. As you can see at the gamemaker-thread, Sythus writes "if value = 2 instance_change(object2,1) ". I then write "if score = 2 instance_change(object_avatar_1,object_avatar_2 )". This <b>isn't</b> the same; the order of the object is reversed, so the initial object is second and the second object is first.
Anybody who have done programming knows how important to do it absolutely correctly. The advantage of computers is that they do exactly what we tell them to do; the disadvantage of computers is that they do exactly what we tell them to do.
So I fixed the code and made it work. The prototype is now functional, except for some minor adjustments.
Here's a screenshot of the first (and only) level in the game:
Riveting, ain't it?
The turquise block in the center is the avatar; the "1" is a to show that it's the first avatar in a succession of avatars (1->2->3). The black blocks are solid; the burgundy blocks can be dug away. It will (hopefully) makes sense to you when you play it.
All of the art is placeholder art and all the audio in the game is audio clips that I gotten from the web. I have an work-ethos of doing everything myself, so I'll have to re-record all the sounds (except the recording of classical music; can't do that). Audio is a very important part of this game.
And I'll have to do the graphics.
But the next step is to test the game on unsuspecting victims; girlfriend, friends, family, other gamedevelopers....can they make sense of the interaction?
The picture probably goes to prove one of my points in my earlier post: if you "release" your game too early to the public, people will feel disappointed about it. In this case because of the graphics. I wanted to post it for people to see an prototype and later to be able to compare with a screenshot of the game with the full graphics to see the progress.
More to come....
Game DesignPosted by Anders Højsted Mon, December 14, 2009 11:02
It's been a bit quiet in here; I've been busy with the Nordic Game Jam 2010
, looking for jobs and making games.
On top of all of this, there's the COP15 meeting
in Copenhagen, so there's demonstrations and events all over town and some of the public transportation is not working (I couldn't get a bus saturday, - they were full of people going to the big demonstration, - 100.000 people). And my leftwing friends are getting arrested for participating in peacefull demonstrations. Life is a bit crazy in Copenhagen these days; there's people from all over the world here which is amazing and wonderfull, - all we need to do is to keep the demonstrations peacefull.
Now about the games:
Evolution: Fitness has been a bit on hold. Chris Hecker's talk about the "why in games" (as in "why do I want to make this game")
made me think about a lot of stuff. So I got an idea for a different game (called Try/Fail), that I just wanted to make. Unfortunally I underestimated the effort required to make it, so I've been working on it for a while now. It's a really small game but some of the gameplay seems to go against what GameMaker can do, so I'm struggling with it.
However, I've had a dream. I've had this vague idea about a game about reality for a while. It's partly inspired by the concept of consensus reality
. Consensus reality is the idea that the reality(:what is real) is based on what we can agree on. This is epistemologically & ontologically false; reality doesn't care about what we think about it. Well, physical reality doesn't. In social sciences you have the concept of socially constructed reality; - that our perception of the world (and according actions) are based on a socially constructed language that shapes or perception. Right?
(Ok, here's a funny exercise: find 3 words that describes the same behaviour, but with different values attached. Examples could be terrorist, rebel, freedomfighter or stingy, parsimonious, thrifty (you can find a lot of inspiration in thesaurusses). Each word changes your perception of how the person is).
Now, the idea for the consensus reality game is that you handle the challenges in the game by changing your perception of reality in the game.
I wrote the idea into X
and realized that I used the verb "shifting" (as in "shifting reality") for the basic gameplay-mechanism in the game. Somebody (either Chris Crawford or Greg Costikyan) pionered that concept of gameplay-verbs; verbs that describe the gameplay. I haven't seen any other games that uses the verb "shifting" to describe the gameplay.
Which leeds me to the interesting: can we reverse engineer this process and come up with new forms of gameplay by using new verbs? (After all: there's plenty to take from
; go now, - innovate!)
Game DesignPosted by Anders Højsted Wed, November 18, 2009 15:45There's a Gamasutra-article on Chris Hecker's presentation at the Montreal Independent Games Festival about art, games & the industry (read it for yourself):
Most importantly "..he spends a lot more time considering and discussing the "why," as in
"Why do you make games?" It's a question he believes is crucial not
just to individual developers, but to the cultural impact of the entire
medium for decades to come.
Why Ask Why?
Those who work in certain popular forms like music, film, and
literature often reflect on how a particular work was born out of a
specific event. "I had to write this book when my girlfriend dumped
me," a novelist might say."
This is very important; art is many things, but it usually relates to and communicates something about (aspects of) the human condition. It usually relates to the perceiver and forces him/her to reflect over their own condition.
So if people have an ambition about their games being more then just entertainment, they should ask themselves "why do I want to make this game, what is my personal existentialist reason for doing this? what do I want to communicate about my own current condition?".
It made me ask that question about Evolution:Fitness: "why do I want to make it?".
The answers is that I want to make Evolution: Fitness because of the whole debate about evolution and creationism. The purpose of the game is to teach people about one of the fundamental mechanism in evolution: the biological adaptation to an enviroment through mutation.There's a lot of misconceptions about evolution and Evolution:Fitness might help people understand things right.
It seems to me that when people debate these things, they don't understand each others positions, so everybody is attacking strawmen. If the creatists understood evolution, they might also understand that religion isn't 100% incompatible with science, even though a 100% literal interpretation of the old testament is.
So I hope to increase understanding for evolution.
Evolution is a very important theory and the understanding &
application of it has benefitted mankind immensely. Science is
important to understand the world around us and manipulate it so we can
diminish human suffering and increase the general quality of life for
people (yeah, I'm getting a bit utilitarian here).
Game DesignPosted by Anders Højsted Fri, November 06, 2009 10:23Here's the first version of the Evolution: Fitness design document
The design paradigm for the game is that it has very few rules that creates a complexity that is interesting. A sub-set of the design paradigm is that the rules of Moving, Mutating affords for direct interaction with the gamestate (:moving a piece directly) while the rule of Breeding affect the conditions for automatic interaction where the game will act, the player controls the interaction indirectly by setting up conditions for it. It could be interesting to create a game where the player only could indirectly act with the game, - where he only could affect the conditions for interaction and the game would do the actual interaction.
I had a hard time figuring out what kind of format I should document it, but eventually decided to do it as a game-manual without flavour text or gameplay-examples. I've written it and read it through once (maybe twice) and corrected it. It's very raw. Remember: the purpose of this exercise isn't to present you with a finished product, but to document the process.
(It raised the issue of iterations: when is an iteration done? when is each phase of the iteration (design -> test -> evaluation) done? Right now all phases takes place in my head; I decribe a design, visualize a playthrough and evaluate the playthrough, so the only way I can define iterations as discreet entities is by being meta-reflective about my mental activity).
(Note to self: parts, whole, level of zoom).
Some things are readily apparent with the document. This is not a satisfying way to describe the game, - it's very abstract and it takes a trained designer to actually understand what is happening. I'm thinking about writing some playthrough-examples to example the game and will also add graphics as I move along (a picture seriously is worth a thousand words).
Feel free to download the design document, comment on it, test it and elaborate on it.
If you want to send me a commented version, send it to firstname.lastname@example.org.
All feedback is appreciated.
Game DesignPosted by Anders Højsted Sat, October 31, 2009 12:24
I responded to a debate on Gamasutra about David Surman's presentation at the gameconference GameCity: 'Game Designers Are Undervalued'
(David Surman is Senior Lecturer at Newport Art School):"Game Design is a independent design desciplin that can be taught. It's a subset of interaction design, which have been around for ages. Anybody who wants to claim that they're de facto game designers should know at least the basics of interaction design & game design (Start with Rules Of Play). If not, then you're just a programmer/tester/producer/gfx artist with a new label on your business card (and likely to cost your company money by doing unessacary iterations or creating inferior products).
Game design (if taught correctly) is just as demanding as programming and the products are every bit as tangible as programming; - mainly as design documentation & creative direction during the development.
Unfortunately most of the game industry doesn't understand this as the usual way of doing things have been to promote selftaught employees to designers, based on their "ideas" (or more often: their trackrecord in other postitions in the company). Some of them have succeded, but the vast majority (around 99% of the projects) have failed miserably. Those that have succeded have done so through massive amounts of costly iterations. The whole idea of selftaught designers and that "game design can't be taught" should be obliterated from the games industry ASAP.
There's a huge difference between being able to tell if a existing game is good and whether a game concept (not an idea!, - a full concept!) is good. Good game designers are able to analyse how likely it is that a game concept will be a good game. A good game designer can scrap a design even before any documentation has been made and he will be able to tell you exactly what didn't work and why.
I know that a lot of people feel that they can do design based on their experience from other fields in the industry, but that's like believing you know how to fly a plane because you've been passenger on one"
The best designer would off course have a interaction/game design design education with added experience from the industry. He would also have to be a reflective practitioner.
Game DesignPosted by Anders Højsted Sun, October 25, 2009 18:48
been a bit unsatisfied with the last blogposts about Shadows Of
Europe and Students Massively Multiplayer Online Game. It took me a
while to understand what the problem was: they remind me of corporate
PR-interviews. They only deal with the result of the designprocess
and very little with the actual process. Please bear with me.
is the process of shaping of a given material into a form according
to a set of specifications. The form is the "design". The
specifications can vary a lot, based on intended use,
target-audience, type of design (eg digital game), material,
available ressources and (probably also) a lot of other variables.
design games, we create an interactive experience by creating rules,
and a way to interact with them. When we create digital games, we
imbed the rules in software. The game is the rules, the interface is
our way to interact with them and we (usually) program the games to
make them more accesible to a larger audience.
recommend Robin Hunicke, Marc LeBlanc & Robert Zubek's article
"MDA: A Formal Approach to Game Design and Game Research"
for an introduction to the distinction between rules (:mechanics) and
is a process where you start with an idea ("wouldn't it be cool
if...") and build it. Usually when you've built and playtested
it, you find out that it isn't quite doing what you want to; it isn't
quite the experience you were looking for. So you have to redesign
it. And test it. And re-design it. This leads to the iterative cycle:
(Re-)Design -> Test -> Evalutation.
more about iterativ development here:
Iterative & Incremental Development)
are made between and in each of these stages. And for a outside designer,
these choices are the most interesting parts of the process. You
can always hear about the inital idea and you can always find out
what the process ended with by using the final product, - but you
can't really hear about why
the product ended up the way it is anywhere.
(One way of covering the
process is to have a design-log where you document designs and note
changes; they're good for gathering info about the process but are
rarely made public. They also need someone to put the content in a
context if outsiders are going to comprehend it).
Designers rarely talk about these issues. Partly because
it takes time from the designprocess, but also because it reveals
where you make mistakes. Often you'll have an brilliant idea about what will make billions, but after testing&evaluation you'll have to give it up, -
and all of the sudden your Magnificient Feature (tm) ends up on the
floor in the design lab. If you have a professional pride and have staked your
professional skills on this feature, this bites. Hard. No need to
launder that dirty linnen in public (Besides, everybody say that it's
ok to fail because failing is learning experience, - but nobody
rewards it). Everybody makes mistakes but nobody wants to talk about; it's a bit like sex.
However, if you don't talk about it, you can't get
feedback on it. The problem with the SoE-post and the SMMOG-post is
that I don't talk about the justifications for the features that we
did/didn't decide to do (like not naming the biggest company in
Scandinavia "Viking" or the compromise of using Interlock
as the foundation for the design in SMMOG).
However, talking about the process - especially while
it's taking place - has two major advantages: businesswise it
generates PR, but most importantly: it generates feedback. If you
take each design-phase, make the design public and ask people for
feedback, integrate the feedback, have people test your prototypes,
gather their feedback and re-design according to their feedback,
you'll a) get more feedback on the project, b) have it tested more
extensively, c) get more ideas for the design & d) give the
customers a feel of ownership with regards to the final product.
These are all good things.
(In Interaction design, this is called userdriven
innovation and is all the craze these days; all the cool kids are
But there's drawbacks. If you do it, your design becomes
public at a very early stage. It will probably be very sketchy
and usability will suck, so many people will disregard it. Some
people might be attracted to it, which is also bad, because many
iterations later you will have a very different product on your hands.
These issues can be handled by adjusting people's expectations; communicate
loud and clear where you are in the process, so people know what to
Public also means that your competitors will be able to
copy (or at least draw inspiration from) your product, which gives
you less of an edge market-wise. However, everybody will be able to
see that your competitors are copy-cats and they won't have the upside of the
goodwill from your open communication/user-involvement.
The user-involvement can also raise copyright-issues. If
you've been the lead designer on a process with input from 20+
personens (or more) and these people aren't formally working for you, who then
has the rights to the product? This can fairly easily be handled by a closed
forum and a legal department with NDA/contracts/large men in long
black jackets coming 'round, which should (for legal reasons) be the big companies approach to it.
I'd like to take a different
approach to it, seeing as I don't have the funds for a lawyer and
actually really prefer to trust people instead. So the deal's gonna
be that anyone who contributes significantly to anything I do will be
credited on it and I'll buy you a beer (or another beverage of your
choice) and maybe dinner if we meet in real life. Deal?
I'll start posting about Evolution: Fitness ASAP.