For Enki Adventures, I've been dealing with a fundamental coding problem. Is it better to quickly shove things together to make them work or solve problems elegantly?
Chris DeLeon makes videos where he creates prototypes very quickly, like this platformer. His code isn't organized, and adding features would be a major pain, but it works, especially for Ludum Dare and Game Jams.
I took that approach when generating procedural terrain in my game. Things worked, but I had 1300 lines of code in a single file and a lot of things that would make programmers make a face. Now, I'm rewriting the whole thing far more elegantly. But when I finish refactoring everything, the game will look the exact same. It's for the best, naturally, as I'll be able to make future changes more quickly. But I wonder if I could have avoided all this mess by doing the elegant solution first.
It's probably not possible to come up with a clean solution first, especially when doing something new. You might spend all your time figuring out the "best" way to do something and not spend any time actually doing it.
I guess it's a tradeoff, and I guess the path I'm taking is working. It'll lead to a great blog post about terrain generation once I'm done, complete with algorithms and crappily drawn pictures explaining them.
Time flies when you're having fun, and boy was I not having fun.
It's been two years since my last blog post, just before grad school began. It was time consuming as anything but probably (hopefully) worth it moving forward. Now I've graduated and finally have the free time to write up another one of these posts. Plus there are a bunch of people in the Game Dev forum posting devlogs, and I can't let them show me up.
I really didn't have time to code at all in the past year or so, putting Enki Adventures on hiatus. But I've recently had time to get back in the groove of programming. Here are some of the code things I've picked back up. (Hopefully it's not too boring.)
There's a work-in-progress code library for making user interfaces called HaxeUI. It performs some dark magic to make pretty and organized menus, and it works with any game engine written in the Haxe language. It does need a bit of help working with each engine, though, in the form of a backend library. I ended up writing the one for my game engine of choice, Flixel. I've got it integrated into Enki Adventures, so now it's just a matter of positioning and sizing the menus.
People have already started using my code as well! It's always weird and cool when people use your code libraries in their projects. Contributing to large projects is fun, but it's something special when someone finds your little old library and thinks it's useful enough to use.
In Enki Adventures, I use the Nape physics engine for collisions and interactions and things. By being creative, I've gotten these "non-collision" interactions to trigger dialogue and even swimming!
Too bad the little pet guy can't swim yet.
I probably rely on Nape way too much, but my game has excellent performance doing it my way. It also saves me the hassle of having a bunch of different systems in place to do each specific thing: being creative lets one system handle a lot of my game. My code is very organized this way.
My dialogue system I wrote years ago is paying off, letting me also open chests, receive items, and do all kinds of custom behaviors. Technically any behavior, since I'm able to inject code using some more dark magic that this language offers.
Now I'm simultaneously working on the inventory and accessibility options. The inventory is using HaxeUI and is a breeze compared to when I've coded inventories in the past. From ugly spaghetti code to an organized workflow, it's almost like I'm getting better at this. It doesn't hurt when the tools improve too ;)
I'm interested in accessibility as a topic. "Can your game be played with a single button?" "Can your controls be remapped?" "Can the sensitivity be lowered for people with jitters or be raised for people with a limited range of mobility?" "Can colorblind people play?" "What about deaf or blind people?" I can deal with two of those questions pretty straightforwardly, but the others I have no idea. There are some guidelines to include gamers with disabilities, and I'll be perusing those at some point. I saw this one DIY controller that was a bunch of buttons and joysticks on a board controlled by the person's feet; I'm pretty sure that would work with my game without an issue as long as the computer can recognize it in the first place.
So there you go. The next post will be within the next two years, and I'll be updating the Tumblr blog more regularly as well, although code is boring and I'm not sure who would even want to read that.
I wasn't sure what to post, but I wanted to post something today. So here's the current items and scribbled thoughts on the todo list for Enki Adventures, the rogue-like/lite/whatever with Jordan (look at his or my previous posts for actual game info). I doubt it makes sense to everyone (anyone?), but I'm probably not the only one with a chaotic todo list.
- How do I lob bombs? Either keep the footbox (and hitbox?) on the ground or dot the collision normals (eww)
- How do I directionally lob bombs?
- Add hscript enum??? super powerful but super terrifying
- Tween offset y with bouncing ease for horiz, scale for vert
- How do I make bombs explode near enemies? onCollide sensor (onSense?) which has to ignore the player and objs (delete inRadius and maybe target)
- Rename hitboxes to something better (taking dmg versus dealing dmg)
- Rename or clarify kb vs kbr in data files (better names prolly)
- Custom game reset(), flx's is annoying (destroys current state which i don't want prematurely)
- Abstract action1 for general bomb/boomerang/whatever
- Tween controller?
- Flicker consts
- update(0) timing
- Assign all cb groups
- Bomb place anim
- Add facing bias to knockback (straightDir somehow)
- Better iphysics abstraction
- Null weapon for enemies: need to specify dmg and kb somewhere tho (enemy stats best place imo)
- .5 sec extra invuln for player (no hit stun)
- Hp checks in CR states
- Placement of onhit/ondeath might account for this (2nd death transition might just be ignored)
- Gamepad: service per gamepad type (via lime.ui for now)
- Replay service? (change all math.randoms to flx random to remember the seed)
- Tree positioning for vertical parts (big tree, 80/48/32 screws everything up) + hardcoded numbers ewww
- Macro build a config file into Consts (into backends in Consts) ???
- Asset paths into consts?
- Hitting trees and such does something nonpermanent
- Hit hold
- On transition, only a chunk of the player gets scrolled (move player all the way forward during transition, loc problems?)
- On transition, if a bomb was exploding in the prev zone, it'll be exploding when you get back (destroy all)
- Short death anims might NOR with kb tween
To my left, neural networks are taking their sweet time to run. Behind this browser window, the beginnings of a lab report are forming. On my desk, project concept drawings and notes are scrawled on the backs of receipts. Spring break looms as a deadline and hamper to group project work rather than time off. The stretch before the final stretch.
This is senior year.
Meanwhile, my code for a Steam-game-hopeful lies restless. Enki Adventures. The flash game that can be casually compiled to an .exe. Haxe, OpenFL, Flixel, and Nape working in tandem, working against each other at times.
I thought Steam was for the big players, the real coders, the lifetime game devs. Are we dreaming big, or do we have what it takes? Roguelikes, roguelites, and procedural death labyrinths have a hardcore following. The promo art sketches look badass so far. Tom believes in us.
We shall see.
I started a Haxe version of Newgrounds' API on github: NG.hx
There are issues (of course), but it definitely works when targeting flash at the very least. Eventually, it'll be able to work with both flash and html5 content and MAYBE desktop and mobile which Tom suggested for the future of the API. It's written in pure haxe, so it should be able to work with OpenFL, Flambe, and the rest. I don't know how Construct 2 plugins work, but it could be one of those at some point. Maybe you could play a flash demo of a Steam game here then log into NG in the full version of the game and pick up where you left off?
Not Po4 game
Po4 deadline didn't work, probably because Jordan and I suck at small, simple game concepts. No surprises there, though. In the meantime, I did upgrade my beautiful green square to his art.
I prefer my green square.
The level design is being handled by Stencyl, which is really good when it's not crap, so like 80% of the time. The good news is that I don't even have to look at levels in order to add them and their content in. The bad news is that real physics engines (nape) are too realistic, and I have to hack physics to make it seem like a video game. I don't think it'll ever be perfect, so it's just a matter of how the game feels when I don't feel like changing things anymore. I'm told that's how good artists do it.
Progress on the Po4 game is going alright. VoidForce has some computer issues which might affect progress on his end, but I can churn out features without art. At least he can write up the story and draw some concepts in the meantime. The October deadline makes this much more manageable.
Or I can use code to make the art. More specifically, my brainchild, a lightning grappling gun:
Which you can try here (if the dump allows playing swf content again). Click the blue square to grapple it.
Not sure how it will fit into the story, but I'll be damned if it isn't sexy. The story will have to be fit around this.
or: I need to stop writing my own code.
Uprising is the second of four games in the Juggernaut series with VoidForce and Mattlaaa, and like fifty voice actors this time around. I'd call it a success if I wasn't the one who had to look at the code. In Flash Forum, people like milchreis and myself always tell newbies to "stop reinventing the wheel" and "use someone else's tried and true code." This game taught me that I should take my own advice.
First compile: August 6, 2013
Final compile (so far): July 7, 2014
Lines of code: 18,097 (good grief)
Close your eyes (figuratively) as you picture typing words for almost a year. That was me. Eleven months is a long-ass time to be making a flash game. The core features were finished by November, and coding menus and polish took the next seven months. Coding menus should not take that long, but it does if you write your own code. If you think playing an RPG is tedious because of all the battles and dialogue, you should know that coding a menu is worse. More tedious than Gary Motherfucking Oak showing up after beating the Elite Four. Does this button look good here? When the game takes 10-20 seconds to compile, and it takes 30 seconds to get to the menu in question, your sanity dwindles as you realize it needs to be moved over by 3 pixels. Wait, no, too much, go back a pixel. I could have done a thing in those wasted minutes.
Then you realize that this isn't the first time in history that someone has had the same problem as you. I mean, sometimes you just gotta roll your own isometric engine, but when it's so common of an issue, someone has surely written code to do it for you. And when you find that code, you realize that it's written in a different (coding) language. Or that using it would set you back several months. So, out of necessity than volition, you keep on using your crappy code. Thus was coding this game. That button looks off now, it should be moved back another pixel.
Every time VoidForce wanted a change, I was the one who had to implement it. I wanted him to correct a spelling mistake, but there was no way for him to. He messages me at some nonsense British morning time, and I wouldn't have a chance to do anything about it until after class (or after I woke up at noon). Changing an enemy's hp, compiling, uploading to NG, and PMing him that the change was made is a complete waste of time. Next time, he will be able to change anything he wants. Change where someone moves in a cutscene. Change how much hp an enemy has in this map. Change the order that dialogue gets spoken. Change which audio plays in this map. I won't need to touch it. The next game will basically be a parsing engine that takes in a bunch of files that we both can edit. GitHub or DropBox, though Git is a bit overkill.
My code sucks. AS3 sucks. The game's memory usage sucks. Coding menus sucks. Testing sucks. Bug fixing sucks. Yet the game gets daily 3rd on NewGrounds behind automatic-1st-place movies from SexualLobster and LazyMuffin, and it's been featured front page this entire time. It seems that a game can be made of suck and still do pretty well, mainly because everything I've complained about is invisible to the player, bugs excluded. But according to analytics, players like it in the first 6 minutes, then most stop playing. On average. Most people don't play past the first minute. Preloading much?
Analytics. Data. The purest form of understanding a game's success. Almost every aspect of the game is being tracked. How long does the first quest take? 12.03 minutes. Which site has given the game the most traffic? uploads.ungrounded.net (NewGrounds). What percentage of people who start the game finish it, and how long does it take? 0.33% and 4.74 hours. How many people used a feature? Not enough to warrant adding it next time. If the average user plays for 6 minutes, and the first quest takes 12 minutes to complete, the average user does not complete the first quest. We can use that knowledge to place emphasis on earlier immersion in the next game. With 475,132 events tracked so far, we have a decent sample size to make judgements like these. This image is people who click the game and people who press play vs time.
Last time I wrote that finishing the game was a good. This time, being finished with the game feels better than finishing it. It's my penultimate project written in AS3; one more until Haxe rules everything around me. It was painful to code in AS3 knowing that I could be happily coding something else in Haxe. The next game will be a pleasure to code, so that post mortem should be a happier read. I'm not sure if it'll ever be "game was good, I had no issues" like I predicted a year ago, but there will be less complaining and more flowery, chocolatey happiness.
I can't enjoy the game because all I see is my code. And my code is a pile of suck with analytics tracking how much suck there is. Luckily, that mentality doesn't affect the game or the players, just the comments in my code.
Juggernaut II is better than the previous game, and the next one will be even more so. It will be written in Haxe OpenFL ("A mobile version of the game?!" you ask. No, go away). And it won't take a year to finish.
There's a fairly good chance that Juggernaut II is complete. If that's the case, it'll be released in the next few days with a lengthy post-mortem write up maybe a week or so after to accompany my previous one. In development from August to June, this game ate my free time like a herbivore will eat meat when given the opportunity. Now that it's done or very nearly done, I have time to work on some other projects that I've put on the back burner in addition to the Po4 game. More of a write-up will come later, but it'll mainly be about how I could have used an actual game engine to save 4-5 months of time, even more if I had used haxe instead of as3. Yes, I'm an idiot. But that's for next week; time to focus on Po4 and stuff.
Speaking of which, team Razzle Dazzle is four-strong and ready to give you the old razzle dazzle.
Side note: I'm surprised that this works so well being typed on my phone. It's a bit janky, but not too bad.
or: My inaugural front page post.
Po4. Haven't started, haven't finalized a team and team name, but I'm tossing around on some initial ideas. I'm thinking a game where you have the option to run 'n gun (Metal Slug style) or stealth through the level. Kinda like Deus Ex I guess, which I recently finished. It gives the player the choice of a fun, arcade game versus an almost puzzle game. I'm sure fitting "4" into that won't be too hard.
With OpenFL, the option is there to make an HTML5 version of the game which would let it be played on mobile on NG. We'll see about that.
Juggernaut 2 is maybe a week away from being done I think/hope/pray. After that's done, I'll have all the free time in the world to work on Po4 and a few other smaller projects. I might just get my sanity back before fall semester. Wait, no, I have to take the GRE soon. Never mind.
I'm almost done Juggernaut 2. Super almost done. Adding polish, and then we have to get a server to host the audio files. Without audio, the game is a respectable 3.63MB. With audio, it's a monstrous 15.84MB. Seriously, 336 dialogue and sound effect files plus 13 background music files. I'd say 12MB is good considering what the uncompressed WAV filesize was. So half of the filesize will be hosted on a server to be downloaded to the game while the other half gets preloaded like normal. Theoretically, the preload time will get cut in half. The server might also get used for hosting a website for the artist, but we'll see.
I also have analytics set up to monitor EVERYTHING in the game: how many people buy items, how many repeat visitors there are, how many people find the secrets in the game. It'll be great, I'll have a graph for everything. Knowledge is power.
After this and after one more project I'm helping with, I'll be done with ActionScript 3.0 hopefully forever. Haxe is way more fun and powerful. Haxe is basically AS4 since Adobe cancelled the actual AS4 (RIP).