Queue the sad music!
I’m now blogging over on Tumblr. Yep, that’s me, jumping on new trends 5 years late like an old man.
Reasons why detailed over there, and this domain will one day – eventually – redirect over there too.
(also aliased as Captain-Andy.com)
Peace out, yo.
A blog post (by Jeff Vogel) has been making the rounds recently, talking about how the indie-bubble has burst and now you need a heaping teaspoon of luck to get anywhere in the industry.
The “bubble-bursting” statement will be addressed in my next blog post, but first, I really don’t like the way Jeff uses “luck” as a concept.
I made a post a while back about luck, and my general thoughts about it, so you can take a gander back there if you like.
Jeff uses this statement to demonstrate how luck is key in making your game succeed:
Yes, Luck: Getting a good break. Meeting the right editor who will champion you or making the right publisher connection.
No. No no no! This isn’t luck. Luck would be sitting in your basement moping about your game, and having a publisher or editor reach out to you because your game is just so awesome. It’s slightly less lucky if you go to PAX and someone recognizes you and it turns out they were the business deal you were waiting for all along. It’s even less lucky if you happen to be sitting next to that perfect publisher during a presentation of “Finding a Publisher,” the GDC talk.
But setting up meetings, looking for a publisher, trying to make the right connections? That is so far removed from that view of “luck” that you can pretty much drop the term. If you keep looking, ask around, use your resources, it is almost guaranteed for you to succeed. In fact, you’d have to be lucky to not make those connections.
It’s like saying that you have to be lucky to buy a bottle of Coke from a convenience store. Because, you know, you might get hit by an asteroid before walking through their parking lot. It’s possible, it’s luck, but in the context of odds, effort put forth, and the expected results of that effort, it becomes ludicrous to even bring up.
Jeff goes on to say:
Worthy titles sometimes fall by the wayside now. There is no inherent universal justice that decides that the “best” games succeed[...].
This bit is totally true. You can have a completely relevant, awesome, amazing, worthy game that gets totally un-noticed because you made no effort to make it noticed. That doesn’t mean luck had anything to do with it falling to the wayside!
I’m not saying that luck doesn’t exist, though. I’m just saying Jeff’s use of the word “luck” seems to be implying that you can use the L-word as a an excuse for failure. Which brings me to my next point:
The way to succeed in video games is to keep trying until you get your “lucky break” (which you will, that’s not a question), and then having the ability to recognize the opportunity, the courage to grasp at it, and the strength to hold on to it. You do this by practicing. You don’t start your journey of “finding your luck” by making your first-ever-game, taking it to PAX, and bumbling through a press interview. You hone your skills with each game, with each interview, with each conference, with each trade show.
According to psychologist Richard Wiseman, luck – bad or good – is just what you call the results of a human beings consciously interacting with chance, and some people are better at interacting with chance than others. [emphasis mine] – YANSS
YOU CAN BE BAD AT BEING LUCKY. But you can still learn to get better. One of the easiest first-steps is to take part in an indie-community (forums, chatrooms, meetup groups, shadowy cabals, etc.) and just asking for help. That’s hard to do.
Luck favours the prepared mind. - Louis Pasteur
When Jeff talks about luck, he basically says “WELP IF YOU DON’T GET LUCK YOU MIGHT AS WELL GIVE UP AND GO HOME YOU LOSE THIS ROUND.” In my view of luck, everyone will have the opportunity to make their great game a hit – you just have to keep at it.
But that’s something we keep forgetting: You have to start with a great idea. Keep that in mind; if all else is failing, it’s probably that it was a bad idea to start with.
Howard Aiken famously said:
Don’t worry about people stealing an idea. If it’s original, you will have to ram it down their throats.
How hard are you ramming your idea? How many throats do you have lined up? Is your idea honestly, objectively good? How do you know that? Who did you ask? How many truly hard questions have you asked yourself?
Yes, a perfectly executed plan can still fail. That perfect game might just fall by the wayside for some unknown reason. The stars might align in just the right way to spell out a new constellation that reads “don’t buy this game.” But those aren’t the reasons for failure — the reason is that you gave up too early. Sure, it might be because you ran out of money, or time, or patience, or just don’t have the emotional stamina to keep on going. Maybe the cost of continuing outstrips your potential returns. But that’s isn’t luck, so don’t chalk your failures up to it — that prevents you from learning a valuable lesson that’ll help you succeed in the future.
It’s okay to fail. It’s expected to fail. You should fail often. What you learn from that failure is what’ll help you not fail next time.
I know that saying “oh it failed because I was unlucky” makes you feel good, and admitting failure may result in many nights of crying yourself to sleep. I know it did for me. But what’ll make you feel even better is having a success the next time time you try.
Make your own luck. Recognize it. Practice grabbing a hold of it. And if you have a good idea, keep trying until you do hit the big time.
Good luck. ;)
I put together this little teaser video back in September showing off/announcing what Depth Charge was going to be:
Alas, we did not make it to MineCon. Next time!
Development Whiteboard
I was intentionally light on the details and didn’t show off a whole bunch because the game was pretty heavily under development back then… The video actually showcased the original Flash prototype, and not the current version of the game. Radial Games‘ new intern Rafa has been cranking away at it since then, and the game has really come along quite nicely.
The game is now working in Unity and exporting to iPads, we’ve got a dozen ship types, solid goals for missions, and we’ve even laid out all the niceties — tutorials, menu structure, all that stuff. We’re aiming to ship before Christmas, and I think we can manage it!
We still have quite a few big questions to answer – we aren’t yet sure how to monetize the game, and I’m not sure that the mobile marketplace will guarantee us any revenue. I’ve got a few tricks up my sleeve though… We’ll see if I can pull them off before launch!
We use a tool called Pivotal Tracker to help us organize our tasks and plan out when our launch date might hit. I’ve decided to make this tool public — anyone can pop by and see what our progress is looking like.
Because this project is largely in Rafa’s hands now (and not my own personal thing), we’re mostly talking about it on the Radial Games Twitter Feed and Facebook Page. Check us out there!
Monster Loves You! officially launched on iOS and Android! It’s been a long time coming, but finally here. Check out the new website for the game, too!
A week or two back I posted about a bad experience I had with the Haxe community. Judging from the reaction I got to that post on Facebook, Google Plus, and even just comments on that article, I think some clarification is in order.
First order of business: I was being unfair to a very helpful group. I was angry at the time (as much as one can be at a minor code problem), and I went through the whole thing with a big chip on my shoulder.
Of course, a blog post is forever, and now my anger is a permanent fixture on the internet – a rusty iron statue forever casting a furrowed brow out upon the community. Meanwhile, in real life, I was over it within the hour and have been a grinning and happy person ever since.
The #Haxe IRC channel (on Freenode) has been pretty much indispensable to me (I wouldn’t be able to get ANYTHING done without them), and often times when I ask about a bug in #OpenFL it gets fixed over lunch which is pretty much the best customer service ever. My worst experience as a community member was someone explaining the issue to me, immediately, and giving me a work-around that would take a minor amount of effort on my part.
Of course, my reaction to that was “WHAT?! I HAVE TO DO MORE WORK?!?!” and immediately flipped the table over. I mean, as an entitled middle class white male, how dare someone put an extra bit of work on my plate?!. In short, I was a total dick!
I still stand by what I said as a valid “heat of the moment” kind of response, though I probably shouldn’t have immortalized it with a blog post. If I were to do it over again, I would make a (calmer) broad statement about the stereotype of the “linux hacker” where a perfectly engineered solution is better than a human-readable one; the whole “RTFM” culture that pervades all technical communities. I did bump into that here, but it’s to be expected these days I guess.
And just how I rail against the “RTFM”-culture and dismissive behaviour in communities, I am also contributing in my own special way by bitching and moaning about it here in my blog, thus contributing to the negative stereotypes. Sorry about that.
#Haxe and #OpenFL are the most friendly, most responsive, most helpful technical community I’ve ever been a part of. I’m trying to contribute back to the community, and once I elevate above newb status perhaps I can contribute something a bit more than this Vimeo tutorial did over the weekend.
Sure, the IRC channel can behave in ways that are slightly negative at times; I think we’d all behave differently if we were sharing a table at the pub. I think we can all strive to do better. But right now, I’d rather hang out in #Haxe than on reddit or (*disgusted face*) youtube comments.
Three months ago I mentioned that — one day — I would attempt the switch to a mac.
I’m finally giving it a go. I walked down (in person!) to the temple of my hatred, the vile and consumerism-centric Apple store (that largely pisses me off because of its success…) and consumed. I soaked it all in, I made snap purchasing decisions based on sexiness, and walked out grinning like a kid that just bought his way into the cool club.
I mean, that’s what Windows-using-Andy would say, if he were looking down on the situation. But no! Me, OSX-using-Andy is approaching this with nothing but smiles and a good attitude. I picked up a brand new 13″ MacBook Pro (Retina), the ones freshly announced just this week. I spiced it up a bit with some extra RAM. I’m doing this full-immersion style, and refusing to use my PC as much as possible – I really want to figure this out! I even have a trusty helper sitting nearby to help me through the tougher spots (♥Dr. Kim♥).
I think it took me the last three months to build up the smile-levels necessary to pull this off. The road has been a little rocky so far, but I’ve been jumping through a bunch of hoops and it seems way less painful than I thought it would be. I’ve even managed to customize my Terminal window to have cool colours:
So I’m pretty happy, so far. I haven’t gotten to the point where I can actually work yet, but I can use social medias all day! And by golly, I’m tweeting!
Some little hurdles I had to deal with in the last 24 hours:
All in all, not so bad. Got all my other apps installed, dropbox all synced up… I mean, the little problem of me not being able to work is pretty big, but I’m confident I’ll solve it soonish (I’m currently playing around with SublimeText plugins… weird voodoo stuff!)
I’m really putting the laptop to the test this weekend though: A 48 hour hackathon over at UBC. Starts in just a few hours! Go go go!
There are plenty of libraries and frameworks out there to help you make your next big game, but many of them don’t work for me. They lack a critical feature, or they are bloated and contain too many unused features, or they require the instantiation of a meta “game” object that then gives you access to the juicy bits. I don’t want these things! I just want that feature I need, and I want it in a cheap/simple package!
The closest I found to what I needed was FlashPunk, but it didn’t quite fit my workflow. So I started writing my own library – just a folder full of helper utilities that I use in just about every single game I’ve ever made – from prototypes to jam games to full on commercial products. In this folder I dumped code borrowed from other developers and other software projects, and the occasional optimized function from a random StackOverflow thread.
Over the years this folder expanded and contracted like an accordion, trying to find that perfect balance between generic usability without being so specific as to tie into a particular project. I ported this folder of utilities to four different languages, the most recent of which is Haxe.
I’ve been developing in Haxe and OpenFL for over a year now, and I think sharing this folder of utilities might be a way to share my experience with other Haxe developers that are just starting out… So here it is. A library you can actually use IRL (It’s called “IRL” because I’m clever and it’s a totally good name for reals).
It’s nothing spectacular, there’s no amazing super long functions hyper optimized for blitting on 4D devices in here. But have you ever wanted a really simple GreyBox to help you prototype? Done. Or how about a simple-to-use save-game class? Or a wrapper for google analytics? I’ve got you covered. I’ve even got a handy little function in there that just makes buttons “bubble up” when you put your mouse over them.
I’ve also got a few dozen other utilities I’m going to pop in there over the coming months, but they’ll take quite a bit more work to become public. Things like my Adobe AIR integrator for SteamWorks; that’ll be fun.
Of course, I’m a self-trained programmer without a good head on my shoulders when it comes to design patterns or advanced features like macros. I usually lean towards solutions that just get things done rather than doing it right, but I’m hoping that – via forks or pull requests – we can work together as a community to make Haxe and OpenFL a bit more fun to code games in, and give us a little bit less to worry about. Maybe I’ll even learn a thing or two from you guys and end up a better programmer because of this.
Cheers!
I recently started writing Word Wings in Haxe and bumped into a little “gotcha” that I wanted to report on, in case others bump into the same thing.
Haxe defaults Float values to NaN in Flash targets, but defaults to 0 in native targets.
I’ve been developing in Haxe for over a year now, and felt like I had a pretty good handle on it. Monster Loves you was written entirely in it, largely headache-free, but I did stick with the Flash target for that particular game — and using NME (now OpenFL) prepped me to expect NaN in many cases. Large reams of my code look for NaN as a signal to initialize (or re-initialize things).
Imagine my surprise, then, when I compiled to a native target for the first time and started seeing weird errors cropping up. My tweens don’t execute properly. My screenshake algorithm instantly terminates. Nothing that crashes my game; just little behavioural differences that come out of Floats being initialized as 0 as a default. Because there was no error message, it took me quite a while to track this down.
“No problem,” I thought. “I’ll just declare all these variables as NaN! Problem solved!”
var myFloat:Float = Math.NaN;
“HAHAHAHA,” says Haxe. “NICE TRY!!! You can’t initialize Floats as NaN up there in the declaration, like you would a number value! You have to start writing your own initialization functions!! HAhahaha you’re such a chump!”
Fuck you, haxe! Fuck you!
To be fair, this behaviour is documented, and is one of the few examples of Haxe actually documenting something well (here’s a counterpoint). Of course, knowing this behaviour would take place requires that you read the documentation otherwise you’d not be able to figure it out. It’s not like I saw my tweens not firing and thought “oh man I should google Haxe’s float initialization documentation,” and I definitely don’t sit down and read an entire API before I start coding. Even if I did read the documentation, I probably would have skimmed the section on “what is a Float” and “what is an Int” as I think I know everything. (It turns out I do not.)
Of course, when I was trying to figure out a solution to this problem in the #haxe IRC channel I was told I was simply “doing it wrong” and that it was all my fault for not RTFM. Gotta love the super friendly support network Haxe has. (I was asking about ways to override Float’s default value, and instead of saying if it was possible or not, they wanted to know why I would do such a thing. Then I was chastised for not already having my own initialization functions.)
Still, it’s frustrating that a language that touts itself as “write once, deploy everywhere” would do this. It feels more like “write once, but only correctly and in this special way, deploy everywhere.” I understand the reasons they describe in the documentation for this behaviour, and sure I can agree with it too. It might in fact be the best way to do things. But it is still a gotcha, it’s still buried in the documentation, and it’s not expected behaviour for a noob like me; it leads to a bad user experience, and should probably change from a human point of view.
From an engineering point of view, where everyone is an expert and reads the manual, and initializes all their variables every time? Perfect.
(I still am in love with Haxe, despite the flaws. I just want to make sure I document this for future explorers.)
EDIT: And it turns out Neko targets initialize floats to null and not NaN, hooray! Three different targets!
EDIT2: I probably laid some unfair bashing on the #Haxe community in this article, and this edit just got way too long so I turned it into it’s own post.
My last post was heartfelt, but I think it ended a bit too dramatically. I stuck a bit of italicized foreshadowing at the bottom of it to help soften the impact — it wasn’t a joke! There really is a “Long Live IceBurgers” post! :D
I feel like it’s time I got back to my roots here at Radial Games. I love me some airplanes, and I haven’t been leveraging that nearly enough. The last aircraft game I launched was SteamBirds: Survival, years ago. I have some old favourite mechanics in IceBurgers that could use a new home. Where can I go from here?
Yep, I’m now announcing Word Wings! From the ashes of IceBurgers rises a new project, one I am very excited and passionate about. This is really a different kind of project for me. Let’s pull out my trusty old bullet-pointed-list to enumerate the ways:
You may have seen a theme in the above list – happiness. I’m joking around in the office with the game all day long, and really really enjoying it so far. I want to keep this project a joyous product of love and care, and a deep desire to just nail the game design aspects. I want to theme this game around my passions and really delivery a top-quality experience — from the ground up, rewritten from scratch.
I’ve already made quite a bit of progress (dynamic game area sizing for different devices and orientations, plus a playable game mode!), but more on that in coming updates!
Life is good!
IceBurgers has a strange history with me.
The idea for the game was swirling in my head for years, I’m sure, but really crystallized at the amazing IndieCabin #1 (in Vermont). It was developed in 8 days of full-time work (inception-to-delivery time was more like a month) and has a really tight, interesting mechanic. Being largely developed among friends and peers was a super fun and amazing experience – that I still fondly recall and talk about often. I’ve always enjoyed word games, and I’m very, very proud of what I achieved with IceBurgers – and even a little bit proud about the timeframe I developed it in. It’s one of the few game designs that I created that I still enjoy over a year later, pulling it out to have a few quick rounds here and there.
The game is also stocked with some of my first tries at making a game feel really “juicy” (though I hate the phrase, it is descriptive). There are tweens all over the place, animations and effects to a level of polish that I normally didn’t bother putting into a game back then. It’s kinda neat to look back on IceBurgers and see that level of polish, and the attention I put into timing and making it feel “just right.” I think IceBurgers is one of my most responsive games, in terms of gameplay feel and also visual flair, and I’m really proud of that too.
I even love the small touches, like how the awesome catchy music (thanks, Alec Holowka!) integrates completely with the gameplay.
I’m also pretty pleased that I still top the high-score charts. IceBurgers appears simple on the surface, but there is a certain depth to the gameplay that is hard to find in most other mainstream word games. I swear, IceBurgers stands out in the crowd as a rich, deep gaming experience! No, I’m totally serious right now!
I could go on, but you get the picture: I am really pleased with IceBurgers. It feels a bit vain to say so, but I’m pleased with myself for making it, too. Those bits make me quite happy.
IceBurgers isn’t all good news, though. In fact, there are more negative memories associated with it than positive ones.
There was the lackluster sales on iOS (all time units sold: 302). So here’s a game that I’m super proud of, that I think is some of my best work, and pretty much nobody has played it. I ended up making it free for a few months, just to fight this feeling – and even then I only got about 50 downloads. I can’t think of many things that hurt much more than your hard work going nearly completely unnoticed.
I was ready to laugh it off as a silly experiment, though, and swallow my pride there — move on. But that’s when things started getting really bad.
After posting a post-mortem on IceBurgers (for the iOS launch) here on this blog, I was personally attacked via email. I was told that my game was a detriment to society, that just by talking about it I was wasting peoples time. I was told that I was trying too hard, that only spending 8 days on a game is something to be ashamed of, and that the gameplay is derivative and uninteresting. My very value to society, as a game developer, was being called into question. Normally I’m pretty good at ignoring the comments, but in this case it was harder to ignore: this was my peers talking. Some of these words came from well-known developers that I look up to; some came from friends (now former).
That part really hurt.
I can’t say I went through clinical depression (that shit really sucks and my heart goes out to you that feel it), but it definitely gave me some hard-core sads that persisted for many months. I tried to avoid thinking too hard about the game ever since, and I distanced myself from the community. I tried to pretend everything was fine and wore a cheery disposition.
But it’s hard to push that stuff out of my head when I know, deep down, that it’s still a good mechanic, damnit. Sure, there was tons of stuff wrong with the game – I said as much in the post-mortem a year ago. There’s plenty of things I could have done better. So I keep thinking of it – keep pulling it back up from the depths of my memory, and with it come the harpoons in my ego. I can’t stop thinking about it, and it hurt anytime I did.
About a month ago I announced that IceBurgers was available on Android, something I had been promising for ages but avoiding because of that pain. Enough time has passed that I think I can say I’m mostly “over it” now; I can now stomach looking at the code again. The Android launch grossed a whopping total of $12 so far (thankfully the port to Android only took me a day of work), which sucks, but hey – at least I was prepared for such low sales this time! And I sure as heck won’t be posting a post-mortem on that.
Nope. No post-mortem. This time, I’m just posting a Eulogy. It’s time I moved on, that I let go. I feel like I’ve fulfilled my obligations to the game, and for the sake of my own mental health I’ve got to stop thinking about it, and distance myself from those hard memories.
IceBurgers is now dead.
(My next blog post is much more cheery: “Long live IceBurgers!“)