Ludum Dare 31
Theme:
Entire Game on One Screen

Judging ends in:
It’s time to Play and Rate Games!

PlayRate80Star

About scriptorum

Long time software developer and occasional game maker. Out of practice with the latter part, trying to get back into it.

Entries

 
Ludum Dare 31
 
Ludum Dare 28
 
Ludum Dare 27
 
Ludum Dare 26
 
MiniLD #39

scriptorum's Trophies

scriptorum's Archive

Post Mortem: Fireman vs Fire vs Snowman

Posted by
Wednesday, December 10th, 2014 11:50 pm

Fireman vs Fire vs Snowmaninstructions is an avoid-the-bouncing-obstacles game with a rock/paper/scissors twist.  The game takes place on three TV screens, each only showing the same picture but with the objects all different (e.g., whereas one TV shows a fireman, the second shows a fire, and the third a snowman).  You control which one screen is active. On the inactive screens objects blissfully ignore each other, but on the active one you control one of these objects and if it confronts another object something violent happens: either the object kills you (the object’s predator), the object stuns you (a matching object), or you kill the object (the object’s prey). To know what the interaction will be you need to be aware of which screen you’re on (which determines which object you control) and which objects are predator or prey. Killing something causes two new things to spawn, so it can get hard quick! But there are some tricks to make it easier.

This game was written in Haxe 3 using Flaxen, which combines an entity component system (Ash) with a game library (HaxePunk).

playerTiles

What went wrong

So … some things went wrong.

Ran out of time

My usual #1 item from “what went wrong” is running out of time. I fancy some day might occur where everything I put together works perfectly the first time out. I’d be done in four hours that way. Partially it’s caused from rustiness, partly from not having a clear architecture in mind and trying to use agile development. Iterative coding is a great way to focus and reduce bugs, but continuous refactoring is possibly a luxury in a game jam.  Also to blame is trying to take shortcuts that I eventually have to undo anyway, along the way these shortcuts introduce bugs during development that eat up an enormous amount of time. Also, frankly, I’m old and slow. I used to be young and slow, but I’ve never been a fast developer. I was told by an employer once, “You’re slow, but your work is ten times better than anyone else’s.” That’s what I call an affectionate slap. How do I get faster? Reuse of methodology. I’m always coding in different languages with different toolkits in different industries. If I just focused on one way of doing things since I started coding, by know I’d be the fastest coder on the planet. It’d be in TRS-80 Color Computer extended basic, but I’d be the fastest in it…

Lack of animations and special effects

Are these things important? Honestly having sound effects and a musical queue for the titling and between levels was far more vital, but how much better would this have looked with some more graphics? The fireman could actually hose the fire and leave rising steam. The fire could spread over to the snowman who falls apart before melting. And the snowman could freeze the fireman, blowing a cold wind and turning the fireman into crackling ice that then shatters. How lovely that would have been. Ah well. NEXT.

Not a pixel artist

Some of the pixel art from LDJAM participants is freakin’ amazing. I’m very envious. I’m not one of those people who believes you can’t learn, and I’ve done some pixel art tutorials in the past, but I have not practiced. I’m fairly bad at it. I’m better with non-retro art, where I can just go crazy with boxes and circles and photoshop filters, but in this game the main characters were so small there was no way around it. As such the fireman looks more like a hunter, making his relations obscure. (Hunter shoots fire?? Snowman beats hunter with own rifle??) I should practice it more, as it would help my programmer art all over.

Lack of final gameplay tweaking

Although the game was playable at the end of Saturday, it was hard to visualize what the experience would finally be like. On Sunday, I never really got to a point where I said, “Okay, here’s the completed game. Play it for 30 minutes, see what needs changing.” I had an idea that the game would be improved with wave system, bringing out a certain number of enemies at a certain rate, and giving a pause for the next wave while you feel a sense of achievement. But I had this idea too late, and if I got to play it as much as I did in the past couple days, I would have had tested a lot of changes to the difficulty ramping.

tiles

What went right

You know, I submitted a game to the compo in 48 hours, so by that very notion my game was a great success. :) But there were some things that stood out.

The right idea

As usual, I drum up three ideas for a jam before I start developing. I rejected the one that was easiest to develop because it bored me, and after conferring with my significant other also rejected the most exciting one because it would have been hardest to develop. Yay for mediocre? Nah, instead I look at it as a simple balancing issue. The idea has to be interesting, and realistically achievable in the time frame. And this was both. I can always go back to developing the “exciting but difficult” one on my own, later. In retrospect, the idea I chose was also the one I understood the most, mechanically. Those kinds of ideas are easier to prototype.

Focus on playability

I set my goal as having a playable game by the end of Saturday.  As a consequence, I stopped designing even though I didn’t have a fleshed out thematic layer for my idea. I had a list of 15 possible rock/paper/scissor replacements but didn’t like any of them. So I delayed that decision and focused on the mechanics. This meant I could go straight to coding, and it also meant I wouldn’t spend a lot of time on art, and would spend no time on animations, sounds, or special effects until the game was playable. I put together some crappy R/P/S icons and a dull, lifeless game frame, and got to the core gameplay by my self-imposed deadline.

I also was better with my time management. I kept a prioritized checklist on Sunday of things I needed to do and what could be eliminated. I came down to decisions like “do I need two distinct sound effects for these two variant events, or just one?” and “what’s more important, trying to throw together a short music track in 20 minutes or adding a rumble to the screen whenever you’re stunned?” (I chose the former, and barely snuck the tune in.)

Honing my tools before the comp

I moved this May and we sort of took an extended vacation to settle into the Charleston area. We were hosting visitors every other week for a while there! I stopped developing for all that time, and could sense the rust on me.  I updated all of my Haxe libraries. I forgot how much of my library Flaxen works, so I some time to improve the documentation while reminding myself of this toolkit. I fired up Renoise, which I hadn’t used in a year, to discover it was no longer operable. Redownloaded the latest version, found the license key, and then stared at the screen and blink while I tried to recall my workflow and any of the shortcut keys. I throw together some basic tunes just to stretch my old muscles. I should have spent some time putting together a practice game, but this was the next best thing.

Making the theme my bitch

I did not like the Ludum Dare theme “Game Entirely On One Screen” all that much.  It seemed like a very polarizing theme. I generally vote against themes that imply any sort of design limitation, as that can lead to too many games exploring similar ideas or implementing the same mechanics. Also I look to the theme to inspire, much like a writing prompt. Some folks said you shouldn’t let the theme stop you, but you do get rated on theme. I did not realize that this year you’d be able to exempt yourself from categories, although I’d probably feel dirty for not meeting the theme. To cover my bases, I met the theme in three ways:

  1. My game does not scroll, have separate backgrounds, does not have ancillary pages. My instructions are right on the screen the whole time. There is no main menu. The title, like the instructions and the UI, is made up of wooden signs that sit in the upper-right quadrant. Even the start button and “you died horribly” message are signs that peek out from under the pile and slide out when needed.
  2. The game actually contains three TV screens, but because only one is active, the game is entirely on one screen at a time. Some folks felt the need to point out that 3 > 1, as if that feat of mathematical comparison had slipped my attention. I think the three screens was my way of meeting the theme while simultaneously thumbing my nose at it. And I have a considerable proboscis to thumb.
  3. I added a snowman. Many Ludum Dares have a mascot, or some recurring popular secondary theme (potato, for example, in LD #26), and unofficially snowman was it for LD #31. Some might see this as me expressly NOT meeting the theme, but I see it as just another way in which I’m awesome. (YMMV)

It felt really good to complete a Ludum Dare. I hadn’t done so in a year, since LD #28. I failed to complete my game for #29 and I was unable to participate in #30. Thanks Mike.

Thinkin’ is easy! It only took me three hours!

Posted by
Friday, December 5th, 2014 11:03 pm

Well I did three hours of thinkin’ and I came up with three ideas that fit the theme. How do you explain where that time went? Well, there was a large glass of rye and a cigar, and also I walked the dog, and spent a lot of time talking to myself. I really don’t like to commit to an idea until I have at least three of them, and snowman johnson wilickers this theme is hard! Or very easy, if you cop out. I’m not content to simply interpret the theme as a design restriction, which makes it very hard.

I rejected all perfectly literal interpretations. The first idea is quite figurative, taking a different meaning of the word screen to mean a screen door. But it’s a bland puzzle game and my least favorite idea.

The second is literal but with a caveat, adding the words “At a Time” to the theme. This has opened up into a very doable game design, but I’m won’t be sure how fun it will until I get a working prototype. Also, it’s got a strong rock-paper-scissors element but I haven’t been able to come up with replacements for the three elements that make a lot of cohesive sense.

Finally, the third idea is the most ambitious, taking a meta approach to the theme, where the game is a story about a game. This one is in a kind of a linear, adventure style, and while I believe it would be very well received, I’m concerned that the story I need to develop before I build it and the associated asset requirements might be more than I can accomplish in the time allotted.

In short, I’m going to make myself secret sandwich and then sleep on it. The secret sandwich is a PB&J. I’ve probably said too much.

I’m in for the compo. It’s been a while since I’ve completed one of these things, but let’s give it another go, shall we?

Editor: Sublime Text 2
Language: Haxe 3/OpenFL
Frameworks: Flaxen (HaxePunk and Ash-Haxe)
Base Code: GitHub
Version Control: GitHub
Visuals: Photoshop, FilterForge
Audio: Audacity, Bfxr, Renoise and some plugins

I do enjoy working with an entity component system like Ash, even though the Haxe port hasn’t been updated much this year. I haven’t done much work on Flaxen lately,  so I really should spend a little time this week to take it for a spin and make sure everything works rather than wasting my weekend fixing my tools. Good luck, everyone!

Debacle shutdown commencing

Posted by
Sunday, April 27th, 2014 2:50 pm

I may have gotten cocky.

I failed to complete my first Ludum Dare compo (LD #25), but I learned from that experience. Since then, I focused on a single set of tools (Flaxen), rejected ideas that relied on new skills, and focused my work on leveraging my code base rather than altering it. Since then I submitted games into the next three Compos and a MiniLD.

Maybe those experiences went to my head. This time, I broke all my rules and never got close to a bare prototype, let alone a finished game.

I spend the first hour of the compo just brainstorming. I have a cigar, walk the dog, sit on the deck, maybe have a little drink and just ponder. I turn the theme over in my head, rejecting what I think will be common interpretations, applying the theme literally and figuratively, looking for the things that live beneath the surface or things trying to escape it. In this case I came up with several ideas, here were the top three:

  1. A plant simulator, where you plant seeds that develop roots through the various minerals of the Earth, taking what they need to grow, poking through the surface if they need sunlight or rain. Each plant sufficiently tended to would grow a different seed, which would grow a different type of plant. Figuring out how to grow Plant #10 was the goal. I loved this idea, but it seemed a bit similar to my LD#27 submission Offspring, and designing the plants and growth system might be complicated.
  2. A giant worm that travels through the Earth and is hard to steer (similar in complication but different in mechanics to a Flappy Bird/Whatever). This would be an endless game, as you tried to maintain speed, avoid obstacles, conserve energy and eat! You could leap out of the ground (losing steering) to try and bag a land mammal for your supper. This was a fun concept. I thought the worm might be tricky, and the success of the game would depend entirely on how good the steering felt.
  3. A prospector on the frontier falls into a well. It’s a long way up. This is a climbing simulator. You drag one limb at a time from hold to hold, risking losing your grip or slipping if you put too much strain on one limb. This was a simple game, and there was some opportunity for me to add some comedic lift by having the prospector narrate his climb and use audio to indicate what limb was under the most strain. Since this was the simplest, and this was Melissa’s favorite of the three, I went for this idea.

However the third idea had a serious caveat – I need to implement some rigid body physics, which I have little experience in. I decided to do a little exploratory prototyping to see if I could refit Flaxen to support some basic rag dolling. After a number of false starts and failed attempts, somewhere along the line I realized the day was gone. Despite my plan, I spent the whole day trying different approaches to squeeze physics into this engine. I was reasonably certain at this point that it would require a major refactoring to add this support.

Here was the end of day one. I could have picked one of the other ideas, but to do them in 24 hours was an uninspiring limitation. I decided to instead focus my time on a third party physics engine for Haxe. If I was lucky, I would pick it up in a  few hours and be somewhat back on track with the Prospector. I researched a bit between Nape, Box2D, and PhysAxe. Nape seemed to be the most popular, so I went with that one. I discovered several things: Nape is cool. Nape is complicated. Nape is not doing what I want.

I spent most of today messing around with it. Integrating Nape with Flaxen was very simple, just adding a System that loops through all entities with Nape components and using the data therein to update the associated Position and Rotation components. After some time I was able to get my model which I assembled in Spriter to show up statically in Nape. However I spent the rest of the day struggling with constraints and joints, failing to get them to work as I expected them to. I’ll keep plugging on, learning the Nape way of doing things, because it’s a very cool tool to add to my repertoire. But as for this compo, it’s time to shut down!

Good luck to everyone who submitted a game, and particularly everyone who is racing to complete a game before the deadline. :)

spriter

Ugh

Posted by
Saturday, April 26th, 2014 1:01 pm

As it turns out, creating a rigid body physics system from scratch during a 48-hour game jam is not such a great idea.

My idea stars a prospector on the frontier, who slips and falls into deep chasm. He survives, but has to climb out. To do this, you control the limbs of the climber, dragging them from hold to hold. Ideally the game would calculate how much strain each limb was under, and he could lose grip and fall again. I picked this one because (so I thought) it was the simplest of the ideas I had come up with. Here’s the art I did for it. Ignore his missing limbs, they would just be mirrored in the game.

sshot1

Unfortunately, Flaxen (my base code) doesn’t handle hierarchical transformations, let alone joints and rigid body constraints. I’ve wasted hours today just getting a positional transform to cascade, but this is worthless without also handling rotation. (And scale? Fuhgeddaboudit!) I’m feeling stupid for even trying.

So at this point, I’m going to do a cursory search for some rigid body physics libraries for Haxe, but it seems unlikely I’ll find anything that will integrate quickly with my library Flaxen, let alone the dependent libraries of Ash and HaxePunk. Then I’ve gotta decide if there’s enough time for a plan B, or do I just call up my friends and say never mind, I’m coming with you.

Oh framework

Posted by
Saturday, April 26th, 2014 10:41 am

Man! I waste so much time updating my framework to add new core functionality, when I should be building the game. My base code doesn’t handle nested position/scope very well, but ?!@$*! this isn’t the time to be fixing that! Gotta get back on target…

Ludum Dare 29: Entry announcement/waffling

Posted by
Wednesday, April 23rd, 2014 8:14 am

Ludum Dare always seems to arrive during busy moments in my life. In this case, we’re moving to another state in about two weeks.  Things are busy busy busy.  So, at this point I feel like I’m in, but there’s a chance I’ll have to bail.

Editor: Sublime Text 2
Language: Haxe 3/OpenFL
Frameworks: HaxePunk and Ash-Haxe (ECS)
Base code: Flaxen
Visuals: Photoshop, FilterForge
Audio: Audacity, Bfxr, Renoise and some plugins
Version ControlGitHub

Regardless, have a good LD, everyone!

You Set Us Up The Bomb: Post-Mortem

Posted by
Friday, January 3rd, 2014 7:31 pm

explosionYou Set Us Up The Bomb is chain-reaction style game with lots of explosions. It takes place on a military robot base, and you know what? Robots are dicks. It’s time to bomb their metallic rears back to the industrial age.  You only get one bomb, but you get to drop it anywhere, and as luck would have it, pretty much everything on a robot base is darn explosive.

 

What Went Wrong

bombTime ran out

Oh, this old chestnut. There’s always a list of what I intended to get in there. I’ve never not run out of time in a jam, it’s just a question of will the game be playable before I finish. Even as an old coder I still have trouble with time management. I’ve never been the fastest coder on the planet, so it’s a wonderful feeling to complete a jam. But complete is relative. My first jam I didn’t even submit it; I had these monks walking around an empty procedurally mapped abbey with nothing to do. Since them I’ve improved my focus and priorities, and also my workflow (see what went right), so games get completed, but damn if I’m not jealous of those people who knock out these home runs with time to spare. I feel like I’m getting better, though, but I have to wonder if jams are like speed chess? In Searching for Bobby Fischer, the chess coach Bruce Pandolfini chastises the student for playing speed chess in the park because it’s teaching him all the wrong things: tactics and intimidation, rather than long term strategy. Will Pandolfini yell at me for learning all the wrong things from jams? I actually took a chess class in college and he was the instructor, but this topic didn’t come up…

bombBugs in the base code and libraries

You only get 48 hours, you don’t want to spend any of that time fixing bugs in your base code or third party libraries. I must have spent about 10 hours tracking down numerous issues. None of these issues were the fault of my game code – that’s not to say I didn’t have bugs there, but those bugs resolved themselves rather quickly. First I had to isolate the code in my game, and if that didn’t reveal a bug in my game, I had to test Flaxen, my base code which relies on two other libraries. I found some bugs there that were head scratchers. But worse then I had dig deeper into my dependencies and found several issues in HaxePunk, which I either fixed or made a work around. That’s 10 hours I could have used polishing my game.

bombDidn’t hit all of my core feature list

Remember I said I had a list of what I intended to get in there but I ran out of time? Well, first, I wanted to have trucks go on patrols between tents, bunkers, and stockpiles, but instead they just wander randomly, which actually makes some of the middle levels a little harder than the early or late levels! I intended to show damage on all objects, and set them on fire if they were going to explode. The robots themselves were supposed to run screaming before exploding, and I wanted their body parts — notably their heads – to fly up toward the camera with some funny quips before landing. I also wanted shrapnel – when something exploded, parts of it could fly randomly a large distance, potentially hitting another object and setting that one off. It’s still playable without these things, but I think the game would be much more exciting with them. Also the game should get harder – each level requires like 65% of all “points” to be exploded to pass to the next level. That number should rise as the levels rise.

 

What Went Right

bombSticking with familiar tools

I think I’ve finally got my process down. Photoshop and Filter Forge for the art. Audacity, a mic, and bfxr covered my sound needs. I would have used Renoise to compose some music had I the time, but with five minutes to spare I sang an improvised song about not having time to create a song and hooked it into the main menu. Hey, you gotta move quick in the last hour! I used Sublime and Haxe 3 for development.  Flaxen, the framework I used preciously for LD27 came to use again here, except this time I separated out the code base and put it up on GitHub. Flaxen ties together an entity component system (Ash) with a game library (HaxePunk). It’s actually really fun to start throwing components and systems together.

bombFocusing on the making it playable first

Several times I stopped myself from going down tangents before the core idea was even playable: polishing art, tweaking sounds, working on higher level code elements. And it’s a good thing, too, because it took me much longer to get the core idea playable than I anticipated. This was the difference between a incomplete but playable game, and a more fleshed out idea that’s not at all playable.

bombExplosions are furn! Ehrmegerd!

Despite everything that didn’t get implemented, the core explosions and destruction are actually fun to behold when you get a good chain going. The effect turned out pretty well, I think, layering a randomly rotated explosion image (shown at the top), applying a layer of fire particles, and then after a pause a layer of smoke particles over the top. It’s especially fun when you get beyond level 14, where the game starts repeating with the maximum number of objects on the screen. Why are you waiting for the perfectly timed bomb drop? Just drop it already, the game gives you another bomb if you fail to meet the quota, just destroy some shit already, will you???

You can play You Set Us Up The Bomb here.

You Only Explode Once

Posted by
Sunday, December 15th, 2013 1:15 pm

Which is a better title: You Only Explode Once or You Set Us Up One Bomb?

Now look at my ‘splosion. Stare at it. It beckons you:

 

explosion

You only get one half day

Posted by
Sunday, December 15th, 2013 7:11 am

12 hours to go! Get crackin, you dairy farmers, lets go!

I spent way too many hours last night stumbling across and fixing bugs in my game library.  And my robots look stupid. Stupid. I’ve got stupid freakin robots in my game. 12 hours to fix the stupid robots.

 

Screen Shot 2013-12-15 at 9.07.21 AM

Screen Shot 2013-12-15 at 9.07.21 AM

Screen Shot 2013-12-15 at 9.07.21 AM

Screen Shot 2013-12-15 at 9.07.21 AM

Posted by
Saturday, December 14th, 2013 6:34 pm
Screen Shot 2013-12-14 at 8.19.59 PM

Die die die you robot army scum!

I’m making some progress. Right now you can drop a bomb on the robot army, and if the blast radius intersects with something explosive, that also explodes.  Now it’s time to get the jeeps and robots patrolling about.

I wasted a good chunk of time dealing with particle emitter bugs I introduced into the library. (Oops.) When the explosions start chaining it makes Flash chug a bit, but I have to tweak the particle effects later anyway; I’ll probably trim the particle count and add some pre rendered bits. Another time waster was fiddling with the art instead of just using temporary art. If I had placeholdered instead, I’d be at the halfway mark with balanced game mechanics instead of just starting that. And I also wasted energy putting together a random level generator, which is cool, but it’s not very balanced, and it took several hours to do.  Someday I’ll learn…

Now that it’s 8:30pm where I am, here comes the difficult decision: Do I caffeinate???

You Only Get One post before I go to bed

Posted by
Friday, December 13th, 2013 9:37 pm

Okay, I’ve got three ideas. I fleshed them all out, went over all the pros and cons of each. Partially I’m looking for the funnest game, but more so I need the one that I can best picture completing. My designs tend to have some gaps in them, and it’s a crap shoot to fill in those details later. Maybe the details fill in nice, in time, and it’s great, but I’d rather not have a moving target when it’s a 48 (er, 45.5) hour deadline.

I first kicked out the idea of the one-legged ass kicking competition simulation. The mechanics of figuring out how to keep a guy hopping and kicking without falling over sounds like fun but will require a lot of balancing, which I may not have time for.

Next I eliminated “Brat Attack,” the game about a toddler who wreaks havoc after being denied a second piece of candy. This one is probably funniest, and while I can picture an opening cinematic that makes me chuckle, there are considerable gaps in how I will render this first baby shooter in pseudo 3D. Ultimately, if I completed it, I think it would be regarded as a humorous take on the terrible twos, but perhaps fall shy in the fun department.

That leaves my ultimate choice, “You Set Us Up One Bomb.” It’s a derivation of those chain reaction games, but with a few more moving parts that I hope folks will see as adding innovation instead of recycling. We’ll be dropping a bomb on a base and the enemy and materials getting destroyed, on fire, and flung as shrapnel. I originally envisioned the enemy as human, and that just started to seem gruesome after a while, so now you’re going to be killing robots. If I have enough time, I would like to record some robot interjections as their heads go flying. Should be entertaining.

So get started coding, would you? Okay fine, I will, stop harassing me.

[cache: storing page]