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
• Improved tutorial
• Improved feedback
• 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!

• Windows
• Linux
• Mac

A few examples of the new background:

Another thing that changed is that enemies now have appearing animations! Instead of just suddenly being there, they are generated out of particles using Particle Playground:

Next up:

• Prototyping and testing of two new game modes
• Experiments with limited net count
• Improved sound effects
• Rework the whole ingame and menu UI

The Concept

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.

After we got that game idea, we found Pixelate, a “Guitar-Hero-style eating game which detects food you are eating”. We did our own Arduino sketches and fruit resistance experiments, but were heavily inspired by the fork they used.

But enough text – have a few pictures of us working on it over the week!

Working on the Game

The Playtesting Session

On Friday, all the games made this week were put through their paces to find out what works and what should be improved next week. We didn’t have our physical parts ready yet, so the digital prototype I made had to substitute for the full experience. I occasionally tested with people over the week, but never with two people who hadn’t played before – and (in retrospect unsurprisingly) it didn’t go very well: Most people didn’t figure out how the fruits worked. Other complaints were that the feedback is too subtle and/or lacking, that the two players barely interact and that the competition doesn’t put enough pressure on the player. Another thing that didn’t work out well was using fruits: Some people thought those fruits have effects like their real counterparts, while the effects are actually randomized each round.

I talked a lot at the end with Tom Fennewald, who participated in the playtesting sessions. Among other things, he suggested that the basic mechanic of the game is fine and what is really missing is adjustable transparency as difficulty: Show what the fruits actually do to start it out like a tutorial, then slowly make it harder by hiding effects.

We will try this and other ideas that we had next week. I’m looking forward to see where this is going!

Oh, and I definitely learned one thing: I should test things more and earlier.

The new release features:

• A short tutorial (and it’s about time!)
• Particle effects for every enemy
• Better-looking player ships and improved feedback on taking damage
• Improved movement controls
• 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!

Design

Three weeks ago, when I was still young and inexperienced, I thought that “Connected Worlds” lends itself perfectly well to making an online multiplayer game. (Nevermind that I never did one before, haha.) That being said, there are some obvious design problems that I needed to solve – and that ultimately led to the current design:

• LD rating is 3 weeks, and people likely won’t play all at once. To tackle that, the game should a) be able to be finished single-player too.
• Even if people are online at the same time, they probably won’t arrive at the same time – and likely don’t want to wait either. For that reason, I made the game drop-in/drop-out: The first player to join starts a new session that ends when the last player leaves or the game is won/lost. Any player that arrives in the meantime just spawns next to the torch. (I briefly entertained the idea of one permanent session, but I wouldn’t want to do the level design for THAT, phew. Also I highly doubted that players would come back often enough for that to be interesting.)
• Synchronisation is hard. So, uh, nothing twitchy. More slowly. With tiles to walk on.
• Synchronisation might not work correctly. I have no idea what I’m doing after all. So, better do a co-op game and nobody gets pissed that the enemy had an advantage.

Okay, so a scalable drop-in/drop-out co-op online multiplayer game. This is basically what I spent my complete first day on, and I had no idea what I actually wanted to do gameplay-wise yet. I implemented a chat though: Just text that appears on top of player’s heads.

After a good night’s sleep, I arrived at the idea spawning from the Olympic torch relay: A flame had to be transported from A to B – in this case between two kingdoms. Slowly everything clicked together: It was dark, hence the flame is important. If you drop it, it’s not protected anymore and slowly dies down, and you have to drop it sometimes because it’s heavy as hell. And there are multiple obstacles that you have to dig through or build across. You can do it alone if you react fast, but it’s stressful always to drop the flame, dig/build a little, pick it up again, transport it, drop it etc. – it’s much better with friends helping you! So yeah, here we go – a game that you can play alone or with “any” number of friends.

Implementation

The game is made in Unity and with the SDK from (and hosted by) Yahoo Game Networks. Free hosting for up to 5000 daily users? Yes please.

There is a server, but it doesn’t do much – it mainly keeps track of the users, items on the floor and already dug-out rocks so that it can inform new players. It also distributes events. The only thing that it is really authoritative about is when an item is spawned, picked up or dropped to avoid item duplication.

On the client side, you are the only player that moves directly – and you send messages to the server how you move. Because movement is between tiles, those messages are few, and they will arrive in roughly the same interval in which they are send, so on the other screens you move the same way, just with a delay. Each player object has an event queue – move, dig, build bridge etc – that will be executed in that order with the appropriate delays, so it’s no problem if messages arrive to quickly either.

Making the server mostly non-authoritative and using that message queue system is what helped me be able to finish the game in such a short time, I think.

What didn’t go so well?

• No sound effects. I wish I had some, but I finished the level itself in last second, and well – that was a bit more important, I guess.
• Nobody invites their friends to play. I wish I knew why. It’s super easy – just share a link – but many people commented that they had to play alone. I suppose they do have friends, right? Maybe even game developer friends?

Apart from that, I’m actually largely content! Sure, there’s not that much gameplay, but it’s fun – and sure, the graphics could be better, but hey! 48 hours and first time online multiplayer! I’m certainly not complaining. Which leads me to…

What went well?

• Online Multiplayer in 48 hours, that’s what!
• The whole thing is surprisingly stable, if sometimes a little laggy. I would’ve expected to have more problems with an online multiplayer game.
• Development wasn’t as hard as expected. I was always a bit wary of networked multiplayer in any form, but it turns out that it wasn’t that bad to always have a server and often two windows running. Might be because it was only 48 hours and a small-scoped project with no necessary security though.
• The Drop-in/Drop-out is cool. And it also has the side effect of allowing people to spectate games. Apropos drop-in/drop-out…
• The game is a lot of fun with streamers! Allowing for a variable number of players that can join anytime, and streamers having an audience already made for great fun a lot of time.
• The chat is refreshingly different. Having text appear on top of the heads is cool, but seeing it being typed live is surprisingly even more fun!

Tips

• Trust in the process. Seriously, don’t worry if your design is not complete yet. I didn’t have any core gameplay ideas until 12 hours before the end and I still finished with something. Just work towards that goal until then.
• Keep a ToDo list. Workflowy is superb for that. Helps me stay on course and motivated.
• Keep your design simple and modular. Especially if you do something big technology-wise that you haven’t attempted before. If you finish early, you can still add more features! I would’ve loved to have enemies and defending each other, or wind zones where you have to keep the flame safe, and… but time ran out, and the current state is very playable.
  
• Test early. I started testing long before I had actual gameplay. I guess networked games are special in that regard though.

In Conclusion…

…I’m quite happy with the result, and I’m seriously considering doing a game with online components for next LD too. So much inspiring online stuff this LD, damn! And maybe I’ll even get a chance to gather more networked multiplayer experience by then, but knowing me, I won’t and I’ll just dive right in. Wouldn’t have it any other way, really.

Do you have any questions? Feel free to ask them in the comments or on Twitter!

And maybe you have a free minute or two and want to try my game? (And maybe ask a friend to join you! Friends are pretty cool.)

If you’d like to, you can play it here.

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.

Process

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.)

Damage feedback

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.)

Little movements

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

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)
• 0,5h getting and eating food
• 1,5h “fun” while trying to get Unity/ADB to recognize the HTC Nexus One Mini Christiaan lent me
• 1h “fun” with “Unable to find suitable jdk installation Please make sure you have a suitable jdk installation. Android development requires at least JDK 6 (1.6)”
• 15min “fun” with “Error building Player: ArgumentException: Illegal characters in path.”
• 40min of actually implementing the gameplay: Input/Sound
• 5min testing and generally being a happy person

Closing Words

And now, a screenshot from the video, so that Facebook etcetera knows which image to use:

Who knows where exactly I’ll take this? Certainly not me, although I have some ideas. Maybe the next jam will be the time to find out!

]]> https://blog.dragonlab.de/2013/09/remote-person-control-first-jam-prototype/feed/ 1 1417 https://blog.dragonlab.de/2013/07/zombie-planet-video/ https://blog.dragonlab.de/2013/07/zombie-planet-video/#respond Mon, 01 Jul 2013 20:51:52 +0000 http://blog.dragonlab.de/?p=1178 Continue reading Zombie Planet, A Game Prototype For The Leap Motion (Gameplay Video)]]> 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!

Visit this post for the download, screenshots and credits:

Zombie Planet, A Game Prototype For The Leap Motion

The source code is released under the terms of the GPL v3.

The assets (meshes, textures etc) are not released under any particular license. Unless mentioned otherwise on their respective source websites stated in the credits, you are not allowed to use them.

If you’d like to use them anyway, feel free to contact me!

Disclaimer: The project was for a university course. Due to time constraints and that not being a requirement, the code is not well documented nor does the documentation fit the C# standards.

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!