My first Ludum Dare. I may not have time to finish a game, but I had an idea earlier this week and this seems like a good excuse to prototype it. Between juggling some hiking to keep the wife happy, some baby playtime, and a birthday dinner, I estimate I’ll have ~20-30 hours total to tinker on this.

Tools: Flash Builder, Drop Box
(might use Flash & Photoshop if I get past the prototype stage and need some UI)

The concept is a pixel-bot arena. Working title: Mesh

Retro-pixellated arcade robot brawling growth simulation.

You start as a lowly Mesh (pixel-bot) with only 3 pixels–your “brain” pixel and two spares. When entering an arena, your goal is to gather as many pixels as possible without dying. Any two pixels of any two bots that overlap become dislodged, floating free in space. If anything collides with your brain pixel, you’re toast. If you cross over a Free Pixel, you collect it. Collected pixels first go towards reparing your bot, then into a point bank.

At the end of each mission you can buy new “permanent” pixels which you can place on your bot adjacent to any current pixel (evolution, heh). That’s probably as far as I’ll make it this weekend, but eventually the goal would be:

1. Sub-Meshes: mount a new mesh onto your base mesh to create crazy complicated compound shapes.
2. Pixel-Motors: define simple pixel paths and attach these behaviors to your sub-meshes to create wacky animated bots.
3. Evolution replay — starting with the base bot, replay the construction all the way through to the current bot.
4. Giant bossfights built with the above.
5. Populate the world with other player’s Meshes (a la first level in Spore).
6. Multi-player battle arenas built with the above.

Going to bed (3 am in California).

Have input and basic collisions working. In the scene below, the two blue/green things are Meshes. The one one the left is controlled by keyboard input while the one on the left is a stand-in for an enemy and just stands there. If either Mesh collides with a Free Pixel (or, in the case of the motionless NPC, the Free Pixels collide with the it), the Mesh will regenerate one piece (they’re both plus signs for now). If the player Mesh collides with an NPC mesh, the colliding blocks get shot off in a random direction–turning red for a few frames to connote that they just exploded (and can’t be re-absorbed right away).

Next up: Mesh Editor (for the player to add pixels), input dampening (when on a small board, don’t move so damn fast), and some basic AIs to be bad guys.

Atom Ant!

Awake now, figuring out first steps. Going to go for a hike while it’s not too hot out, but should have between ~noon and 5:30 to work uninterrupted. After that, it’s off to a beer hall for birthday libations (work is doubtful after that).

Going to get Mesh rotation working first (nothing like a little linear algebra before breakfast) and the first “arena” level fun before I start the tedious task of building a Mesh editor.

Yesterday ended up being mostly a wash game-wise (hike->nap->beer->sleep), so looking doubtful I’ll get everything in place. I build a level spec this morning, started adding some really basic UI, and used Google Spreadsheets to act as a quick level editor:

The next step is to build a few more basic UI pieces (level chrome, game over, menu), then it’s the level editor (if there’s time)

didn’t get in the mesh editor (which ties in the evolution theme), but did manage to get a basic menu-looking thing and some level switching (4 levels total)

if I get some more time I’ll keep jamming on it. I had the idea to make an arcade mode where you battle previous versions of yourself.

If I’d had even another hour to tinker with Mesh before the deadline, I probably would’ve been able to add 3-4 more levels. I’ve been pretty busy at work, but took some time to knock a few levels out at lunch one day. I’m using a Google Doc as a level designer (see image at bottom), then translate that into rough JSON, then minify the JSON and test. It’s a bit cumbersome at the moment, but quick enough that I may not bother with a level editor.

For a live look at levels as I cook ’em up: https://docs.google.com/spreadsheet/ccc?key=0AsSkS1z3LMmMdF9wMzVNQS10T3ZxRjdDUHFyOGJCakE

Also I’ll try to keep posting updated builds to a new URL on one of my dump sites: http://www.simianlogic3d.com/fun/mesh/001

Play here: http://www.simianlogic3d.com/fun/mesh/updates/002/

I put it down for a few weeks to tinker on something else, but came back to Mesh a couple of days ago. I imagine the development for this game will continue to proceed in fits and starts. It’s not the best idea I have for a game right now, but it’s a fairly known amount of work and it’s an interesting problem space.

This update includes:

• mesh editor!
  • from the main menu, press ‘u’ to enter the 5×5 editor
  • click to add/remove pixels
  • invalid placements get an ‘X’ over them–all PixelSlots must be connected to the main brain
  • press ‘esc’ to return to the main menu
• data persistence: grabbed a datamanager from a previous project and set it up to save your edits
• free pixels now fade after a couple of seconds, which gets rid of some clutter
• added a bunch of board constants (with an eye towards much larger play spaces)
• the board will now expand to the next logical size if your starting mesh would go “out of bounds”
• added “breakage” — if a mesh pixel loses its connection to its brain, all of those pixels will break off

This mesh editor will serve as the basis for a couple more editors to come. Though the one presented to the player is 5×5, it can support any dimensions. With a little more work I can retire my google doc and just edit enemies directly in the game. The next step will be to build a path editor, which is essentially the same thing but with more restrictions (consecutive moves must be adjacent and backtracking is legal).

Once I’m happy with the mesh and path editors for creating enemies, I’ll try to go nuts and get the level count up to 20-25 or so with “basic” enemies in various board sizes. The next big chunk of work is sub-meshes, which are essentially the AI enemy meshes, but attached to another mesh. To start players will probably be limited to predefined behaviors (i.e. horizontal and vertical oscillators, spinners,  patrol loops), but at some point I’d like to let players design their own submesh behaviors. I’m hoping the addition of sub-meshes will make the game dramatically more interesting and sandboxy.

Outside of the core mechanics, some design ideas are starting to gel as well. I’m thinking the player will start on this micro 5×5 editor, but unlock larger editors as they progress. A sub-mesh would be limited to the next editor down (so a 10×10 mesh can hold a 5×5 sub-mesh, which might be able to hold a 3×3 sub-mesh). Each “arena” will have an entry fee and a reward ($$$). That’s enough structure to build a pretty massive upgrade cycle—-purchase more pixels, new pixel types, unlock larger editors, unlock new sub-mesh behaviors.

Ultimately I’d love to put in a PvP mode. I looked into various flash socket servers and Node.js, but the amount of work just to do a proof of concept would be pretty substantial. I’m going to focus on “finishing” the single player prototype before I even consider tackling multiplayer.

Not much time this weekend (Saturday is pretty much a wash), but I’ll see if I can get something ready by Sunday or Monday.

Tech:

• Flash
• Flash Builder
• Some UI sugar/sound/state management from pre-existing projects.

Initial Idea

http://en.wikipedia.org/wiki/File:Linophryne_lucifer.png

For some reason, the first image that popped into my head was a crocodile lurking at the bottom of a river bed, waiting for prey. That morphed slightly into the Angler fish, which could make for a really cool graphics-light game. At the outset, then, I have two ideas:

1) Angler Fish predatory game. You start with a black screen. To shake up the bioluminescent bacteria in your “lure,” some kind of QWOP style controls could be used (or on a mobile phone, accelerometer shake). Shaking consumes energy but lures prey. A single “chomp” button would be needed to time the perfect moment to eat your pray. Angler fish don’t really have predators, so I’m mostly stuck on the game over condition. It could be running out of energy (starving to death) or maybe trying to eat something too large. Could do this with some ugly 2d graphics or get bold and bust out Unity & some sort of low-poly modeler (1st person angler fish hunting).

2) Ambush Predator. Stick with the original crocodile theme and expand it to little wario-ware style one button “attack” games. In each scene there would be an ambush predator and some prey. Your task would be to perfectly time the strike and nab the prey. Perfect timing would score more points while a miss would end the game entirely and start you over from scratch (a la Moron Test). Some predators could be: crocodile, angler fish, venus fly trap, flasher with a trenchcoat…  this is a neat idea and much easier technically, but would require a lot more art.

I made the sketches using my Wacom Inkling, thinking I’d take them into Illustrator or Flash and color them. Unfortunately I didn’t realize my pen battery was dead, so I ended up with paper sketches but nothing digital. I’ll probably just clip one out and use it as a bitmap until the pen recharges, then take another crack at it.

The other guys are potential food/enemies.

Play Version 002 here.

Spent a little while doing a better bite animation–pretty happy with it now.

Spent a little bit of time doing a belly jiggle, but I was redrawing the belly on each keyframe. I thought it would play so fast that this would be ok, but it doesn’t look that smooth. I’ll probably bite the bullet and figure out how to do a shape tween if I have time later.

open wide

Real angler fish bite on reflex when something touches their light-ball, but that’s lame for a game. Instead I hooked up the spacebar to play the bite animation (which triggers the belly jiggle on completion).

After getting animation, I built a simple shadow overlay that tracks the location of the light-ball.

not too bright

lights on

All in all, not bad for 6 hours on night one. It’s after 3 a.m., though, so I’m going to sleep. Next up:

• add some fishies to eat, then figure out hit detection on eating them. might need to shrink the main fish once it gets more crowded
• add some sharks to hide from (turn off the lights and wait for them to pass)
• add some squid tentacles to hide from (turn off the lights and wait for them to pass)
• add the mouse-shaking mechanic to activate the light

At that point the “gameplay” should be more or less done. If I get it that far, that’ll mean it’s time to add menus, sound, and some basic UI.

Instead of waiting for my Inkling pen to charge, I dusted off my wife’s old Wacom tablet from college. I grabbed the angler fish from my sketches I liked best, threw that on a guide layer in Flash, and traced the sucker. I’ve never used a drawing tablet before–it works pretty well once you get the hang of it, but it’s pretty fricking tiring to use. I imagine they’ve gotten better in the last six years or so, but it makes me wonder if all the Flash artists I know are secretly ripped in their drawing arms.

I thought the tablet was pretty cool for drawing outlines, coloring, and erasing–but for any really fine stuff I ended up switching to the mouse. Once I had the outline in, I started carving it up and rigging it in Flash. The pectoral fin, fishing lure, and upper jaw are all in one group which can pivot while the rest of the body is still fixed. I went ahead and set up a “slider” right on the jaw from fully open to fully closed, but I haven’t decided how I’m going to do an actual chomp yet.

I’ll probably break up the chin piece and the bobber into different segments so I can give them a little bit of wiggle. Skewing the pectoral fin on the y-axis does a pretty good job of making it look like it’s moving, so I’ll probably do something similar for the tailfin. I’ll probably also break the stomach off of the main body so I can do some tummy expansion and jiggles once this bad boy eats some fish.

In terms of design, I’m still very much at the “toy” phase. I threw on some simple WASD/arrow movement and set the jaw to open/close based on the x-coordinate of the mouse. Just tinkering with this gives me enough direction for where I want to go with this: instead of shaking a phone like I first thought, I’ll have the player navigate the Angler fish with WASD and “shake” the mouse to shake its lightbulb. It’s a pretty ridiculous motion (navigating with the left and shaking with the right), but I think it’ll be pretty fun.

play version 001 here

as expected, yesterday was a total wash. starting again now.

i’ll see how far i can get in 6 hours, otherwise I’ll just drop down to a Jam entry

Newest version here: Om Nom Nom

I added little AI fishies that swim around. Any fishies in range of your light will change their behavior. If they’re above you, they’ll go towards your light. If they’re below you, they see you for the monster you are and run away. How bright your light is affects how much they correct their course.

Press space to eat them when they are over your bioluminescent ball, and eating fishies causes you to get bigger.

Next step is to find the sweet spot of brightness–too close and too bright and the fishies will run away. Not bright enough and they won’t come near you. I want to make it a struggle to to get that sweet spot and not feel like angler-fish-murder-spree.

fish nom nom nom

my power grows

entertaining bug in the fish-spawning logic

This will be my third Ludum Dare… I’m using it as an excuse to experiment with Unity/Futile, so I don’t expect to make it as far as if I was going with more familiar tools (i.e. Flash or iOS native).

Tools:

• Unity / Futile
• Photoshop, Illustrator
• TexturePacker
• Glyph Designer

Art:

• I have a license for the Oryx 16-bit fantasy sprites, so it’s super tempting to make use of it (http://oryxdesignlab.com/sprites/16-bit-fantasy-sprite-set)

Brainstorming

I sat down and started sketching around the theme, first just starting with numerals. It would be kind of cool to take the theme literally and do some sort of puzzle/physics game with numerals from around the world. I did a little digging and found this helpful page (http://www.omniglot.com/language/numerals.htm):

Ultimately I ruled that idea out… being a first time Unity user, I want to do something simple and non-physics-y.

After ruling out literal numerals, I started thinking about how I might do a card game around the theme. Could you do a CCG with only one card in your hand? That might be a bit much on the content front, so how about traditional card games? Poker with one card? The idea isn’t fully baked, but I like the idea of using poker cards. At the very least, rendering and dealing a deck and some cards will get my basic intro to Futile over with.

Not having any open source card art handy, besides brainstorming my first hour has been spent slicing up a public domain SVG into individual card pieces (which can be found at http://openclipart.org/detail/171444/white-oxygen-playing-card-faces-by-lone-coder-171444). I’m thinking some sort of faux-roguelike or dungeon battling game that users poker cards for attack and defense. Or maybe something with drafting…

After being helpfully chastised/reminded not to use outside art, I cobbled together a quick and dirty set of cards in Photoshop and then texture-packed them:

On the design side, I embarrassingly couldn’t find any poker cards in the house… after a quick trip to the drug store, I returned with caffeine and cards. Physical testing (me against myself):

It’s kind of a loose interpretation of the theme…

You only get ONE card for offense.
You only get ONE card for defense.      (ok, that’s two cards)

After the initial cards, the rest are dealt one by one to each player. They must choose whether to put that card into their attack or their defense (which royally screws with regular poker odds). At this point your attack will go against their defense and their attack will go against your defense. Repeat until someone dies!

Also might go more Puzzle Questy with the mechanic–each time you cash in an attack/defense it charges your attack/defense skills (like XP into those stats). With that mechanic I could shim in a simple level progression for attack/defense and just make it an arena battle where you keep going against progressively stronger opponents.

Time to start building a simple card/deck model in C#.

This took me a half hour or so to finally figure out, which sort of the point of diving into new tech. After getting my card atlas set up and put in the right place, seemed like a super easy next step to make a single card and put it on the screen.

Not so.

Turns out my card atlas is 2048×2048, and by default Unity checks a box to down-res the size to 1024×1024. I ran through a few useless debug steps — making sure the current iphones support 2048×2048 textures (they do), making sure Unity supports that size (it does). Next step was to dive into Futile’s AddResolutionLevel to make sure I hadn’t mucked something up (I hadn’t).

After reading up and tracing through some of the resolution code, I found the image in the project folder to see what size it thought it was… and lo and behold there’s a default box checked to throttle the size down to 1024×1024. Sensible enough when you read the docs (artists like making huge textures), but an example of why I’m hesitant to use Unity in the first place… a confusing bug that was nowhere in my code!

Getting a shuffling deck set up took me a bit longer than expected (one more reason to do something as simple as a card game!), and my old man energy is flagging for the night. I also did a sort of logo/card back which turned out kinda fun:

I also roughed out a design to get cracking on in the morning… probably a bit too ambitious even for tech I know well, so we’ll see how far I make it.

The basic structure is a dungeon-less arena combat solitaire game (Gladiators?). Maybe more like Infinity Blade without the generations? You start as a lowly peon with a wooden sword and shield. You fight other peons by playing solitaire. Different poker hands map to different defensive and offensive maneuvers, which are affected by your base stats (armor & damage). The fancier your maneuvers, the faster you level up those two independent stats. Instead of having a single XP level, you have an attack level and defense level… these levels control how much damage/health you have as well as what kind of armor/weapons you can buy/equip.

Defeat an enemy (while hopefully doing fancy maneuvers to level up) to earn coins, which you spend on better gear. Repeat until you die.

I have five screens mapped out, but there’s quite a bit of UI in there — progress bars, a few FX for combat, the actual gameplay screen… but the scariest screen by far will be the store screen (if I make it that far). On top of that will be coming up with the content for the store screen (say, 20-50 levels multiplied by 2-3 interesting pieces of gear at each level… yikes!).

A good chunk of today has passed, but the game is somewhat mechanically playable now. For native iOS development, I have a Photoshop script that exports each layer as its own image along with a buttload of metadata for where things are laid out on screen. I’m using the metadata to create a Dictionary of named positions on screen, which lets me do things like spawn a card at the position name “deck” or “dealt_card.” The actual background itself is one big flattend PNG.

Next steps:

• wire up the text fields in all the correct positions
• put in the logic for figuring out your finished attack/defense hands
• add some sort of initiative display to this screen (thinking Final Fantasy style…ish)
• create a set of janky low-res bodies/heads to use for player/enemy portraits (maybe in the style of Spaceteam)

Next next steps:

• Intro/Menu screen
• start battle / maneuver screen (with health progress bars)
• you win and you lose screens

If I can get all that done today, that’ll leave tomorrow to focus on the economy/content and the store screen.

Spent a bit longer than I probably should have putting these combinations together. My character rig has 6 body parts:

• face (never changes)
• hat (28 options)
• head/skin (12 options)
• torso (8 options)
• legs (8 options)
• feet (9 options)

This image represents some of the possible combinations that will come up both as the player character and enemies in the game. I still need to do a variety of swords/bows/shields to fit in the hands, but overall I’m pretty pleased with the results. Without adding weapons yet, there are around ~193K possible enemies (but you only get one that looks like Tim Curry from Legend).

submission here

Made Art vs Found Art vs Paid Art

The competition rules say you have to make all the art yourself to get around people grabbing stuff off of Google that may or may not have a license (as well as just to make something entirely in 48 hours). I get why those rules exist, but I feel like they’re missing a few edge cases. I have a (paid) license on the Oryx 16-bit sprite set and LD would be a perfect venue to actually play with those. There’s no murkiness in the license, and the only reason not to allow stuff like that is that I guess people who haven’t paid for them might feel like their art puts them at a disadvantage. I mostly do LD for the design/engineering side, though. I could switch to the JAM, but I like the 48-hour format better.

Re: Card Art — I feel like I spent the whole first day just making the card art. I don’t think public domain poker cards would be violating the spirit of the art rules, as that’s sort of the raw material needed for designing a game on top of the standard 52-card deck. Content generators are allowed, but I didn’t see any for playing cards.

Work Flow

The Futile/Unity workflow is nicer than I thought it would be. For my current iOS projects, I do something like:

compose screens in photoshop -> export individual layers/metadata -> in code, automagically lay out screens based on filenames and metadata (including image layout, text fields, and buttons)

I tweaked my layout scripts as I was going and probably made some choices that need revisiting… but in general the workflow for Unity/Futile became:

compose screens in photoshop -> export to a metadata file + individual sprites -> texturepack as needed / create bitmap fonts as needed -> write code

I wrote a base node (an FContainer) that does most of the metadata processing and import for me. FLabels and FButtons are created where appropriate. The only thing it doesn’t do is add images automatically. Instead I create a set of named positions that I can use to anchor sprites/images. For the purposes of this tiny project, I just decided that all my dynamic text fields would be the same size and only used one BitmapFont… now that I’m not under a time crunch I’d like to

Poker Fight v1.0, v2.0?

I’m not sure if I’ll keep working on the project. It’s tempting to at least finish what I had scoped, but what then? Mobile version? Web version? Desktop downloadable? For simplicity’s sake I only put the player’s cards on screen and simulate the opponent using weighted random poker hands… but it was actually more fun testing with real cards having each player have their own hand (pulls 20 cards out of 52 instead of 10, which gives you more knowledge). Writing an AI for this isn’t all that trivial if we’re optimizing for best poker hand (and do we even want to play against a master statistician?).

Before LD 29

I’d like to take what I’ve learned/built from LD28 and contribute back to save more time for future LD’s… I see two big things to continue work on:

I want to clean up my photoshop export script and make it more Futile-friendly (y-positive, origin in the center, multiple resolutions). To go along with that, I’ll have to clean up my base Futile node (I call it MetadataNode) so that it supports all the new changes and adds some more nice things. Having this class built and ready to go for the next LD will probably save me ~4-5 hours (can just start building UI instead of architecting a UI system before building it).

I want to build a poker card generator (either in Processing.JS or maybe Flash or Adobe Air) that lets you provide the suit icons, faces, and select from 2-3 different layouts… then spits out either a sprite sheet or 52 individual cards at a chosen size. Having this tool would save me ~3-4 hours on future LD entries that are based around poker cards.