Tag: Daniel Linssen

Pixel Art Chess Set: Communicating function through design

My five year old nephew started learning to play Chess recently, as I discovered on a visit a few weeks ago.  We played two games, and I didn’t have too much trouble beating him, but for a five year old he’s not bad. He knows all the pieces and their basic moves and their relative value.

I thought it would be fun to build a video Chess game that he could use to help learn strategy and how to see the board. So this is my latest project. I’ll be posting more about that as I work on it.

My first step was to design graphic resources. I didn’t want to spend too much time on it, just a basic “programmer art” chess set, that I could use to build the program with. Of course, it didn’t end up that way, and I’ve gone down the rabbit hole designing variations on sets of minimalist pixel art chess men. It’s too fun and fascinating not to.

My first attempt was actually rather good, I thought. I went for 16x16px representations of the classic chess pieces. I drew them very quickly, but was very pleased with my results, particularly the Knight.

I could have stopped right there, but it was so fun to make this set that I wanted to continue exploring and see if I could refine my pixeling technique further.

I decided to search the net for images of chess pieces to see what variety there was, and found a lot of examples of beautiful sets. I started to take notes and to infer design rules for chess men:

  1. Chess pieces are called “chess men” which seems antiquated and sexist, especially given that the most powerful piece in the game is the Queen.
  2. The modern standard chessmen are a design named for English chess master Howard Staunton, and have been in use only since the mid-19th century. A strength of its design is that each piece is easily distinguished from the others, making errors from mistakes in identifying a piece — a problem with other sets — unlikely. Previously, chess men of different types had a less distinct appearance from one another, and were not as standardized.
  3. In a Staunton set, the Knights are the most detailed, ornate, varied, and realistically represented pieces. 
  4. In Staunton sets, there is a standard height order: pawn, rook, knight, bishop, queen, king. (This surprised me, since Rooks are more valued in Chess I would have expected them to be taller than Bishops.)
  5. The pieces are differentiated by their tops. Each type of piece has a distinct, unambiguous shape.
  6. The body/base of the pieces have a common design, to create unity among the pieces in the set.

I tried to apply design choices to my chess set following these insights.

A follower on Twitter offered feedback that the pieces should be different heights, so I tried that. With a 16×16 pixel tile size, I could only shorten the back row pieces by 1-3 pixels.  I also tweaked the King piece by adding a few more pixels to its top, to make it a bit more distinct from the Queen, and moved the Pawn so that it wold be more centered in its square.

I do like the result:

Staunton pixel chessmen

I think my initial 16×16 Staunton set look like they’re in ALL CAPS, while this set is more “readable” by using “mixed case” heights for the pieces.

I wanted my chess game to be focused on usability and instruction. I needed each piece to be immediately recognizable, and not to convey a bunch of extraneous information to the player that has nothing to do with play mechanics. 

My next attempt was a different take altogether. I wanted the look of each piece to suggest its rules for movement. I also thought that it would be clever if the pieces communicated the rules for using them through their visual design.

I ended up being very pleased with this set as well, although I went through many more variations, particularly with the Pawn. This one also came together easily and rapidly.  When your tile size is 16×16 and you’re working in just a few colors, it’s easy to work fast.

Things I like about this set:

  1. The shape of the piece is a built-in tutorial for how the piece moves.
  2. The Pawns still have a pawn-like shape (at least the black pawns; white pawns are “upside down”).
  3. The Knight’s shape may be read as an abstraction of the horse’s head shape of the Staunton piece.

I think out of these variations, my favorites are: P9, Kn2, B3, R1, K?  I’m least certain which King I like.  I think K4 and K5 are my top two, but I also liked the idea of incorporating a crown motif into the design, to signify the King’s special property of being the King.  K1, K2 and K6 were attempts at this, but I think K1 looks too much like a Staunton Rook, unfortunately.

I wasn’t sure which of my designs to use for my final set, so  I posted my sets on Twitter and a pixel art community on Facebook. @Managore responded to my request for feedback by coming up with a set of his own design, which I quite like.

His design was retweeted and liked over 500 times, and received many positive compliments from his followers, many of whom are game developers. One of my favorite indie developers, @TerryCavanaugh, who made VVVVVV and Don’t Look Back, pointed out an physical chess set that had been designed a few years ago which incorporated the same ideas.

It’s exciting to see my idea get picked up and reworked by fellow game developers who are inspired by the concepts I am exploring. So fun! Getting that validation that what I’m working on is interesting to others is very motivating. But it’s particularly good to get some attention from developers whose work I’ve admired for years, however modest.

I’m excited about this project and look forward to working on the program. I have more design ideas that I’m looking forward to getting into soon.

Interview: Daniel Linssen

Daniel Linssen is an indie game developer who lives in Sydney, Australia, who I came to know after playing his first Ludum Dare creation, Javel-ein, for LD28. After releasing the full version of Javel-ein, he was cool enough to reach out to me to let me know of its existence, since I had so enjoyed the version he had made for LD28, and since then we’ve corresponded regularly and become digital pen pals. He is also the creator of Busy Busy Beaver (which won Bacon Jam 07) and FFFFFF for Flappy Jam. His most recent game, The Sun and Moon, recently won first place in the Overall category for Ludum Dare 29.

CS: Thank you for agreeing to do this interview. Ready to begin?

DL: As ready as ever!

CS: First, do you prefer to be called Managore or Daniel? What does the name Managore mean?

DL: Daniel. In the past I liked having a unique identity while still being anonymous, but I’ve given up on that.

Fun fact: For a long time “Managore” was absolutely unique. Then a year or two ago a Bulgarian company released an online game called Managore and my uniqueness was lost. Oh well!

The name doesn’t really mean anything. Years ago I started writing a (really terrible) sci-fi novel and one of the characters, some sort of biological experiment, was named Managore. And the name stuck.

CS: How did you get started making games? How long have you been doing it?

DL: The earliest example I can think of is as a kid I designed some Sonic The Hedgehog levels on paper. I think I was around 8 at the time.

CS: That’s something I used to do as well, designing games on paper. I think I did my first game concept when I was six or seven…

DL: I’m pretty sure the levels I designed would have been terrible. I hope yours were better!

CS: Nah, the stuff I drew up wasn’t that sophisticated. I’d do a drawing of a screen shot, and then narrate the rules and the player’s goals, point values, etc. and my mom would write them down for me. I didn’t do anything so sophisticated as a full-blown design doc or anything. It was just about the enthusiasm and instinct to be creative, and wanting to do it for real someday.

DL: There’s an old DOS game called Jetpack and I spent a long time using its level editor. The idea of a level editor was pretty novel for me at the time. Over the years since then I’ve played around with RPGmaker, C++, Valve’s Hammer Editor and Flash but never made anything that I could really call finished.

CS: What game projects did you work on previous to your first LD game?

DL: Well a whole bunch of unfinished or unreleased games, unsurprisingly. Actually the only games I’ve released so far have come from game jams. My first experience participating in a game jam was three years ago, I was working with a friend of mine. The game we made was a one screen rhythm platformer for Reddit Game Jam 05 (the theme was “love”) called Give In. I worked on the player controls (which are way too slippery) and the graphics (which I still kind of like the look of).

After that I started using GameMaker and worked on some exploratory platformers which will probably never see the light of day. Then, half a year ago I took part in the Bacon Game Jam 06 (the theme was “rainbows”) and made an action platformer called Violet, which I think of as my first “proper” game, if you can call it that.

CS: How do you approach a 48 hour event like LD? How is it different from when you are working on a game without external time constraints?

DL: I try to start off well rested but that’s about it. Sometimes I have an idea of what aspects of the development process I want to focus on or improve on. Once I have an idea and I start coding, autopilot tends to kick in.

CS: OK let’s talk about The Sun and Moon. I’ve just read your post-mortem article on the making of it, so hopefully we won’t rehash too much of that. I encourage readers to check it out for themselves.

First, let me just say congratulations on another fantastic game. For the record, out of 1493 entries for the LD29 Compo, you placed 1st Overall, 1st in Theme, 2nd in Fun, and 3rd in Innovation. This was just your second LD entry! Obviously, no one expects to win a category, but how well did you think The Sun and Moon would do when you finished it?

DL: Well I went into it hoping to make a game which I could be as proud of as my previous LD game, Javel-ein, and I think I achieved that. When I finished, I was really happy with how things had gone. Everything (well, except the music, but I was too tired to realize that at the time) had pretty much falling into place and the game’s mechanic ended up being a lot of fun. I was lucky not to run into any major hurdles along the way.

My hope was to get a medal in some category but I knew there were so many utterly fantastic games to compete with, so it was always something I was hoping for but never really expecting.

CS: How does it feel to have won the Compo?

DL: It feels amazing. I couldn’t believe it. It’s a dream come true.

CS: What does the title, The Sun and Moon, mean?

DL: Good question. I have all these good answers for why I chose “Violet” and “FFFFFF” and “Busy Busy Beaver”, but I don’t really have a good answer for The Sun and Moon. I was really struggling to come up with a unique and meaningful name. I had all these ideas written down. They’re pretty bizarre so they might be entertaining to read:

A World Divided, The World Beneath, It Spoke Quietly And No One Heard, A Hollow World, The Sun and Stars Both, The Sun and The Moon.

If you’re curious about ISQANOH… I honestly have no idea. I liked the sound of it.

Anyway, because it is such an abstract game, at least as far as my games go, I wanted the name to be up to the player’s interpretation, but I did have a reason for choosing “The Sun And Moon”. As I was developing the game I realized I needed to make the player change appearance while underground, and from that point onwards the player kept reminding me of the Yin and Yang concept. The dark version which falls and the light version which rises. The air and the ground. Complimentary forces. And one representation of the Yin and Yang is the Sun and Moon, so I went with that.

CS: Yeah… what was interesting to me about the title was, there wasn’t really any literal sun or moon in the game! I wondered about that, and was interested to hear what the story was, if there’d been some plan to get them into the game but you ran out of time, or… if, like the Sun and Moon were just metaphorical somehow..

DL: I worried that people might find the name a little too… artsy? But as far as I know that hasn’t been the case.

CS: I think it’s a fine title!

CS: The core mechanic of The Sun and Moon is to traverse a series of obstacles by selectively passing through solid platforms. How did you come up with the idea? How long did it take you to refine the specific mechanics (requiring a jump/fall to pass through the floor, buoyancy within a solid platform, the acceleration/momentum upon ejecting out of a solid platform, etc.)

DL: It just sort of came to me, after a long string of bad ideas. I was thinking about a bubble in a world made of water and air, and the idea evolved from there. I had a pretty vivid image in my head early on of diving into the floor and shooting up into the air and from that point I felt like I had come up with something fun. I stuck with that mental image and built the mechanic around it.

Originally you didn’t have to jump to pass through the floor. I planned to make the player “wobble” up and down if you were standing on the surface and held down the action key. The way I happened to code it meant that when you held down the action key, since your vertical speed was zero, the “wobble” wasn’t there. This worked well enough so I just left it that way.

CS: At what point did you realize you were on the right track?

DL: When I started making the levels. I posted a gif of one of the first levels I made and the responses were really encouraging. The more levels I made, the more content I was with how my game was going.

CS: How long did it take you to build the basic engine?

DL: Surprisingly not long at all. I mentioned it in the post mortem but I made a movement and collision engine called the Beaver Engine which I used as my starting point. The Beaver Engine is a stripped down version of Busy Busy Beaver, one of my previous game jam games, which took about 12 hours to write the code for.

It took a little rewriting to add in the underground physics and make it all work properly but overall the basic engine was pretty painless.

CS: What design decisions were hardest to make?

DL: We’ve already talked about it, but the name! I was actually starting to panic a little towards the end because I couldn’t come up with a name! Oh, also the player’s trail. I went through five or six iterations before I found something I was happy with.

CS: What features/ideas did you drop from the game?

DL: I’ve started to get a pretty good idea of how much I can realistically get done in a game jam, so I kept my feature list pretty minimal. I actually had time near the end to add in a few features such as the level select screen, which I wasn’t originally planning on including.

Speaking of features I wasn’t originally planning on including, I should definitely mention how much of an absolutely huge help it was having you give the game a go a few hours before the deadline. I remember you saying you wish there was a way to know which level you were on, which led to the level number appearing at the beginning of each level, and you said it would be useful to know which level had been played last, which led to the player sitting on top of the last played level in the level select screen. These were really important features that I wouldn’t have thought of at the time.

CS: Absolutely! It was an honor to have been asked, and to be able to provide a little feedback so you could refine the finishing touches on the game that ended up taking 1st Overall. I remembered thinking right away that it was a very strong entry, and I liked it from the first couple levels. I had the idea about the level numbers because when I was giving you feedback, I didn’t have an easy way to reference which level I was talking about. So it was a fairly obvious suggestion.

DL: Fairly obvious to anyone but me! I guess it just really helps to have a fresh perspective with an eye for what’s important.

CS: True; when you’re in the final hours before deadline, your focus tends to be on the most critical elements of the game, and finding bugs. Being able to look at the game with a fresh perspective just isn’t possible, so it’s valuable to be able to get feedback from someone who hasn’t been staring at it for the last 40+ hours!

How would you compare The Sun and Moon to your other games, Javel-ein and Busy Busy Beaver?

DL: Well I knew while making BBB that it just wasn’t going to be that innovative, so I focused on making it fun and silly and pretty. For The Sun and Moon I went the opposite direction and focused on making it unique and innovative, at the expense of a story, detailed graphics and humor.

And then Javel-ein is sort of a blend of the two.

CS: This game focuses on mechanics rather than story, and, I think, stands up well on those merits. Have you thought about adding story elements to the game, or do you plan to leave it abstract?

DL: I’ve thought about it, but I honestly don’t know what direction I could take it.

CS: Your sense of level design and mechanics for 2D platformers is, if I may say so, pro quality. Can you describe your process for designing levels?

DL: In general, if I have a game mechanic to work around, I try to explore that mechanic in as much depth as possible. For The Sun And Moon, I looked at all the different types of movement that the mechanic allowed for (e.g. diving down into the floor, jumping up and through a block, falling off a tall platform and diving deep into the ground below, jumping through a thin wall, jumping into and up through a block) and came up with levels that made the player use these tricks. I wrote all my ideas down on paper first since I’d often have multiple levels ideas come to me at once.

CS: Do you have interest in making other types of games than 2D side scrolling platformers?

DL: Definitely! I think it’s just been the case that the ideas I’ve had that have worked the best have always been tough platformers. On the backlog I have a color-based puzzle game I’ve been working on as well as an idea for a top-down naval exploration game.

CS: The art style of The Sun and Moon would be best described as a minimal, GameBoy style. But it works very well, especially the “clouds” in the background. How did you come up with the idea for them?

DL: For the clouds? Early on the background was a solid color, and I realized that if you flung yourself really high into the air it was impossible to tell how fast you were going. To fix this I decided to add a parallax background in. My game, with its monochrome palette and dark-foreground-on-light-background style, already looked far too similar to Luftrausers, so I wanted something abstract and different.

When I was coming up with the idea for my naval exploration game I experimented with perlin noise and other techniques to generate a huge ocean with lots of islands and interesting coastline, so perlin noise was still fresh in my mind. Because Photoshop’s “Render Clouds” filter creates tileable perlin noise I knew I could use that to quickly make a suitable background.

CS: Interesting that it was a feature driven as much by gameplay needs (having a reference so the player could gauge their speed) as much as cosmetic needs. Visually it’s a very pleasing effect!

How much have you added to the game post-compo?

DL: I’m up to 67 levels at the moment, though I lot of the newer ones still need some work. I’ve added controller support and made the game run on mobile devices. I’ve added a timer for each level that records your best time. I have a lot of ideas for mechanics that could add variety to the gameplay and I’m currently playing around with these to see which ones work the best.

CS: Wow, sounds like you’ve been busy! What are your plans for developing the game further?

DL: Even more levels! However many I can come up with while making sure each level is still unique and fun. I’ll work on the visuals a little bit but I want to keep it looking minimalistic.

More importantly, the music is going to be completely redone.

CS: How about some technical questions?

DL: Sounds good!

CS: You use GameMaker: Studio for your games. Do you work with any other programming tools or environments? What do you like about GM:S? What do you wish was better?

DL: Not at the moment. I think what I like the most about GM:S is that I’m so familiar with it. And that it’s very easy to prototype new ideas. There are, unfortunately, a lot of things I wish GM:S did better. The built-in level editor leaves a lot to be desired, the program occasionally crashes and I lose progress, Windows builds and html5 builds can be wildly inconsistent, and a lot of other, smaller issues.

CS: How did you get into GameMaker?

DL: Two of my favourite games, An Untitled Story and Spelunky, were made in GameMaker. They inspired me to begin making games seriously so I guess I thought it was a good idea to use what they used.

CS: Are you active on the GMC forums? Are there any other good sites for game development that you frequent?

DL: Not at all. I browse /r/gamedev and /r/indiegaming on reddit, but that’s about it.

CS: You mentioned in your post-mortem that you experimented with a couple of different motion trail techniques, before settling on a line drawn out behind the player. How did you make the line taper?

DL: Okay so each frame an object is created. This object stores the players current location (x,y) and the player’s previous frame location (x_p,y_p). The object draws a line from (x,y) to (x_p,y_p) of a certain thickness, starting at 5 pixels and decreasing by half a pixel each frame. So, at any one time, the trail is made up of 10 objects, each drawing a line of varying thickness.

If the player is underground it’s a little different. It still creates objects which store the player’s current location but these objects draw a circle instead of a line, and instead of the circles shrinking their visibility is decreased each frame.

CS: Thanks to gravity acceleration, you can achieve some pretty high vertical speeds. Was it a problem to handle collisions at such speeds? Did you have to do anything special to make it work?

DL: Good question! Because every object in the game (except the collectables, come to think of it) is 16 by 16 pixels, I only needed to make sure that the player never moves more than 16 pixels each frame, so I set the terminal velocity to 14 pixels a frame, just to be safe. I think the terminal velocity is pretty hard to notice in general.

CS: Is there anything else you’d like to say?

DL: Only that participating in Ludum Dare has consistently been a fantastic experience.

CS: I have to agree. Not just making games and having other people play them, or even getting to play a lot of cool games made by other people, but getting to know a few of the people in the indie scene, both through their work and through actual correspondence. Perhaps that’s been the most rewarding part of it all. Congratulations on your accomplishments, good luck in the future, and thanks for taking the time.

DL: It was my pleasure, thank you for interviewing me!

 

Game Review: Busy Busy Beaver by Daniel Linssen

A close shave resulted from a precision fall in Busy Busy Beaver

TL;DR: A fun, quick puzzle platformer, Busy Busy Beaver isn’t as difficult as Linssen’s previous game, the amazing Javel-ein, and is perhaps just a bit less engaging, but it’s charming sense of humor makes up for it. If you’re up for an hour’s worth of platform puzzles, try it out. Built in just 40 hours of marathon game jamming over a weekend, it’s remarkably polished for a game produced so quickly.

Download Busy Busy Beaver here.

You’re a beaver. You need wood to build up your house. Collect the wood, until you have enough, but make sure you don’t touch spikes or eat so much wood that you have no platforms left to get back home.

Simple, yes? The challenge is mild to moderate until the last few levels, but it’s a relaxing kind of intellectual challenge, where you don’t have to think too much, but just enough to make the game interesting without being frustrating.

I got stuck on the very first level, until I learned this tip: Press Down+Z to eat wood that you’re standing on. (I actually tried this early on, and couldn’t get it to work, which left me confused as to how to beat the first level, until I learned the secret: To eat down, you have to be in the center of a grid block. The level is laid out over an invisible grid, and if you’re standing on a grid line, you won’t be able to eat down, even if you’re standing on a grid line between two blocks of wood. As a player, I would have expected to eat both blocks when straddling a boundary, rather than neither.)

Game review: Javel-ein by Daniel Linssen

I loved Javel-ein when it was first released as a Ludum Dare 28 Jam entry. It’s been expanded into a “Full Game” — I put this in quotes because, other than perhaps a lack of background music, there wasn’t anything about the Jam entry that felt incomplete or less than “full” to me. TL;DR: it’s a great game, it’s free, and if you run Windows, you can play it.

Get Javel-ein.

Game Play

You’re a guy armed with a Javelin, jumping and running through a 2D platform world of caves and lava pits. There are dangerous creatures, which you’ll need to kill with your Javelin. Once all the creatures are destroyed, you need to find the door to take you to the next level. The twist is that you only get one Javelin, and you have to retrieve it each time you throw it, leaving you temporarily defenseless. (more…)

Updated Javel-ein released

One of my favorite games to come out of Ludum Dare 28, Javel-ein, has been developed into a full game by its creator, Daniel Linssen. I was amazed with how polished and balanced the original version of the game was, so this expanded version should be a real treat to play.

I’ll probably post an update with a full review once I’ve had a chance to play it. Review here.