About Me

I make stuff, because I go crazy if I don’t, and I do my best to make cool stuff, for the same reason.

Another Luxe Tip

I didn’t expect to write more of these, but here I am! I wanted to document a bit of interesting behavior I found in the process of building/rebuilding a shmup.

I had this cool effect for making a sprite kind of flicker and glow a bit by adding a duplicate and making it expand and contract rapidly. I think the old way in SpriteKit used a parent/child relationship with an SKAction for the animation. In luxe, the way I’m doing it is by attaching a component to the base sprite.

This component is fairly simple. I build a sprite, attach it to its parent via the parent property (so moving it by hand is unnecessary), then add a few animations. I’ve already learned that onremoved() is the right place to do teardown, so I destroy the sprite in there and all’s well, right? Not quite.

The extra wrinkle here is that I’ve got a timer that fires after a few seconds to remove the component. Simple and straightforward - entity.remove('flicker'); - until I tried to run it. There’s a couple of annoying subtle bugs in here that made me sad.

The first is the parent-child relationship built from the sprite. The lifecycle of a sprite is this, during destroy. First, destroy yourself, then loop through and destroy your children. This means I’m double-destroying my flicker sprite! Dangit. The solution? Don’t add it as a child, and manually update position in update().

The second is that timer. See, there’s a problem there, too: what happens if you kill the parent before the timer fires? Everything gets cleaned up properly, but then you try to call entity.remove('flicker') and - boom, again! Dangit. The fix here was to save my scheduled timer and tell it to stop in onremoved(). Both reasonably simple fixes, but real head-scratchers as I was working through the issues. This isn’t even a particularly complicated situation, but making simple mistakes really bit me in the ass.

Little Luxe Tips

I’m not dead! A shock, I know, but between real-life obligations and a decline in my general state of gives-a-crap, my fun little hobby life has suffered in recent months. Shucks.

Doesn’t mean I can’t bounce back, though, right? Spring 2015-ish, I was on the hunt for something new to tinker with, and I found this rad stuff.

First off, a dumb, semi-obvious one. For anyone loading textures in config, using something like config.preload.textures.push({ id:'assets/playershot.png' }); who want nearest neighbor filtering on all of their textures, it’s important to call phoenix.Texture.default_filter = phoenix.Texture.FilterType.nearest; before you load anything. Promise - this’ll make you sad and confused otherwise. Obvious in hindsight and a real forehead-slapper once I figured it out.

Another important thing to note is that someday (soon?) phoenix is going to go away, replaced with embers. The API might look similar, and this might still be relevant, but just something to keep in mind.

I bumped into another forehead-slapper obvious issue with global events and ids. It’s super easy to just Luxe.events.listen('whatever', function() { doRadStuff(); }) - but the gotcha here was not holding onto what listen() returns. Whoopsie. That’s the thing you use later to unlisten to things, ala Luxe.events.unlisten(event_id). The worst part? This is even in the docs! Bad me.

The last tip is going to be a bit of a rambler. Luxe supports the pretty useful entity-component model of design: you’ve got your base entity, and you can lump additional behavior onto it via components, which are small little focused nuggets of goodness. I’m coming from an objc/iOS background, which means that I spotted new, init and destroy and thought, aha! That’s clearly the place to put stuff!

D’oh. Nope. See, the thing you’re attaching your component to isn’t quite ready in new - that’s just for building stuff up. Init, too, is a little early - sure, you’ll be ready, but if you want to add stuff your component after the fact (adding components to an entity returns that built component - handy for twiddling stuff immediately afterwards) - well, onadded is a better place. Teardown is similar, as onremoved happens earlier in the destruction lifecycle than ondestroy.

Slow Jam 1: Technical Postmortem

Yesterday, I posted up some of my recent thoughts and experiences on the last PIGSquad game jam. It went pretty well, and I’m pretty happy with it! This is going to be the big, ugly breakdown of how I actually put the whole thing together.

And just to repeat myself, here’s the page for the game!

I’ve mentioned this before, but I’ve been doing a lot of work and research with luxe, a game engine built on top of Haxe. It’s all pretty new and different for me, coming primarily from a recent iOS background - but that’s for another post.

Luxe is in alpha, which means it isn’t quite finished yet. Luxe, more importantly, is completely badass. Damn and blast, I was going to talk about this another time.

I’m not going to cover what I brought up yesterday - we all know it’s a spaceship game. Instead, I’ll go into how I actually put this whole thing together, from start to finish, with a bit of a focus on Luxe. Like with C, Luxe starts you off in Main. It’s the entry point for the whole app (as far as I understand - apologies in advance, __discovery). For me, it’s also where I keep a few important, app-wide things, like where we’re at in a state machine, and the starfield background.

Background Starfield

Speaking of which, that background is something that turned out really well. I’m pretty proud of how I put it together, so let’s start there. In Pixelmator, I added noise, tweaked light and dark balance and fiddled with it until I got black with a sea of stars. From there, I duplicated that layer and ripped out anything black, leaving just stars. That layer, with just stars and no black background, was duplicated a couple more times. The trick here is that I went in with the eraser and just swept through it, leaving patches of stars here and there.

Now, the engine part of things. Each of those transparent layers gets to live as a texture on its own quad. Simple uv coordinate manipulation - adding a delta on each frame - makes the texture slide across the quad (or Sprite, if you prefer the luxe term). Each quad also gets its own delta speed, adding basic parallax. Finally, I provided a basic setter to Main, the class containing this whole thing, so that any state could change the speed that the game went at. Simple, straightforward, and pretty clean.

Physics

One of the physics simulations luxe supports is called Nape. Nape is pretty darned good, and more than sufficient for my purposes. Putting it to good use is left as an exercise for the reader, but my general scheme was to put together a couple of simple static boxes: one would keep the player ships from exiting the view, and the other served to clean up any bullets or asteroids that bumped into it. It was a pretty straightforward system.

Nape, in particular, is pretty cool because of the rich callbacks system. I can define certain physics bodies as one type, and others as another, then get a function called when the two bodies interact. It’s how all of my collision works: when two asteroids bump, I spawn a little explosion. When a bullet hits an asteroid, same thing. When an asteroid hits a player, explode a lot! Oh, and kill that poor helpless ship, too.

Input

Input was pretty straightforward, too. Luxe comes with an entity component system right out of the box, so I put this to good use. My InputComponent ended up being a bit of a God Object, which isn’t great - but, hey, game jam. It’s okay if things are a bit clunky or poorly designed, as long as it works. Input holds onto the particular ship’s physics body and attaches to the ship’s Sprite. Each frame, I update the sprite’s position and rotation based on its physics body. (This is how asteroids and bullets work, too.)

One trick that I apply here, I think picked up from @madgarden is to give the acceleration a boost when the player tries to move in the opposite direction of travel. So, if you’re heading right and going fast, then try to go left, give a bit more oomph to the physics impulse until your velocity normalizes. It makes everything a lot zippier and feels pretty great, once you’ve tuned whatever that extra-oomph is.

Data-Driven Nonsense

I think this came up in yesterday’s overall post, but going into the last day, I put together a basic json-based data file for ship stats. This was after I’d already gotten the whole game up and running. This was huge, because it meant I could see where the hardcoded numbers are, and set them up accordingly in the json. My InputComponent, after it’s been loaded, can ask Main about what ship it’s made and assign values out of the data file.

It was almost offensive how well this system worked, and it’s something I plan on re-using for other projects. The only failing: the lack of testing. If I had my druthers, I’d put together something that let me twiddle and toggle game settings on the fly, rather than having a lengthy rebuild/relaunch cycle. Being able to disable ship death and tweak ship settings in-game would have been huge. Maybe for the next jam! (But probably not, knowing me.)

Music

This is probably going to earn its own post at some point, but figuring out how to do loops and samples in Garage Band was pretty great. I stepped through a bunch of their supplied loops, dragged in the ones that sounded good, then set them to loop over a particular interval until I got something I liked. The one trick that I found handy was to separate an intro from a main game loop. This seemed like a good way of doing things, because in luxe there’s a completion handler for when a sound effect will end.

That’s most of the interesting chunks. Doing this project in luxe has really gotten me excited again about building stuff, and I’m looking forward to the next gamejam in August (July’s has a schedule conflict for me, sadly). I’m also looking forward to just having an easier, cross-platformier dev environment. After being iOS only for so long, being able to blast something out to a bunch of different places feels pretty great.

Summer Slow Jam 1 Postmortem

It’s been awhile! I missed each and every one of you. At least I haven’t been sitting on my thumbs during my long-ish silence. Promise!

Before we get too far, here’s the page for the game!

So, PIGSquad, a local group of gamedev enthusiasts, is pretty great. Recently, they started this neat Summer Slow Jams thingie - each month this summer is a different jam with a different theme (or set of themes). I like game jams, but most of the 48/72 hour ones are a bit too rushed for me. Family obligations make it difficult to really focus, too. A week, on the other hand. . .

A week is a pretty healthy amount of time. The general theme was “something you can showcase” and the game-specific themes were: seed, spirits, in the fast lane, explosions(!), brewfest, guilty pleasures, wild west, and man vs machine. Most of these didn’t really say much to me, and the overall prompt of a showcase-worthy game was a bigger barrier than the game themes, honestly.

(One interesting thing about the themes - at least two of them are total gimmes. Guilty Pleasures and Explosions pretty much let you build whatever the hell you want - what game couldn’t use more explosions? It was a neat trick to make it easier for everyone to contribute and come up with something.)

First off, before you can really start on anything, you have to, uh, think about what the hell you’re doing, right? For jams, I usually just sit and stare at the theme for awhile and waited for stuff to fall out. Seed, spirits, brewfest, and guilty pleasures didn’t yield much immediately. I had a neat hook for man vs machine that was basically a cyborg metroidvania with some of the corruption mechanics from Breath of Fire: Dragon Quarter - you had rad robo-abilities, but using them made you more inhuman. I stopped myself at ‘metroidvania’ and filed that away for later.

Which left only a few more options. I had a hook for wild west: basically, a timing/reaction game with two players, where one had to move an analog stick in a certain way to draw a pistol, aim, and fire, but it felt too fiddly and didn’t strike me as particulary “showcaseable”. Yes, that’s a word, as of now.

In The Fast Lane was the first thing I ended up building a prototype for. I had the idea of doing a Grandma Simulator, where you’re an old lady sitting in the fast lane, oblivious to the traffic crashing behind you. It seemed a little cruel and mean, and again, not all that showcaseable. (My standards on what’s worth showcasing might, upon reflection, be a little bit high.) I kept thinking about it and ended up doing a kind of Road Rage simulator, instead. I wired up simple boxes with basic movement to fake up what actual freeway traffic was like. It worked, but it didn’t strike me as particularly zazzy, so I shelved it.

Time from first code written to discard: maybe a day or so? On a 48h jam, I probably would’ve just had to stick out the crappy prototype, but I knew I had a bit more time to let things noodle and build. Probably a good thing, too, given how fiddly the cars felt. Tuning physics for game feel is tricky, and adding decent AI drivers felt like a big challenge.

It was Tuesday before I settled on a different idea, going with something else I thought of on the first night of the jam, using the theme of Explosions instead. I had pretty decent shmup sprites, and a fairly good grasp of what makes those fun to play, so I settled on a cooperative Asteroid Field Navigation game, with a dash of Star Wars in-joke to boot. 3720 : 1 (3720 to 1) was born-ish!

It didn’t hurt that I’d, more or less, done this already before. A shmup that I’ve been writing since the Kennedy Administration had a neat asteroid field mechanic, where occasionally these white ping-pong balls of death and sadness would rain down on you and the aliens. Dodging them was fun and shooting them was fun - why not make a whole game around that one mechanic? It seemed like it’d work. Scaling back weapon effectiveness and making it a team effort could help keep the game interesting and challenging.

Which meant that I had to get to work, and work I did! Though, looking back, not nearly as much as I should have. The fun umbrella of personal issues kept me from being as productive as I ought to have been, leading to some last-minute issues. Things got done, but not up to my usually high standards. This being a jam is no reason for clumsiness or cludginess.

My choice of tools were probably the thing that really saved me. I used Pixatronic to generate my spaceship sprites and the asteroids, Pixelmator for the rad parallax starfield (probably my favorite part of the whole shebang), bfxr for sound effects, Garage Band for the music and, last but absolutely not least, luxe for the engine.

Garage Band is a little cheesy, but the track for that turned out pretty well, too. Figuring out how to put together simple loops was fun, and completely worth the half-hour invested. This is a tool I’ll absolutely use again the next time around. Moving forward, I’d like to add a few more loops to alternate between, rather than just an intro and a single loop. Variation is good, and making different loops is as simple as toggling channels on and off.

Luxe let me put together everything with remarkable speed and not a whole heck of a lot of code. How much code, you ask? This much!

-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
haXe                             7            242             74           1003
JSON                             1              0              0             98
-------------------------------------------------------------------------------
SUM:                             8            242             74           1101
-------------------------------------------------------------------------------

Note that little chunk of JSON! Another thing I’m pretty happy with is having a set of ships, loaded from a file! It’s odd where the low bars and the high bars are, huh? It’s something I wanted to do on bullet heck for ages, and just couldn’t handle, or couldn’t get around to it. C’est la vie.

Before I get too much further, remember the theme I’d chosen: Explosions! I had, uh, one. It wasn’t a bad one - a simple circle that appears and shrinks, with a bunch of squarish particles flying everywhere. Probably not the worst explosion in the world, but it could have done with a lot more polish and tweaking. This is an area I’d definitely like to give more attention going forward, particularly when it comes to ships exploding. They should knock asteroids around when they go kaboom! At least I’ve got screen shake.

Going into the big jam demo night, I had a main menu screen, a ship selector screen (for up to 4 players) and a game screen. Each worked - mostly. The ship selector had a few bugs, and there were a few little issues with the game, too. I’m proud that I was able to get them fixed mid-jam-demo, but less proud that I let them slip at all. One of the things I’ve been reluctant to do, with jams, is commit to working in a team. I’ve always been concerned that I won’t be able to work fast enough, or won’t be able to contribute enough.

Next time, however, my plan is to take on a team of friends and have them be extra sets of eyeballs. This experience is some proof that I can push something decent enough out without completely driving myself mad. Everything I caught in the last few hours could’ve been spotted earlier - with another set of eyes, or more people. Given the next jam topic is going to be multiplayer games, all the more reason to get more people involved. The fact that I’ve already written a multiplayer game for a jam (partially unintentionally) only helps my case.

What’s more, on the final demo night, I’ll be able to have other people around to talk and show off the work. I absolutely suck at self-promotion and talking about my work, so this is going to be a huge boon to me. I dreaded showing it to people, and really hope the next time around goes even better than this time.

The mechanics of scoring could have used a bit of help and explanation. Basically, you earn points (parsecs) based on how far forward the furthest ship is. The gameplay idea was to have someone in a quick ship towards the more dangerous part of the asteroid field, where fast reflexes were most necessary, and have the other players hang back and try to shoot asteroids out of their path. There isn’t much of a visual explanation of this effect - probably something added to the score bar would help in that regard.

Knowing which ships to pick is also a bit of a challenge. The star explanations for ship capabilities are. . .well, that was one of the last things I did, on the day of the jam. I was throwing numbers into JSON and hoping nothing broke. More work on ship balance is going to be necessary to call this actually finished and done.

At the end of the day, I’m pretty darn happy with how this project turned out - happy enough to actually post it for people to fiddle with. I learned a lot about working with luxe, making music, not leaving things until the last minute (cough, cough) and just putting together a general framework for more of these types of games. The general blocks and chunks are going to be really straightforward to pull out for the next multiplayer work.

If you’d like to try it, head to my itch page to give 3720:1 a try. It’s still a little clumsy in a lot of ways, but I’m still happy with how it turned out. Feedback is always welcome, and the best place to hit me is probably my twitter.

What’s a Game?

Some people like to carefully proofread what they write and post on the Great Wide Internet™. It’s a good philosophy! It leads to quality content (for your braaaand) and, in general, it’s how things ought to be done.

This is not gonna be one of those things. Strap yourselves in, folks, I’m going completely free association, here.

Backing up a step, I’ve been playing around with luxe for the last few weeks, hence the silence. Ludum Dare went Very Poorly, but unfortunately I don’t know the Latin for that. ‘Vilissimo’, sayeth the googles. The sad part is that it’s all stupid emotional nonsense, but that’s not what I’m here to fumble with.

I’ve been building a silly little couch party game for the last few nights - since Friday, come to think of it. Or maybe last Thursday (4/23/2015). The first night, I got a whole level loaded from Tiled! I’ve never done that before, so it was kinda neat to see such quick turnaround. Slowly but surely, I’m learning. Second and third night, all physics, then input. Now I’ve got these neat little marbles that roll around the screen, more or less how I imagined my prototype, way back when. Triggers are hooked up, so I know when things bounce into bad things, and…

Wait. Shoot. I’m forgetting something. The whole, uh, game part of gamedev. This is just fiddling and playing around - valuable, for sure, and certainly when trying to pick up something new and slippery, but I can’t really play this. Games generally have goals, some have scores. Even games with emergent fun, whatever the hell that is, tends to have some kind of structure in place. So far, this is just a toy. Which loops back to why I’m here!

What’s a game, in the kind of base, boiled-down sense? Is it just a set of rules, simple or complex? Pong’s a game, right? At its core, Pong is a game that ends when someone’s lives hit zero. Aha! That means, in my game, I need to keep track of each player, decrement some counter when a particular event happens, and call the game ‘over’ when there’s only one person left standing. Right?

Well, sure. But what if it was a little different? What if there was a flag, and each marble had to steal/knock it away from the other marbles to take it back to their little cubby? How do you structure that? I guess that’s where I’m at. Luxe (bless it) has this pretty common, rad, new-to-me Entity-Component system. I’ve got a Sprite, and I attach Input to it, and bam, it moves. I attach Physics, and shazam, it affects its world, while the world around it affects it. (I’ve combined the two for convenience, but you get the point).

Which, after a whole lot of hot air and sore fingers on my part, leads to the conclusion: are Game Modes for this Dumb Marble Game just components that I can bolt onto…what? Having them attached to the sprites themselves seems a little too low-level, truth be told. What if the game object, the thing that holds the world, and the sprites, and receives the callbacks for collision, is the one I lump this thing onto?

Well, now we’re getting somewhere, aren’t we?

Weekly Update: 4-5-2015

This week was pretty slow. Most of it was spent fiddling and playing around with luxe and trying different things out. It’s going pretty well, and - hilariously enough - my first sample projects are rebuilding old stuff. I’m starting with bullet heck.

Not really pictured, here, are a few of the things I’m still wrapping my head around. Input works pretty well with just the keyboard, but it might take a bit of effort to get playing nicely on mobile. The mothership-esque thing also rotates to face the player, which is neat.

The good news with all of this fiddling is that I think I’ll be ready in two weeks (yikes) for the next Ludum Dare. I’m getting pretty excited!

The other thing I did was play with a few more generators for wallomatic and try to re-integrate the blurring stuff. I found some information about how to do a good blur, so I can at least tell if I’m getting the ‘right’ answer. Still not sure it’ll ship with blur, but at least I’ve got one problem knocked out. Basically, computer blur is dumb, and you’ll end up with black bands, rather than the averaged color. Obviously, this is bad if you want something to look good.

Weekly Update: 3-29-2015

This week I did…stuff? Ostensibly? Mostly just playing around with the pattern wallpaper thing. So far it really doesn’t work very well at all, which is a bit disappointing. The dials and knobs are too fiddly, and I’m not getting results I like, so it’s not looking good for this stupid thing.

Same deal with blur on wallomatic, actually. It’s…good, occasionally? And other times it’s just kind of a blurry mess (obviously) that hurts my eyes. I wanted something, oddly enough, with a lot of banding, but it isn’t really working out very well. Will try twiddling a bit more before giving that feature a swift kick in the teeth.

Which is kind of a funny side-issue on its own. It works pretty well on a few of them, all the time, but a lot of them it just really doesn’t jive. Is it better to not have it at all if it mostly sucks? That’s what I’d think, but what do I know?

Work continues, slowly but surely, on Bullet Heck. I’m doing some of the Game Center nonsense right now, filling out leaderboards and achievements, because every game needs ‘cheevos! I think a lot of the features are pretty much done, until they’re, uh, not. Welcome to gamedev!

Lastly, I’m still playing around with luxe engine/snowkit/whatever the hell. Still neat, and trying to wrap my head around components and entities and how to get everything to be aware of each other and play nice. The list of “things I need to make a game” is probably shorter than I think, and it’s really only the hard things that I need to get worked out.

Weekly Update: 3-22-2015

This was a bit of a slow week. I’m still learning about haxe, snowkit, luxe, the works, so there’s not much to show for my efforts (so far). It’s a bit odd, jumping into a completely alien thing, but I’ll get competent sooner or later. Hopefully sooner - Ludum Dare’s right around the corner.

I also did a bit of fiddling with the wallpaper generators, and finally got around to starting an idea I’ve been kicking around. Wallomatic’s kinda cool because it’s simple and geometric and reasonably non-offensive, but there’s no real art or style to it. It occurred to me that using some simple textures and patterns, tinted, could be kind of a cool project, too, so I’m putting together something that’ll basically do that.

I’m happy enough with the wallomatic UI to pretty much bring the whole thing over. I’m tempted to redo the save button and maybe have some different options. A share thing might be neat - you get to save a wallpaper without the annoying dialog if you also share it to facebook or twitter or something.

Short week, busy week! Yikes. Tired of having colds all the time.

Weekly Update: 3-15-2015

This week was spent partially hating on SpriteKit and partially loving Fastlane. The latter is awesome. The former makes me sad. Bullet Heck was built in SpriteKit, and it’ll probably be my last project built with it, too. Moving on.

Research into snowkit and haxe continues. I’m really liking it, and plan on having some kind of prototype-y thing built before too long. I don’t want to use it for the next Ludum Dare (at least, not before I’ve got a bit more experience using it) but it might be fun to see what I can cobble together.

Spent a bit of time working with those fastlane tools, though, building up screenshot scripts and getting things in line for inevitable, neglected app updates. Pixatronic ought to get some better stuff at some point, and Panic Attack needs to get iPhone 6/6+ support someday.

Er. Suppose The Dungeon deserves all that, too, right? Yikes.

Weekly Update: 3-8-2015

This week was another brisk one. I spent a bit of time hammering at the asteroids in Bullet Heck to make them a bit more sensible and a bit more game-y. Just having a constant, endless wave of asteroids is a bit exhausting so I’m setting them up to do occasional bursts based on the asteroid density of that particular wave.

I also did a bit of work on Wallomatic this week, adding a neat blur filter toggle. I’m always leery about adding twiddlers and settings, but this one feels like a keeper. It was all pretty much inspired by how OS X blurs your wallpaper at the login prompt, so I have Apple to thank! Yay.

I’m still kinda thumping away at learning luxeengine/snowkit and that whole constellation of rad stuff. There’s an Art/Code night this Thursday that I’m hoping to have something playable and pokable, but we’ll see how it goes. There’s not that much stuff to build, but I’ve got kind of a busy week ahead of me.

Pilot Pen Nib Swaperoo

Ages ago, I had a post about pens! (Hah. Post. Pens. Moving on.) I had two surprises from that, revolving around the Pilot pens - specifically, the Metropolitan and the Penmanship. One’s a fairly classic black, with pretty great weight to it, and the other is this odd clear plastic thing with grip-ridges and an odd cap.

They’re both pretty good pens, and especially at their prices, but I was always disappointed with how thick the Fine nib was in the Metropolitan. I like to put down a really, really thin line because my writing is cramped and my handwriting isn’t all that neat. Thin means I get to be a bit sloppy, so between the two pens, the Penmanship really won out.

That was pretty much the end of it until a week or two ago, when I started looking into nibs. Why couldn’t I put an EF into the Metro? Turns out, there was nothing but fear stopping me - and another Penmanship. I didn’t even bother searching, though knew that you could yank it out of a Penmanship and do a swap that way. Which, actually, is exactly what I did.

Here’s the shoot-the-Cacodemon-until-it-dies tip: wrap the nib and feed (the black thing with ridges) in tape to yank it out. I used packing tape, because the nib only extends about halfway down. Yep, just wrap that thing and give ‘er a tug. Be careful and gentle when unwrapping, repeat, then discover that the nibs just kinda fit into place. Sliding it back on was pretty straightforward too, and just took a little bit of force.

This is filed under “lol who cares” to just about everyone, but damn, I’m happy with this pen now. Dang, I never did end up doing that post about ink, did I? Spoiler alert: I put Montblanc Blue/Black ink in there. Puts down this really nice darkish-gray line. It was my go-to black before I got this other ink, but that’s for another post!

Weekly Update: 3-1-2015

This week, I did a bit more work on both Bullet Heck and my luxe evaluation. I was a little bummed out by the wiimote not being a good controller for luxe’s gamepad support, but I’ve got some spare 360 controllers that seem to do great. When I carve out the time I’m going to try to do a kind of physics-based arena Marble Madness kind of…thing. It’s still pretty nebulous but I think I’ve got enough of a hook that I should be able to fake something up.

There was a game demo event thing on Monday that went pretty well. Got a lot of stuff done on Bullet Heck just before, mostly adding text and story snippets. I also managed to fix a long-standing annoyance with the way controls worked. They’ve been kinda stupid and broken for awhile so it feels really good to get them in a confident state.

That was pretty much this week. Someday I’ll be done, though I’m a bit terrified to write out the full and complete ship-task-list. Those are usually pretty disheartening experiences. Don’t forget - when your game’s mechanics are done, you’re nowhere near done!

Weekly Update: 2-22-2015

This week went by in a flash, and not a whole lot got done! Er. Crap. That’s, uh, precisely the opposite of what I should be saying, huh?

It’s true, though! I was sick through most of the week, and Bullet Heck is starting to wind down in terms of features. There are still a few bugs left to squash, and some rough edges to polish, and - oh. Game Center, Leaderboards, score reporting, blech. Monetization, too, I guess. This is one of the problems with making stuff - even when you’re done, you’re not really done-done.

I guess the thing I poked at more this week was evaluating new environments. I’ve been looking a ton at luxe and snõwkit because of Jonathan Hirz, a cool dude I know on Twitter. (That had too many links. I’ll stop now, I swear.) It’s cross-platform, which is something I’ve wanted to be able to support for awhile. Looks like pushing out builds for gamejams and stuff is way more doable with this, too. It’s early days, but people seem happy with it.

The tricky part now is figuring out which silly prototype idea ought to be dusted off to get built in this thing.

I still really want to make a more general, non-generative version of Pixatronic at some point but I’m not really a pixel artist, so I don’t know if I’m the best to judge whether it’s useful or not. I have a few ideas on how to make it not suck, but I’ve had a lot of apathy towards that whole dumb thing - which is sad! I’m actually still pretty proud of how the canvas was all put together, code-wise. (Maybe that’s all rose-colored glasses, or something.)

I need clones or interns or something. Sheesh.

Weekly Update: 2-15-2015

This week started out strong with a fairly productive Art/Code night hosted by a local gamedev meetup group. I twiddled a bit on a traditional pixel editor for iOS, a procedural hero generator thingie, and finished it off with more tweaks and work on Bullet Heck.

Bullet Heck might be mechanics-complete at this point. The asteroid stages turned out pretty fun, and they add a lot of chaos that isn’t necessarily detrimental to the player. Still to be done is tweaking parameters with all of that stuff, which is what I’m planning on doing for the next week or so. Still doing general polish/bugfixes/rough-edge-sanding, which happens, uh, forever. Just ask anyone.

Taking a first stab at a silly little bit of story/flavor text at game-start, too. Should be sorta mad-libs-y with a bit of humor.

I probably need to spend a bit of time redoing sounds, too. They’re kind of a mess, and just kinda not good. Jumbled, unclear, nondistinct.

Oh, I twiddled a bit on a new wallpaper idea, too, something plaid-ish or Tartan-esque. Not quite done yet, but it looks kinda neat. Not eye-searing, at least.

Periodic Update: 2-8-2015

This week I started digging into Unity’s massive tutorial-o-rama. Cripes, you people loves you some videos, huh? Not a single text/picture intro tutorial in sight.

Most of the effort’s been focused on getting Bullet Heck done and fun. I added a new, silly gameplay mechanic this week that’s already cracking me up. Asteroids can fly in and ruin people’s day now, including the aliens. Should be pretty fun.

Informal playtest feedback has been pretty helpful, too. I’m liking Apple’s new TestFlight stuff. Seems like I don’t have to hound or hassle testers to get feedback these days, which is a pleasant surprise.

Lastly, I started noodling and writing down ideas for the Next Big Scary Thing. I don’t know what I want to build it in, and I don’t really know how I’m gonna do it, but I’m hoping to get that more nailed down in the coming weeks. We’ll see how it goes. It’s sort of procedural-ish and roguelike-y without being explicitly part of either faction.

Short update, I know - I’m still fighting stupid colds and have been majorly low on energy. Tis the season, I guess.