Category: Duet

Culling

Posted on by Matthew VanDevander

I suppose it is unrealistic to suggest that performance is never an issue when creating a video game. Since the better a game performs, the more graphical tricks you can cram up your games proverbial sleeves. But with the speed of modern computers, 2D games tend to not require much optimization. And as they primarily use tile-based graphics, it is relatively trivial to determine which tiles in the level are on screen (and therefore should be drawn), and which are not.

However, there are some newer 2D games, such as Braid, or Aquaria which use a entirely different method for their graphics which is not tile-based, but instead uses images which can be repeated positioned, rotated, and scaled arbitrarily to build a level. These images are rendered to the screen using modern 3D graphics hardware, which—being designed for 3D games—is rather fast for this application. Even still, there can be quite a large number of these images building up a level, so it is useful to devise an accurate and speedy method for determining which objects are on screen, and which are not. Continue reading “Culling” →

Games and Puzzles

Posted on by Matthew VanDevander

Work continues to crawl along on Duet, however I have been banging my head against a few things recently. Notably I have this question of “How do I know if a game is worth a person’s time to play?” I have been reading some literature on the subject of games and puzzles, so I felt it would be pertinent to share some of my thoughts:

On games, versus Puzzles…

Duet is a puzzle platformer. But that really just describes the mechanics of the game, without really delving very deep into the definitions of such mechanics.

So, in the worst style of writing, let’s define these terms with help from the internet.

A Platformer is a type of video game “mostly presented in 2D” which features “jumping to and from suspended platforms or over obstacles” Requiring the character to start from point A and get to point B by jumping and traversing various obstacles.”

A Puzzle is a type of problem that “tests the ingenuity of the solver”, and according to puzzle collector Stan Isaacs, it is “fun, and has a right answer.”

So, these definitions seem about right to describe Duet. But my research seems to suggest a divide between games and puzzles. So the question that I’m proposing, is where do I draw that line? Is Duet a puzzle or a game?

There are many definitions of what a game is, but my favorite is:

“A Game is a rule-based formal system with a variable and quantifiable outcome, where different outcomes are assigned different values, the player exerts effort in order to influence the outcome, the player feels attached to the outcome, and the consequences of the activity are optional and negotiable.” – The Game, The Player, The World: Looking for Heart of Game-ness

Games typically are designed to be as replay-able as possible, the idea being to explore the nebulous space afforded by the game’s mechanics. Once that exploration is completed to the satisfaction of the player, Playing the game is no longer necessary or interesting. Therefore all games must be inherently educational and interesting, but one must remember that a person’s prior experiences in and outside of games can reduce the novelty of an previously unplayed game to a point where she may find it not worth her time.

Puzzles–as defined earlier–however are intrinsically free of replay value. Once a puzzle has been solved–deliberately and with understanding–it is no longer valuable to the solver. This is to say that puzzles are only replayable if the solver does not understand why he solved the puzzle in the first place. Puzzles are similar to games in that prior experience with similar problems can nullify the intrinsic value of a puzzle to the point where the intellectual gain from solving it becomes trivial. However, the primary difference between puzzles and games is the goal.

The goal of puzzles to find the solution, the goal of games is to win against an opponent. However, there are still contradictions within these definitions. What exactly is an opponent in a single player computer game, what exactly is a solution?

Duet, as well as other games (Braid, Portal) are (perhaps uncomfortably) straddling the line between games and puzzles. On one hand, they quickly fit into the earlier definition of a game, they are based on formal systems and rules, they do have quantifiable outcomes with different values assigned to them, the player does exert effort to influence the outcome, she feels attached to the outcome, and the consequences are negotiable. However, the games also fit the definition of a puzzle, they have a solution–solvable only once– having limited replay value.

So where do these games lie exactly, are they really games at all? Is a game a type of puzzle? Is a puzzle a type of game? Are puzzles, by their very nature, inferior to games?

The creative process…

Posted on by Matthew VanDevander

The game that I am making currently is about cooperation. So what exactly does that mean? It means that every mechanic, every puzzle, and even every piece of art must be scrutinized to determine if it is core to this concept.

The process by which I create new mechanics for the game goes something like this:

Idea – From somewhere, either through playing the game, or from other games or other media, get a possible idea for a game mechanic.

Mentally Prototype – Imagine how the idea would affect the game. For some ideas, this is very easy. For instance, if the element has already been in another game. For others, I may have to skip mental prototyping, since the idea cannot be easily imagined.

Mentally Check for “Core-ness” – An interesting idea that does not fit with the games core theme is not worth implementing. For my game, the core theme is cooperation. In life, people like to establish relationships with people who have strengths where they themselves are weak. (In addition to common interests and similar experiences) Based on this aspect of human relationships, the players in my game must always have different abilities. Usually the bad ideas are those which do not create a give/take relationship between the players. Bad ideas are those do not create interdependence, but instead spur self-centered behavior.

Prototype – If the idea that I have cannot be discarded through mental prototyping, and seems like it may fit in the core of the game. Then I program it in, in the simplest way possible. Usually creating a bunch of dirty code. (But that’s okay, if it’s a bad idea, it’s a waste to write clean code)

Test – I try the mechanic out in many different situations, and in combination with existing mechanics. If the new mechanic creates any interesting puzzles that I couldn’t imagine when I first thought of the mechanic, then it is a candidate for the final game.

But how do I decide which things are interesting enough to make it in the game? That is certainly a tough problem, and there are many solutions. The simplest solution is to include everything that might be interesting. However, for my game, I have some fundamental guiding principles. I believe that the player of my game is an intelligent person, and should be treated as such. They are not stupid, and will be able to solve any of the puzzles that I can create for them, without breaking them down into simpler elements. I also believe that this player’s time is valuable to them, and I should respect their time, and not waste it. So therefore, I should never put filler into the game by repeating ideas that I have already explored.
Based on these principles, I will remove any puzzles which either waste a lot of player time on execution, or have very obvious solutions and may only be different than a previous puzzle in insignificant ways.

Even still, I struggle with this game every day. Sometimes I have to ask myself if the entire game is not just a waste of time for the player. It is certainly possible. But I am a game designer, and I want to make games, not incomplete products. So it is better to ship a game that I found interesting, even if no-one else will, than it is to not ship a game. As the Duct Tape Programmer says, “Shipping is a feature. A really important feature. Your product must have it.”

So time marches on…and there is much work to be done.

New demo for Duet.

Posted on by Matthew VanDevander

So, I’ve officially named the game now. It’s called Duet. There’s also a new demo, which you can download here. (Sorry, Demo is no longer available, the game is in full production swing now, so the prototype is pretty much off limits to the general public)

Me and my fiancee have been working on some concepts for the art style of the game.

These are very work in progress. They are mainly intended to help discovery of the mood for the game.

Some good news, and some bad news…

Posted on by Matthew VanDevander

Well, it’s that time again. The time of the month that I suddenly realize that I haven’t posted anything on this blog in a few weeks. But anyways, I said had news, so I should get on with it.

I always feel that it’s best to get the bad news out of the way first, so that the good news can give me some hope in the end. It’s more dramatic that way. So the bad news is that Fij is postponed indefinitely. Meaning that I most likely won’t work on it for a while. Truth is, I probably won’t finish it, looking at my history of unfinished projects. However, I definitely have some ideas that I want to pursue with Fij, so it will sit on my back-burner.

The good news is, I’m working on a new project in Game Maker. Which I know probably seems like a step back from real programming. But it’s actually going great.

Screenshot
Standing on a precipice

The game is about cooperating to solve puzzles. So it’s naturally a two-player game (at the minimum.)

Screenshot, again
A puzzle!

I don’t currently have a name for the game, so it’s just Untitled Cooperative Platformer in my mind right now. I also don’t know whether the current graphics are any indication of what the final game will look like, but the little blocky people have a certain charm to them, don’t they?

The design process is sort of an exploratory one, I just doodle out levels and try out any gameplay elements that I might be thinking of in different ways. If I can make it through the level some how, then it’s a puzzle. But usually I don’t know if I will be able to make it through the level before I test it. So the game is telling me what it should be. And I’m just sort of letting it become itself. Not to say it doesn’t require work, or that there aren’t bugs. But I do keep an open mind before I squash bugs, and try to see if the bug is actually functionality in disguise.

And just in case you want to test it out in it’s currently simple state, here’s a demo-ish length version of the game. It is my first game maker game, so if there’s some wierd .dll file you need, then let me know. Feedback of any kind is gladly appreciated. However, do keep in mind that it requires two players to play the game. It is possible to get through it on your own, but it would require some serious skills.

(Sorry, demo is no longer available for download.)