Ludum Dare 39: BatteryUnknown’s PowerGrounds

This game was made completely from scratch for LD39. After spending much of the weekend at a family function, I decided to turn in something for the Jam 🙂

The sound effects and music were made by my friend Tim specifically for this game, kudos Tim for helping me out, awesome work!

Gameplay: it’s a free-for-all; stay alive and gather batteries to keep going. You can see other players only if they’re within your line of sight, once they disappear behind a wall, they’re invisible.

Controls: Use W,A,S,D to move; Q,E to turn; Spacebar to fire. If you prefer, you can use the arrow keys to turn and move.

Libraries used for making this: Three.js, Node.js, Howler.js

Ludum Dare 38: Small World Resort Manager

Got around to participate in another Ludum Dare Compo: https://ldjam.com/events/ludum-dare/38/$16322 – and I figured I might as well post it here. Hey at least it’s an update of some kind 😉

How to play

The game should be relatively complete, barring any bugs (this is my first Compo entry so the time pressure hit much harder). Let me know if you encounter any issues.

The controls should be relatively self-explanatory. It’s a pixelated tycoon-type game. Didn’t have time for music, so you might want to queue up some Reggae or something 😉

Links

Windows: http://openfu.com/ld/ld38-files/SmallWorldResortManager_Windows.zip

Mac OS X: http://openfu.com/ld/ld38-files/SmallWorldResortManager_OSX.zip

Linux: http://openfu.com/ld/ld38-files/SmallWorldResortManager_Linux.zip

Web: http://openfu.com/ld/ld38/

Source: http://openfu.com/ld/ld38-files/ld38.compo.zip

How it was made

This game was made from scratch with the Pixi.js (http://www.pixijs.com/) library, also: Howler.js (https://howlerjs.com/), jQuery (https://jquery.com/), Minibars (github.com/udo/minibars), Pathfinding.js (github.com/qiao/PathFinding.js/), and a custom font: http://www.dafont.com/press-start-2p.font

Game 3 Canceled

flyer-canceled-i

After reflecting a lot on this, we made the decision to not go ahead with our already-late 3rd game “Flyer”.

About the game: Flyer is / was an air combat simulator where the player takes control of a hovercraft to defend a fleet of space ships in the atmosphere of a gas giant as they get attacked by drones.

time-to-stop

Why we’re stopping development:

  1. I (Udo, this is mostly from my perspective since Sven hasn’t been involved in the game) dramatically underestimated the effort required to make 3D models that actually look acceptable, as well as the general effort it takes to make a 3D game. Since we’re making these games in our spare time, and there was a distinct lack of spare time during this last month, it’s no wonder that Flyer didn’t get off the ground there.
  2. The gameplay is difficult and unrewarding. While I personally had a lot of fun playing the game, I don’t think it’s suitable for pretty much anyone else. Playability-wise the game combines the “worst” aspects of a helicopter flight simulator and a flight combat system. There are good reasons why helicopters don’t get into dogfights, but I pretty much made a game about that anyway.
  3. It’s boring. I can sit for hours and just fly around in this game, but that’s not an exportable idea of fun and engagement. Even the action scenes, when I viewed recordings of them later, felt extremely boring and confusing,
  4. The little feedback I got was negative. For the most part, people didn’t react to the game at all, which is always a bad sign. When I pressured people into giving me feedback, it was unanimously negative. On a very basic level, nobody saw why you would want to play this.

Big studios cancel games all the time for the same reasons, and I understand a little better now how that happens. I have no doubt that we could have salvaged this project by sacrificing more time to it, but that’s counter to our current mission. We want to explore and iterate on games quickly, throwing more good time after bad is not on the agenda.

Sorry if we disappointed anyone this time, but we’re already throwing around some ideas for our next project and the next time, we will have something to show for.

Why We’re Making Once Game a Month

The idea of making one game a month is certainly not new, it’s even been meta-gamified with #1GAM. One of the questions we got was why we’re not participating in #1GAM? Well, part of it is we’re busy making the actual games, and we have to choose where and how to commit our resources carefully. I briefly considered it in order to connect to other people making games, but it doesn’t seem likely for us to forge a lot of meaningful relationships in a mature community of 13,000 developers. It’s also not like we need the motivational aspects of gamification.

So Why One Release per Month?

tweet1

We need time to get comfortable with our tools and our processes, but more importantly we need to explore the space for a concept that will stick. We’re not ready to spend months chasing down one illusive idea if we’re not reasonably sure, both of our own interest in the concept and the public demand for it. It seems easy to commit to the first idea that comes our way, without knowing if anyone (including us) will care about it long term.

That being said, we aim to make our monthly game concepts high quality, fully playable downloads without game-breaking bugs. As far as we know, our last release had only one major defect regarding the persistence of savegames.

When Will We Make a Long-Term Game?

Right now we have a lot of ideas we’d like to test drive. Some of them may work out well, others may not. That’s an expected part of our process right now. We’ll commit to a longer-term project when we feel we have the experience and the data we need to make it.

Even though we’re not charging money for our monthly releases, UDVEN is fundamentally a commercial endeavor. We’ll know the right factors are in place for a bigger project when the financial aspects seem feasible – which is a good benchmark, I think.

– Udo

UDVEN Release Newsletter!

Our release mailing list is all set up! Sign up to get notified whenever we put out a new game (which is around the 10th of each month, currently).

Notify Me of UDVEN Releases


Email Format


Post Mortem: Commander Wallis and the Tentacled Menace

So last week we finished and released our first game, Commander Wallis and the Tentacled Menace, on itch.io. Here’s how we did:

commander-itch

We knew this was going to be hard, and the stats confirm that we’ll have to fight for every single user. In a crowded (market-)place, it’s hard to get noticed. On the other hand, it’s kind of great that 28 people downloaded and played our game! We feel we accomplished our goals with this release: learning the technical, design, and managerial lessons we needed.

What Went Well

The process of making a game in one month worked out pretty well. The overall strategy aspects, the story, the graphics, those turned out nicely. Technology-wise, we chose NW.JS for our platform, no game engine or framework, just a thin wrapper around WebGL – performed well for our purposes and was fun to program with. Doing lower level development without a game engine gives you certain freedoms and even speeds up development in places, but on the flip side it comes with a reduced feature set (especially since we only have a month to finish the game). In the case of Commander Wallis, this trade-off was perfectly okay.

What Could Have Been Better

The game has some pacing and UI issues which could make it less suitable for some players. I’m not sure we would have actually needed to make 10 levels, considering that most players will probably only play to the 3rd level, tops. Getting people interested in the game was very hard, and we could have made it easier by providing a press kit and some gameplay video. We also should have launched the website and the Twitter account first, to build up a (small) audience instead of just putting it online on release day without context.

These are all actionable lessons we need to keep in mind!