It’s been a while since the last update. I spent the months working on interesting prototypes and experimental installations, but now I finally have time again to come back to Catcher!
Since the last time, I picked up generative art to make interesting backgrounds. After a lot of experiments, I finally settled for a background that looks similar to the old one, but more interesting and with more dashes of color – and because it’s procedural, it will always look different.
I also visited the AMAZE Indie Festival in Berlin and got lots of great feedback that I used to improve this build.
Here is the changelist:
New procedural background
Made level transitions more fluid
Tweaked movement and net opening/closing
Replaced A-F rating with stars
Added a score malus for death
Added a particle mouse cursor ingame
Capped player ships at screen border
Improved “Sector Clear” screen
Improved rocket visibility
Improved level progression
Fixed several bugs, including net collision problems with fast-moving enemies
You can download the current versions here – and if you do, please give leave me some feedback!
I’m currently taking part in Critical Hit 2015 in Montreal, an incubator for experimental wearable games. This week, we started our first prototype! The God of Randomness teamed me up with Owen Bell, Milin Li and Mónica Rikic – so 3 of our 4 members are programmers, but luckily my team members are also great at wiring, sewing and making. The theme for the first game was “mini & forbidden”.
Our first thematic impulses were to make something with either witchcraft/voodoo or bacteria. This quickly lead to the idea that somebody is ill and must be cured by one or multiple people, possibly using magic. From there we got to our current idea: Two people are ill – their heart rate, body temperature and digestion are either two high or too low – and both try to get healthy before the other one does. To do that, they eat fruits. Each fruit raises or lowers one or two of the aforementioned properties. (To keep it replayable, those effects are randomly decided at the start of each round.) It’s a logic puzzle: The players have to find out what each fruit does by eating them, then look at their current status and figure out which fruits to eat to get healthy. In the end version of the game, there should be neither screen nor keyboard: The players actually eat real fruit with specially made forks that can sense fruit types and wear aprons with LEDs showing their status.
Read more... (671 words and 12 images, estimated 2:41 minutes reading time)
Performance rating after a level to provide context on “How good did I do?” aside from scores
Self-made score server
Lots of small bug fixes
The self-made score server was needed after Scoreoid, the service I previously used, decided to silently cease service and take all of my player’s scores with them. At first I thought it was just a short outage, but after a few months of not even being able to access the backend site it seems they just died silently. Time to depend more on the things I make myself, I guess.
Here are a few screenshots from the new build:
It feels so good to be back. Expect more updates in the coming months!
The rating period is slowly but surely nearing its end, and I thought it cannot hurt to write a postmortem for the game I made three weeks ago. I wish I would’ve promoted the game more (it’s my first online multiplayer game after all!) and I wish I could’ve played more games, but my master’s thesis was jealous and demanded I spent more time with it. That being said, I have a free minute now, so here goes nothing!
Read more... (1254 words and 2 images, estimated 5:01 minutes reading time)
Like just about every game, some lessons were learnt, and I thought I’d write a small piece about them. It’s 12 hours before the judging ends, and nobody has time to read through a novel, so I’ll keep this short!
Game & Level Design
If a level has the right difficulty for you, it’ll be too hard for everybody else. I swear I’ll remember this lesson one day, haha. That doesn’t necessarily mean “make it easier”, because in a level-based game, there is another approach:
When in doubt, make more levels. Easier levels, preferably. I should’ve spent a lot less time on the menu and instead made more transition levels. Which brings me to:
Don’t introduce more than one mechanic per level. Level 2 introduces: Lava, falling stones AND growing the snake. That’s, uh, a bit too much.
Even if you think the goal is clear, it might be not. So – better make it clearer. The goal in my game is to exit the screen to the right, like in most platformers. Some people thought that they had to eat the whole level though, which is a more Snake-like goal.
Put instructions in the first level.
Some players don’t read the instructions before starting the game – but once they are confused inside the game, make it as easy as possible to re-read them.
Art, Sound & Music
Glow is freakin’ cool. Seriously.
Homemade sound effects can be quite entertaining.
Any game needs sound effects, and since I’m no good at making them digitally, I tried to use my mouth for most. Turns out that’s a lot of fun to listen to, and I actually had a few people praise my sound design, especially the eating- and the end-of-level-sounds.
Abundant Music (music generator) + GXSCC (a MIDI chiptunes-like renderer) are the best team.
I’m no musician, so I had to use generated stuff. Those two are PERFECT. It still took very long to find songs that sound well together, but that definitly was time well spent.
Cheery music for hard and punishing gameplay.
Gnhihihihi. So much fun while watching streamers.
Trust in the process and stay open for new ideas. The concept I started out was a lot more boring, but but sometime after implementing the stones I asked myself “Okay, so those stones fall – what if gravity affects the snake too?” – and then SnakeFormer was born. So even if your initial idea isn’t perfect, go for it anyway instead of giving up, it might evolve into something great later on!
If your idea comes late, don’t worry! There’s still time! I don’t think i started any development 12 hours after the start of the compo – 8 hours sleep, 4 hours pondering. I think it paid off!
ToDo lists are great to maintain focus.
Always use a ToDo list so you won’t lose track of your next tasks. Workyflowy works best for me.
Thanks a lot for reading! I hope you enjoyed it as much as I enjoyed writing it.
Maybe I made you a bit curious about my game too? If you want to, you can play SnakeFormer here – and I don’t think I have to mention how much I like comments and ratings, do I?
I’ve been to the A MAZE./Berlin Indie Festival last week – and apart from meeting a lot of fellow game developers, playing awesome games and making weird cat glitch art at workshops, I’ve also been showcasing Catcher!
It’s been a rollercoaster of joy and frustration as I tend to be emotional when it comes to my creations, but I want to know what people really think – so often I just watched people play without telling them that I made the game. It’s incredibly humbling to see people pick up the game, try it for a short while and then walk away frustrated because they don’t get it. On the other hand, it feels so good to see people finishing sector after sector and still trying after dying countless times in the later levels!
I got lots of valuable feedback. The most important aspect to me are my observations regarding accessibility – it’s okay if people decide that the game is not for them, but it’s NOT okay if they just don’t understand how to play. Following are are the main problems and how I intend to solve them.
Using the right mouse button to close the net
Some players didn’t get that they have to use the right mouse button to close the net.
While this was explained in the wordy tutorial text in the first screen, almost nobody read that. (The best way to hide secrets in your game might just be in long text passages.)
An image might help because it’s faster to understand and draws the eye more:
This will be shown until you have finished a level where you catch at least one enemy with the right mouse button. (You can also catch enemies by making looping motions – but this is a lot harder to pull off later and players should definitely know the right mouse button method.)
Some players didn’t understand what to do at all, rammed their ships into enemies and didn’t understand that this hurts them.
While I could explain this via text, I think that’s mainly a feedback problem with three portions to it: What happened, where did it happen, and what was the result?
After my improvements, when you touch an enemy with your ships, the feedback looks like this:
What happened: “Ship Collision” is displayed. A damage sound effects plays. Bright damage particles spawn at the point where it happened.
Where did it happen: The ship that collided blinks red for a second.
What was the result: A newly introduced healthbar at the top gets smaller. (Health was always in the game, but previously only expressed in % in the upper left.)
The healthbar also refills visibly between levels, which will hopefully teach the players that their health is always full when a level starts. (One less thing I previously had to express through text, yay.)
Many players had problems with little movements. In most games little movements will be tinier and more precise – in Catcher they just don’t work at all right now and result in big unwanted turns.
I haven’t tackled this yet, but I’ll probably change the controls so they react less to little movements. This shouldn’t change how the game is played too much because right now experienced players mainly make big movements anyway – because small movements are currently imprecise and useless.
Will this work? I don’t know – but in two weeks there’s a local playtesting event here in Berlin, and I’ll watch players there. Keeping my fingers crossed! And if not: Back to the drawing board with me.
Other improvements for the next release
Other things the next release (probably soon!) will have:
Particle effects for nearly every enemy now. The game looks SO MUCH more lively now.
Lots of little bug fixes.
Visually improved catcher ships! This one was due for a long time now. They’ll point to your mouse when being apart from each other, and dock when they get close.
Thanks for reading!
After posting all those status updates on TIGForums, I thought I had to start here (and at IndieDB) too. I hope you enjoyed it – it’s just about the first time I’m posting updates on a game that is not out yet, so it’s a bit unusual for my blog.
If you’d like to play the game, just click here for a Unity webbuild and desktop downloads!
The October Berlin Mini Jam was crazy enough – we had a triple splitscreen with blinds made out of cardboard and and a MakeyMakey game using fruits and vegetables as controllers. (“And to shoot, you just touch the plum.”)
Fueled by this energy, I made this toy prototype for the theme “Lab Experiment”:
Remote Person Control
Remote Person Control (First Jam Version)
One person gets a computer and
a gamepad: The Controller.
One person gets a smartphone, earphones
and closes their eyes: The Robot.
The Controller can now steer the Robot
with transmitted voice commands:
“Left, left, stop, forward, forward…”
Like I say in the video, it’s not finished. It is just a toy right now – I ran out of time to make it a game. I’m thinking about adding commands like “Move your body” and “Move your right hand” so you can actually steer the Robot’s hands too – and then have a command like “grab” to pick up stuff, for example.
The prototype was already a fun experience even with just simple directional controls though. It feels really interesting to use a gamepad to control something in real life (and a human on top of it) instead of something on the screen!
Bugs, Bugs, Bugs
While working with Unity is normally a pleasure and developing Android has proven to be far more straightforward than other mobile platforms, this time I just got terribly unlucky. Here is how I spent my time:
4h reading up on and implementing the network stuff (connecting, waiting, synchronizing and dealing with disconnects)
For the Human-Computer Interaction course at my university we had to do a 3d interface prototype. My team decided to make a game with the Leap Motion. And thus, Zombie Planet was born in about 3 weeks: A game that you control directly with your fingers. Defend your world from invading zombies and save your people!
Zombie Planet, A Game Prototype For The Leap Motion
Visit this post for the download, screenshots and credits:
If you’re reading this, chances are that you are developing games yourself. If that’s the case, you might want to take a look (and join!) #onegameamonth. It’s a very interesting challenge/experiment which kind of gamifies the rapid game creation process. Don’t worry, you can still post a game for January and February, and if you participated in a jam (such as the Global Game Jam), you probably have some already!
For me it probably won’t be too hard (after all I’m organizing a monthly jam in addition to all of my usual projects), but there are some interesting achievements that I might aim for – finally selling a game, for example. I’ve planned this for some time now, but interestingly this “achievement” thing actually adds a little urgency to it.
Anyway, #onegameamonth looks exciting. Check it out and join me!