Here’s a boss design (from the fifth level) that I’m in the process of implementing. Thought it looked neat so I’d thought I would share it:
As I near the end of creating the puzzles, I’ve started to think about the art style and aesthetic of the game. Since the game will encompass many commercials ranging from the 50s to the early 90s, I’m trying to find a fusion of vintage, vaporwave, and glitch art. Here’s a few pieces of concept art I created of the main antagonist (he’s currently named “TV King”):
I would have liked to implement more of a glitch aesthetic, but alas this was all I could come up with. Photoshop was my friend here. I pretty much know nothing about creating art, so I’m learning slowly. I tried to actually draw on paper but I soon realized I’m terrible at that and better at combining pieces of art in unique ways. I’ll create another post once I finish the remaining puzzles and refactor/polish up the code. After finishing those tasks, I’m going to dive right into the art. Finally as I finish the prototype with the newly added art I’m going to start sending out the game to some play testers.
I still have a long way but I’m getting there. Until next time!
Since I’ve been working on my game a lot as of late (let’s just say I’ve been on a very tight deadline), I thought it would be valuable, mostly for myself, to write down how I design levels so I can have a better understanding of what works and what doesn’t. Every person has their own preferences, techniques, and “unique” ways in which they go about this so please take this with a grain of salt, especially since I’ve only made one finished game. Now, let’s dive in.
First off, designing levels will obviously depend on the game’s genre. Since I’m currently working on a puzzle game, this design process will mostly pertain to that but it may very well bleed into other genres. So, since I’m making a puzzle game, the first thing I decided to use was graph paper. Before this I just prototyped in the game engine itself, but several months back I found that designing your levels on paper is actually a lot easier since you’re able to quickly iterate and erase/insert things on the fly versus in-engine.
The image shown above is a picture of me thinking of an interesting mechanic for the first area of my game. Every level in the game is 11×9 tiles (it’s a grid-based puzzle game), and each tile corresponds to a square on the sheet. I found this to be immensely useful because you can choose what exactly goes on each tile, and the movement of these objects can be expressed with simple arrows (at least for my case). On average, it takes me about a day to design 8 levels. Then after that day, I spend half a day going over it and making sure the puzzle solving meshes thematically with the corresponding area. If I’m not satisfied, I just throw it out and start the area’s puzzles again. To be frank, I feel very lucky when I stumble upon a good level. So I guess the moral of the story is to leave luck to heaven, and make sure to give thanks to your muse! (I totally didn’t copy those phrases from other people)
As far as I know, there’s no “formal” way of going about this. I think up of interesting mechanics and write them down. I model them, write out the details, and then draw them into my 11×9 level grids. One of the hardest parts is object placement, which can take hours depending on how the player will interact with them. Once I have a solid mechanic, I realize, wait, this is actual shit. So I erase it and think of another. Lather. Rinse. Repeat. I scoured the web to find anything related to puzzle design because every time I design puzzles I feel like I’m shitting in the dark (is that a saying?), but unfortunately I came up dry for resources that would help me out. So in the end, it’s a lot of trial and error and even then I don’t fully know if the mechanics I have on paper is a good until I implement them into the game.
The above picture is a completed puzzle (after about ~4 iterations). The amount of iterations wildly varies. Sometimes you get it on your first try, other times you get it on your 11th. I think the average amount of iterations per puzzle depends on the context of the puzzle, but I do believe that you can decrease that amount by creating more puzzles and gaining experience. Or go to a game design school. BAHAHA just kidding.
Well, writing this out has helped me out quite a bit. I rarely write blog posts anymore, and I want to change that. I plan on formally announcing TV King when I have a solid prototype and I’m aiming at the end of July. I literally haven’t put out a game in 3 years other than prototypes, so I’m excited to be close to finishing an actual game. I’ve also been working on a little 2D game engine, but I’ll leave that for another post. Until next time!
Since Ludum Dare is over, I’ve continued working on my puzzle game again. I’m currently implementing puzzles and working on the design, but on the side I’ve been working on the look and aesthetic of the game. Since the game takes place inside of a TV, I’ve been looking around for a solid TV/CRT retro shader. Thankfully, Gamasutra published a little tutorial for making my own CRT shader. The article was written by Svyatoslav Cherkasov, a game developer for an up and coming indie game called VHS Story which actually looks pretty cool! I’m looking forward to playing it
I followed the tutorial and added a little of my own custom code, and here’s a screenshot of the game using the shader:
Still debating if I should keep it in the game… On one hand, it totally fits with the themes of the game and being trapped in a TV, but at the same time the look is a bit jarring. The player will need to look at the screen for a while since it’s a puzzle game, so would I want to annoy the player’s eyes with a tacky look? Well, one way or another, the shader will definitely make it into he game, just varying in degree.
My next post will probably deal more with puzzle design, but since I feel like I have no idea what I’m doing and all my experience from puzzle design is from GDC lectures and PuzzleScript games created by Stephen Lavelle, it might take me a while to formulate my thoughts. Until next time!
This Ludum Dare was quite different than what I was used to. I usually compete in the compo going at it alone, stressing about the deadline and ultimately leading to an either interesting or boring prototype with sub-par pixel graphics. This time, I actually had teammates. This isn’t the first time I’ve worked on a game jam with other people, but it was the first time when i felt a connection and got along really well with everyone on the team. Ultimately, it was a very fun experience and a very silly/funny prototype came out of it.
Here is our entry, our game/prototype was called: The Forest of Hamelin
Here’s the team:
Alex Chytrowsky: Lead, HUD, Planning
Matt Murphy: Planning, Documentation
Sunil Rao (Me): Gameplay Programmer, Grandmaster of Unity
Ian Swift: AI/Pathfinding
Keith Thomas: 2D Art
Bryan Spahr: Voices, Music, Ambient Sound, ALL THE AUDIOS
Nathan Hurde: bringer of the chicken
I’ll update this post with some screenshots as well as some pictures of the game jam.
I usually don’t post these kinds of things, but I stumbled upon this short little video while working on my prototype and it really moved me. Let’s all have a productive 2015!