Posts Tagged ‘LDCompo’

spin-circle

Posted by (twitter: @@Modoc_Dev)
Monday, December 14th, 2015 9:18 am

spin-circle

Here we are, my little write up. First things first. Here is a .gif of my game if you haven’t seen it yet. And if you haven’t played it yet and want too, just click the image :)

 


spin-circle development log.

Day 1

So spent the first few hours trying to think of an idea. I had a couple come to mind, but turned out I couldn’t draw a shark. (Not like the ones in Shark Wars entry). So I re-thought my ideas, and this is what I came up with.
The rest of the day mainly consisted of 1 getting main code done, 2 graphics for feel.
Sometimes it is hard to get an idea and feel without graphics. At the start of development, it seemed quite bland so particle effects were added for appeal and interest.

At the end, after finishing the main code and happy at when it was a good finishing point, I created a to do list to help me remember what I was in needed of doing.

Day 2

With my handy to do list, I got right onto the music. At first, I went with a more upbeat feel, but do me the game didn’t lend itself to it at first. I decided to do something different with sound, than I have done before, after watching an awesome YouTuber’s video on adaptive soundtracks. So now, it starts off nice and slow, and as you progress the music intensify (to a degree) with the difficulty of the game.
With base code, feel graphics and sound out of the way, I spent the rest of the day optimizing, balancing, smoothing transitions, updating graphics and normalizing sound.


Now, release onto Windows, web (automatic WebGl), and Android (via Google Play) with highscores.
Future, improve gameplay, release a HD version for Android.

Once again, Ludum Dare was a great experience. You learn more, improve skills, touch up in areas and well have fun! If you are programming and can’t seem to finish a project, DO LUDUM DARE! Trust me, it helps.
Hopefully, all going well, I’ll be joining Ludum Dare 35 for another challenge.

spin-circle

Breaking News: Progress Report from Planet Spinny Growy

Posted by
Saturday, December 12th, 2015 8:43 pm

ss

I have a playable game tonight! I can rotate my barren planet around using the left/right arrows (that’s two controls, check it) and the rain increases the growth rate of my plants (you heard the word growth, right?). So okay, maybe that’s a loose definition of playable, but it demonstrates the core concept, which is a bar I don’t usually hit by Saturday night. Sure I don’t have any levels, I only have one kind of plant, and a lame growth animation, and I’m missing numerous key game elements, and there’s no music or sound or menus, and there’s really no goal other than watching the plants grow … but screw you, man! It’s playable! Woo!

I gotta keep the energy level up in here before I fall asleep on this pile of candy wrappers.

Such fancy post

Posted by
Thursday, December 10th, 2015 6:26 pm

I’m in for the compo. For a change of pace and to improve my repertoire I’m doing this in Unity. Hopefully my Haxe friends forgive me.

Game Engine: Unity5 in 2D
Language: C#
Editor: MonoDevelop
Base CodeSpewnity (just some random bits of code)
Version Control: Game Source
Graphics: Photoshop, FilterForge, possible Pixen
Sound: Audacity, Bfxr, Renoise w/VST plugins
Puppies: Who doesn’t love puppies? Nazis, that’s who.

Bad Tivo

No! Bad Tivo!

 

Good luck in the jam, and don’t forget to train your DVR.

 

 

 

Post-mortem: Flappy Monster

Posted by
Friday, August 28th, 2015 1:55 pm

Flappy Monster is a nod to helicopter-in-a-cave style flight games, and turns them sideways. More popularly known as “Flappy Bird” games, the thrust/gravity/navigation mechanic has been around for a while. In my twist, I gave the monster ineffectual wings. Flapping makes him angry (because he can’t fly) so he runs, runs faster, through buildings and forts of humans civilization who desperately lay down sharp pikes to stop him.

WHAT WENT WRONG

Idea waffling

I start each game jam by walking the dog and talking to myself like a weirdo. I run through the possible interpretations of the theme, what I think others might do, and how I might distinguish myself. When I get back, I have a drink (this time it was Remy cognac), sit on the porch, smoke a cigar and brainstorm. Normally by the end of the evening I have several ideas fleshed out and I’ve at least picked one, with the core mechanics designed. But this time, I was flustered, and was waffling between two ideas until 4AM.

The first idea was an homage to The Thing where you were accused of being the monster (but not actually). It was somewhat a logic game, where you knew little facts about the other people that clued you into who was the monster. Anyone left alone with the monster could become infected, and then you had two monsters. You assigned characters to do tasks which revealed more clues about who’s the monster. Characters would have trust levels with each other, making this task harder, and ultimately putting suspicion upon you, perhaps leading you to becoming infected yourself. I loved the idea, but I spent hours researching logic puzzle design and failed to nail down precise core mechanics.

The other idea was a chasing game. People thought you were a monster and chased you, and you responded nonviolently. If they grabbed you, they held you in place until you shrugged them off. If you stayed held long enough (perhaps because several people grabbed you), your health would begin to drop. The twist was when your health reached a lower threshold, you’d explode with rage, killing everyone on the map. So ultimately you are the monster (albeit provoked), and your goal is to survive long enough. I eventually settled on this idea, but I was still analyzing mechanics in the morning, trying to figure out how to make the chase exciting. Ultimately when it got to noon, I acknowledged that this design had too many issues and no time to work on them.

I came up with the Flappy Monster idea as an alternative, as something I thought I could build with the time remaining.

Poor prep

I generally code Haxe using the Sublime 3 text editor. It’s not an IDE. It has support for templates but I don’t use them. It has support for completion, code style, and shortcuts using the Clemos Haxe Bundle but I had trouble getting it working properly and stopped using it a while ago.

Under the hood, Flaxen uses Ash-Haxe as an entity-component system. The benefits of this system are only realized if you actually use systems and components to address states and behaviors in your game. These things require some boilerplate code. Not a lot, but when I’m coding under the gun, the extra minute it takes to set up this boilerplate and locate the file in the appropriate location seems like forever.

So instead I start hacking. The code base gets ugly, cluttered, and hard to extend very quickly, and by the end of the 48 hours I’m fighting kode krud in my desperate attempt to cram in one more feature. Next time I’ll put together some templates and macros to make this process quicker, and keep me leveraging the ECS.

Also, I had little practice with Spriter. While I love the ability to do custom animations in it, it’s a buggy and very quirky app. Between Spriter and TexturePacker, I was trying to discover an efficient art pipeline that wouldn’t drive me nuts. In the end, I barely escaped a Lovecraftian descent into insanity. Seriously Spriter, I have to enter my custom rect every time? You can’t save that shit in the scml file? Jerk.

Ran out of time

This “what went wrong” is always on my post-mortem list. And every time it’s my fault. Because I know I have 48 hours and only 48 hours to make a game, yet I “blow the time budget” at various points. I have to be more ruthless in my time management. Unknowns are a killer and a time sink, so prepare as much as possible, and if the design is not coming together quickly – ditch it!

As one gets to the end of the deadline, things stop dropping off your to-do list in favor of more critical priorities. In my case music and more special effects never happened. And the game would have benefited immensely from another hour of playtesting and tweaking. But that’s alway the case!

Users complained that the pikes were hard to see, the difficulty was brutal, the RNG was unfair, and the monster took too long to slow down. All true, my friends, all true.

WHAT WENT RIGHT

Knowing when to scrap a bad plan

I’m glad I switched ideas.

The chase game was still stuck in design, and I’ve been bitten before jumping into development without thoroughly understood gameplay. The idea I came up with was a twist on Flappy Bird, placing it on its side. Instead of flapping for height, you flapped for running speed. Instead of the “height” of a hurdle to get over, buildings of different sizes required a minimum speed to run through (or you get knocked back and your game ends). And to simulate a “roof” to duck under, I added pikes in the ground that you could only tiptoe through; if you ran too fast, you’d trip and get impaled.

It’s a decent twist. It doesn’t quite provide the same depth of experience as a flying game. For example, when flying you may have to fall half way down the screen, but in Flappy Monster (where the running speed correlates to flying height) there are no pikes that require a max of “half” speed. All pikes require you to go pretty slowly, so as a result pikes right before buildings can be quite punishing.

Completed!

Out of 9 Ludum Dares, I’ve completed 6. That’s a terrible stat that shows I have persistent issues with time management. In some cases I’ve hit the deadline very close to a playable game, which I consider a minimum requirement for submitting. (Some people don’t.) Despite my fumbles, I (eventually) leveraged my ability to recognize when plans needed to change, I identified and shifted priorities, and most importantly, I placed utmost priority and focus on the goal completion. Without that, no game!

Working on a Post-Compo version

When the compo ended, the game had only JUST become truly playable, and I was entering a groove where adding features and juice was eminently satisfying. So why stop there? I branched my code and kept working on a post-compo version, albeit at a more-relaxed pace. I added scrolling grass, shaded the monster, cleaned up and animated the pikes, added a demolition rumble effect, smoothed monster movement, tweaked the RNG to be less cruel, and gave the monster an increasing deceleration for faster and more dramatic slow downs. It’s more playable. And I’m still adding things to it. It gives interested players a change to look at something closer to “what I was going for,” and rewards them with a better experience as appreciation for looking. And I get to put in those missing elements that make me happy. :)

“Writhe: The Thing from the Omega Sector” complete!

Posted by (twitter: @DragonXVI)
Sunday, August 23rd, 2015 4:54 pm

Why not Zoidberg?

Writhe is complete! Available download for Windows PC, Mac ‘n Linux!.  Go play it!

As usual I’ll do a writeup/post-mortem thing later on.  For now amma take a rest ‘n play a few games. Hopefully this one’s a little easier to complete (if all else fails I put in a ‘skip level’ button :p ).  Enjoyed making it, hope y’like playin’ it!

“Writhe” last stretch

Posted by (twitter: @DragonXVI)
Sunday, August 23rd, 2015 12:09 pm

Not sure why Gifcam melted during the recording of this and made everything green but whatevs TOO BUSY

Alright! Last stretch now, and it’s mostly polish now, audio’s in and the last of the annoying bugs’re squashed (maybe).  Sneaky peak above shows off a bit of the Final Boss and some other fun mechanics.  Still to go:

  • Level 6 (levels 1-5 are done, level 7 is the boss. Level 6 is mostly going to be a “Everything you’ve learned” level)
  • Custom mouse cursor for aiming the tentacle
  • Main menu / Title screen
  • Some kind of end screen
  • Level splash screens
  • Additional music
  • Submission prep

Gotta go fast!

“Writhe”: End of Day 1

Posted by (twitter: @DragonXVI)
Saturday, August 22nd, 2015 4:43 pm

Our old friend Mr. Rotating Laser Turret returns for revenge

 

Well, what started off as a bit of a physics battle is turning into a fairly simple but potentially funky little game.  Like my usual LD Compo entries, this is a fairly basic 2D affair with some kind of physics gimmick.  Your tentacles can be lashed out for striking things or grabbing dinner, and the objective is to eat every scientist in the level and reach the exit.

At the point now where I can start whipping levels together and get some ‘Gimmicks’ in in terms of obstacles.  Still to come are laser beams, missile turrets, explosive containers, breakable walls, force field zones…  Anything else anyone can think of? Might find time to bung it in 😀

I’d also like to get a Boss Level in to finish it off, so that’ll likely take up a chunk of tomorrow.

Last thing tonight is to pop open FL Studio and get started on the music! (I’ve been listening to a lot of Splatoon’s OST though so it might end up as kind “Alien Ska” at this rate…)  Hope everyone’s games’re comin’ along! 😀

 

Oh yeah I should probably make the scientists flee when you’re near… They seem a bit blind at the moment…

“Writhe” Initial progress

Posted by (twitter: @DragonXVI)
Saturday, August 22nd, 2015 7:07 am

Hey all! Another LD Compo entry.  The theme wasn’t my hopeful winning choice but after rattling through a few ideas I’ve hit a solid pace now.

You’ll be taking the part of a lovely writhing mass of tentacles attached to a big hungry alien that’s escaped from its habitat on a Xenobiology Research Station and is ready to wreak havok.  Avoid security systems, devour scientists and escape!

The original plan was to have it entirely one-button physics based with the only movement allowed a kind of ‘latching’ tentacle you used as a sort of grappling hook, but that got annoying pretty fast so instead of spending 2 days balancing playable physics, I’m goin’ with something a bit more simpler!

 

 

That’s a quote from the most excellent Muppet movie Muppets: Most Wanted, and it has nothing to do with this compo entry announcement. I just can get the songs out of my head.

Editor: Sublime Text
Language: Haxe 3
API/FrameworksFlaxen (HaxePunkAsh-HaxeOpenFL)
GitHub Version Control: Base Code and Game Source
Visuals: Photoshop, FilterForge, possible Pixen
Audio: Audacity, Bfxr, Renoise w/VST plugins
Animal: Bad frog! Bad frog!
Fräulein: Evilen froggen! Evilen froggen!

Thank you, Kermit, no more questions.

Time for plan B

Posted by
Sunday, April 19th, 2015 7:49 pm

As usual, I spend the first few hours of Ludum Dare coming up with several game ideas and evaluating them, choosing the one that has the best balance of interesting and completable. This time I made some major gaffs, picking ideas that were required major design work, replacing a good premise with goofy abstract puzzle mechanic that does the original inspiration no justice, failing to focus properly on a day one prototype, and getting distracted with third-party and not so third-party bugs. As such, although it’s almost time for submission, it’s still not actually playable. So, out of eight LDs, about I’m about to fail my third.

It kind of surprises me, falling into the same old traps, but that’s what it is. I had fun doing some pixel art, learning a bit from Derek’s great Make Games Tutorial.

specialist-red bookresearch-green

 

 

 

I’m mulling over the possibility of continuing to work tomorrow and entering whatever I get working into the Jam, but right now I’m tired. Good luck everyone!

Screen Shot 2015-04-19 at 8.29.44 PM

Jam This!

Posted by
Tuesday, April 7th, 2015 9:42 am

It’s that time again to make a public announcement that I’m ready to embarrass myself enter the compo!

Editor: Sublime Text
Language: Haxe 3
API/FrameworksFlaxen (HaxePunkAsh-Haxe, OpenFL)
GitHub Version Control: Base Code and Game Source
Visuals: Photoshop, FilterForge, possible Pixen
Audio: Audacity, Bfxr, Renoise w/VST plugins
Cheese: Cheese? Why are you bothering me about cheese at a time like this?!

Jam on, fellow ludophiles.

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.

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!

[cache: storing page]