About Waterman7 (twitter: @@w7games)

Entries

 
Ludum Dare 36
 
Ludum Dare 33
 
Ludum Dare 32
 
Ludum Dare 31
 
Ludum Dare 30
 
Ludum Dare 29
 
Ludum Dare 28

Waterman7's Trophies

Waterman7's Archive

My first game on the Play Store!

Posted by (twitter: @@w7games)
Sunday, November 8th, 2015 12:55 pm

Hi guys!

I finally managed to get my LD33 entry ’76’ onto the play store. It’s a small puzzle game about tactically removing tokens from the board. It’s also free, so why not give it a try?

Comments, reviews, and feedback in general are really appreciated! :)

 

2015-11-07-22-21-56

Postmortem: Sprotzel

Posted by (twitter: @@w7games)
Saturday, December 27th, 2014 10:14 am

[reblogged from my game design blog Replay Value]

A few weeks ago, I participated in the Ludum Dare’s 31st edition with the theme “Entire Game On One Screen”. I made a game called Sprotzel, which you can play right here.

Sprotzel

What went right

Choosing constraints …

I find it really helpful to set myself some sort of constraints when working on a game project. Those can range from visual constraints like using only a limited color palette to input constraints like only using only two buttons to play. In this case, I got from the theme of the jam Entire Game On one Screen to the technical constraint The screen never gets redrawn. From there, I quickly came up with some concepts that sounded interesting, one of which resulted in the final game.

… then abandoning them.

However, at some point, once I had the core gameplay and aesthetics implemented, I hit a wall. I wanted to include a new mechanic into the game (collecting pickups), but I just couldn’t seem to find a way to include it without either ruining the visual style, or breaking the constraints I had set for myself. So after some struggle I decided to drop the constraints and do what’s best for the game instead. Letting go of that self-imposed limitation was harder than I expected, but I’m glad I did so. I think constraints, especially technical ones like this, can be useful as a source of inspiration and design challenge, but only until they become obstacles instead of stepping stones.


Staying in the flow.

I didn’t polish the game as much as I could have. I stopped at some point, even though I still had ~24 hours of time left and started a second game. Now this is everything but consumer-friendly and the first game definitely suffered from it, but for me personally it was probably the better choice. Because anything I would have added to Sprotzel after that point would have been dull busywork. Implementing a proper in-game tutorial isn’t fun, it just takes time. And it wouldn’t have added anything substantial to the game experience.

So instead I used the remaining time and motivation to just start something completely new, even if I wouldn’t finish it in time. It actually went so well that I’ll probably keep working on this second project. Had I used another four hours to polish Sprotzel, I don’t think I would have been able to do anything of the sorts. I guess flow is as important for a dev as it is for a player.

 

What went wrong

Not play-testing.

This is really the one thing I regret the most about this jam. I was sitting in a room with five other people for the whole time and in the end each of them only played my game once or twice at all. I didn’t really do any explicit play-testing or ask for feedback, which shows in many aspects of the final game, especially its high difficulty.


Not leaving the comfort zone.

Sprotzel is a typical Waterman7-game if there ever was such a thing. I didn’t really try anything all that new or exciting or challenging. Not on the gameplay- and not on the programming-side. There wasn’t even a crunch-time. Somewhat boring really. It was still fun, don’t get me wrong. I just feel like I didn’t learn as much from this jam as I did from other ones.

Not making audio. Again.

This is slowly becoming kind of a running gag, except it’s tragic instead of funny. Although, this time I at least I gave it a try. The problem was, I tried to learn not only a new program mid-jam, but a whole new design-field. Of course, without any prior experience with sound, the endeavor was doomed from the start. I struggled with some unfamiliar interface and pushed random buttons for some amount of time before humbly resigning to the gods of sound once again. But I will have my revenge. Some day I will face them again, prepared.

Postmortem: Zeit

Posted by (twitter: @@w7games)
Tuesday, August 26th, 2014 7:41 am

[Originally posted on my blog]

I participated in the 48h game jam Ludum Dare again last weekend. The theme was “Connected Worlds” and I started making a game called Zeit based on the multiple worlds interpretation, in which you are stuck in an endless time loop and have to fight off enemies and avoid a growing army of alternate versions of yourself. Sounds fun? Meh. I didn’t really like it, so I stopped working on it after 14 hours and left it half-finished. You can still check it out if you’re interested.

Zeit

The Good

So here’s some of what went well this time.

– Livestreaming. I did that, and a couple of people actually watched it. It’s great for two reasons:

Firstly, I was way more focused on the task and way faster than I would have been otherwise. You don’t procrastinate when you know you’re being watched. Secondly, I now have all of my 14 hours of work on tape and can revise my workflow and do cool things like this time-lapse. I’ll probably keep doing that in the future, and I can only recommend it to anyone who does anything remotely interesting.

– Researching. I did that for the first time. I didn’t have any idea what to make of the theme “Connected worlds” (at least none that would have been realistic given the time frame and my limited programming skills), so I googled anything related to “connected worlds”, “multiple worlds”, “other worlds”, etc. Eventually I got stuck on the many worlds interpretation, which gave me some crazy gameplay ideas about alternate universes and time-loops. The stuff is actually really interesting, and you should totally do some research on it if you’re looking for gameplay inspiration.

 
The Bad

Here’s what didn’t work out so well.

– Giving up. I did that way too early. In retrospect, I really regret not finishing the project. Even if in my eyes it wouldn’t have been a good game in the end, someone else might have liked it. (And some people already do.) Game jams are not about making a great game, but about making a game. And the experience of that might be worth just as much. I guess I’ll still have to learn to from time to time finish a game just for the sake of it.

– Not making sounds. Again. I remember last Ludum Dare I wrote something along the lines of “If everything works as planned, my next LD entry will have at least some sort of noise in it. Promise! Well. It doesn’t. It would have been a good exercise to implement audio into the game, too, but I didn’t even get to that stage. I’ll really try harder next time. Promise. For real now!

 
The Takeaway

– Don’t give up next time. As one commenter accurately pointed out in response to my game: “Some ideas are just worth exploring, even if there is no fun at the end.” Maybe next time explore it some more before abandoning it.

Post-Mortem: Baum

Posted by (twitter: @@w7games)
Wednesday, May 7th, 2014 2:26 pm

[reblog] A bit more than a week ago, I participated in the Ludum Dare 29 compo. It’s a themed 48h game jam on the internet. This time around, the theme was “Beneath the surface”.

It was my second time participating in a Ludum Dare, and this time around I made a game called Baum about a bone-eating tree with hands for roots being afraid of spiders. You can check it out (and rate it) right here, if you haven’t already.

 

Baum

 

The Good:
Here’s some of the things that worked really well.

– Not working alone. I actually met up with a friend and we both worked on our LD entries in the same room at the same time (check out his game cell.erity), brainstorming together, exchanging ideas, playtesting each others games and giving each other feedback. It was an amazing experience and far more fun than going at it alone.

– Not giving up. I actually started out working on a completely different game for the first ~24h before realizing that it was far too complex a concept to be fully realized in time for the compo. I really didn’t want to submit an unfinished experience, so I stopped working on it. I was really demotivated. I slept a couple of hours and played some games. At that point, had I been alone, I would have probably given up on this LD and called it a weekend. But I was feeling some sort of responsibility towards my friend. I was the one who talked him into participating – I couldn’t be the one who wouldn’t have a game to show for it. So I just started over with something completely new.

– Not giving a shit. Really, when I started working on Baum, I was in a different state of mind than I usually am when working on games. I didn’t care if this game was going to be the best I could do. I just needed to get something playable done, and quick. So I went with the first most simple gameplay idea that came to mind, and just did it.
Playing as a tree collecting things with its roots? Sounds like a game. Let’s do it.
It was a somewhat scary, yet refreshing experience for me personally, and I while I think Baum is definitely one of my weaker works, I got great feedback so far and at least some people seem to really dig it. And in the end, that’s what making games is all about for me.

– Incorporating player feedback into the design. Now, at first I had no idea where to go aesthetically with Baum. I usually do very abstract graphics in my games, because I hate (and am very bad at) doing art. This time though, I was actually working from an idea based on setting, not on gameplay, so I didn’t want to go abstract with it. So I just did some really crappy placeholder graphics and worked with those. Then, a playtester (we had some visitors throughout the jam) remarked that those slowly moving root-hands really creeped him out. So I went with it and developed the whole style around the idea of a disturbingly bizarre mood, which fit in perfectly with the concept. I never would have come up with the game’s look as it is now, if it weren’t for that one player who was creeped out by my shabby placeholder graphics.

 

The Bad:
Here’s some of the things that didn’t work all that well.

– Not making sounds. Again. This has been the source of complaints in my last LD entry, and it was again this time. I totally understand it, as sound can be a very important tool to give gameplay feedback as well as creating atmosphere. Now, the problem is, I still don’t know how to do good sounds, and that’s why I never bothered to put any in my games (unless someone else had made them). I am planning, however, to finally get around to learning some audio basics at some point. If everything works as planned, my next LD entry will have at least some sort of noise in it. Promise!

– Not documenting my progress. I’d love to show some screenshots of earlier versions of the game and how it changed over time. I’d also love to show some stats on how much time I spent with what part of the development, how many hours I worked in total, ect. Problem is, I didn’t bother to keep track. In retrospect, I do regret it myself, as I’d be quite interested in analysing my workflow.

 

The Feedback:
Here’s some of the response I got from comments on the game, as well as talking to people who played it.

– People loved the mood. Most comments I got were not about the gameplay, but the atmosphere of the game. It was a simmilar thing with my last LD game, where people also seemed to enjoy the tense atmosphere. I find this very interesting, considering I never really start making a game with the intent of creating a certain mood. I always start with gameplay, and usually find a tone while experimenting with the mechanics. I’m wondering how a game would turn out where I actually build it around a certain tone I want to set instead. I might try that in the future.

– Confusing visual feedback. Basically, I used the same particle effects when the tree is eating a bone (positive) and when a spider is crawling up its roots (negative). In retrospect, that was a pretty stupid idea, and happened mostly due to my own laziness.

– No sense of urgency. Some people didn’t like the slow pace of the game. They missed some timer, or depleting resource to make the game more tense. Also, someone managed to exploit the fact that there is no urgency to essentially break the game and get real high scores without much effort. This one really bugs me, because I think it’s a fundamental flaw in the game’s design, and one I could have easily fixed.

– The spiders are very unpredictable. Some players didn’t like that and said they would prefer it if they would move in more of a pattern, as to enable more strategic planning. On this one, I heartily disagree. I think, most of what makes up the tension of the game, is never being quite sure, how the spiders will behave. Predictable spiders would make the game a lot less interesting in my eyes.

– Some people hate waiting. Some don’t. I got both positive and negative feedback on the ‘spiders crawling up the roots’-part before the game is over. Some people didn’t like waiting until the spider reached the tree each and every time, while others really enjoyed getting a bit of the creeps whenever it happened. Easy solution would have been to make it skippable. Oh well.

– Most people hate spiders.

 

The conclusion:
LD29 was a blast, I learned a lot, and I made a game about a tree with hands. Lovely!

[cache: storing page]