Prototyping Zems for Ludum Dare 29
Next weekend (not this coming weekend, but the one after that) will be Ludum Dare 29. I plan on participating in the team-based portion of it, and I will be working with a Unity developer from Belgium on creating a basic prototype of Zems. I will try to use Zems artwork for the board and the card template, but I will refrain from using any high-quality artwork in this prototype. My goal is to have barebones gameplay functionality implemented so players can get a general idea of how Zems gameplay will work.
Another reason why I will be prototyping Zems for LD29 is because I might actually develop the complete game in Unity, after not wanting to for the longest time.
Why I Didn’t Want To Use Unity (originally) for Zems
The main issue I had with Unity is that users had to download the Unity Web Player to play a game on their browser. While this isn’t that big of an issue, I know from marketing and sales lessons that the more steps you put in front of the user, the greater the chance that user will be turned away or quit mid-process. This means if I throw up a bunch of fancy screenshots and videos of a completed game and then say, “You need to download this web player to run the game,” a significant number of players will leave the page and likely never come back, despite all the fancy advertising you did to lure them in.
This is especially true in the evolving browser games market today, where people can play games without waiting (except for a loading screen) through Flash or HTML5/JS (sometimes with WebGL acceleration if the browser supports it). While Flash games also require a plugin, Flash has been around for so long that 95% of all computers today ship with Flash preinstalled. Unity, at the time of writing, boasts the incredible power to build for multiple platforms such as desktops and mobile phones, but for brower-based games it still required players to run its Unity Web Player.
A few weeks ago, Unity3D unveiled plans for the upcoming Unity 5. One of the planned add-on features is the ability to export to WebGL, which means browser-based games will no longer have to rely on the Unity Web Player and can instead be run through the browser with hardware acceleration. This is huge when it comes to considering Unity for browser-based games, and this feature alone was enough to convince me that the Unity team is moving in the right direction for the future of games development. I can confidently say that now I won’t have to find something else to develop Zems in since I’m quite comfortable using Unity, and that Zems might even be playable on mobile devices in the far future.
My Ludum Dare Career (So Far)
When I last participated in ludum dare, it was #26 and it didn’t go so well. I was using Construct 2 at the time, working with another developer and an artist, and we were trying to create a noir game. Our project was pretty ambitious, and I’ve since learned to scale things back (which might not actually be a lesson learned since I plan on prototyping Zems for this ludum dare). I’m not even sure we turned in a fully functional game, since I wasn’t the one in charge of putting it all together. Regardless of what happened, I learned the harsh lesson that finishing something in 72 hours is insanely hard unless you are doing something super basic.
The team behind LD26, excepting myself, wanted to continue production on our project and turn it into a full game. They set up a website for it here: Walk Softly, although there hasn’t been an update for about 6 months now so I assume the project is dead.
Goals for Ludum Dare 29
I admit I am cheating a little bit because we’re technically not supposed to start on the project until the weekend of the event. However, my goal is to produce a semi-polished prototype of basic Zems gameplay within one week after the event, so I figured I might as well start now on setting up the scene and various other things. I won’t actually be starting on the game functionality itself until the weekend – that’s how I justify my ‘head start’.
72 hours is not a lot of time, especially since I don’t plan on cutting sleep for it like I did for my last LD. I think sleep is important and that a weekend event like this one shouldn’t cause drastic changes to one’s rhythmic schedule. For these reasons, I’m keeping my goals quite simple (but not really so simple, as we all know):
- Basic singleplayer 1v1 gameplay featuring only Hero, Creature, and Invocation (spell) cards. No other cards planned for the full game will be implemented.
- 10 unique cards, with 3 copies of each. Each player will get a 30 card deck to play with, and I will determine these 10 cards prior to the weekend.
- Deck shuffling.
- Drawing opening hand.
- Partial mulligan.
- Single shrine for both players, without the ability to build more.
- Action system with the following actions supported: add a card from deck to hand, play a card
- Combat system between creatures/Heroes, (with both melee and ranged attacks if time permits)
- Creature/Hero ability activation
- Victory screen/loss screen
This is actually a lot for 72 hours, but that’s what the headstart is for – the Belgian developer already has some of these things already developed, such as deck shuffling and drawing the opening hand. I know we need to adhere to a theme for the event, but I’m confident we can fit the theme in there no matter what the theme actually is.