The Stencyl Jam 2012 contest was announced since early May (I think... it's been a while). Usually when these contests are announced, there's some sort of tight deadline. But since the deadline is July 31st, and Stencyl was a program meant to aid budding game developers, I figured maybe it was worth a shot. Gives me a great excuse to get started, and start small.

Yes, start small. My original idea I've been writing about in my earlier posts is going to be much larger. I don't have all the ideas down, and it's going to be much more complicated than I could possibly do in a couple of months. Even without the testing and iteration, it's probably still not enough time. So I had to quickly come up with an idea that I want to do. I decided to do a tribute game to an obscure puzzle game that I had enjoyed, since it is territory not covered by Stencyl's crash courses (a platformer, a shooter), I personally enjoy puzzle games, and it's also something Knuckstrike wanted (dungeon crawler). Kind of.

So here we go: making a game in flash, so that I'll know what to expect, what I can do, and what a huge pain in the ass it all can be!

.

Dev Diary ==========================

Early May: Started doing pixel art for the game. I already know what I want when it comes to pencil drawings, but I've been dabbling in pixel art earlier for the phoenix. And ... well, it was a lot harder than I expected. One thing's for sure, pixel art at a medium scale or smaller cannot really be done with computer algorithms.

This time was mostly spent in experimenting with shapes and sizes of the main character. I have the least confidence in drawing creatures, so I just kept at it for all sorts of tries and variations. Eventually, I finally settled on a couple of poses that I could use for the meantime. If things go as expected, it's very likely that the character will be replaced for something that's better. I couldn't just go without trying out a weapon on it, so I went ahead and pixeled myself a sword too. That went a lot faster >.>;

.
Mid May: Started pixeling my first tile set. It went okay. There's quite a bit that's left to be desired though, both from a level designer's perspective, and aesthetics. Specifically, the walls that aren't facing south can only be seen as a thin line of pixels that aren't distinguishable from the core/fill. I'll have to come back to this later, but first, I have to figure out what exactly I'm getting myself into when using Stencyl...

.
Late May: Downloaded Stencyl, and went through the crash courses. Other than the provisional "sounds" and "music" being .png images (lolwut), it was a fair display of what to expect. However, for the genre of my choosing, it left very little to go on for a starting place. Well, I wouldn't be a programmer if I didn't attempt to tackle such challenges head on. Mostly spent the week staring at all the options, and thinking about how I wanted to do things, as my training from the crash courses quickly disappeared.

I decided to check out the scene designer, since my years of playing games basically screamed "a tileset exists!" Sure enough, I had the tools to make a level. However, in a bit of shortsightedness, I quickly learned about my fallacies in my tileset, partly due to the possible combinations of wall arrangements, and also because of how level designing doesn't necessarily impact performance cost.

7 retries later, I got really fed up with the rigid inflexibility when it comes to editing tilesets in Stencyl. I decided to just roll the common tiles, then make a tileset that can make virtually any tile I could possibly want. Extra doodads and details were to be made in their own tileset.

.
Beginning of June: I got into the dirty of coding, Stencyl style. Actually that didn't last very long, since what I wanted quickly went out of the scope of the "design mode" tools that were available. So it turns out I have to learn AS3 much sooner, not that I mind.

Right off the bat, I had to deal with coordinating computer calculations and the visual interface. It was certainly much easier dealing with only code that happened in sequence. However, I have to deal with handling player input, making sure something happens when it should happen, and something shouldn't when it shouldn't, timing events, making sure other code doesn't interfere in the process, ... , all while making sure that it runs at a satisfactory fps for smoothness. In addition, I have to learn about all the nuances that come with working in the "fourth" dimension. For example, the KeyStateListener for a keyboard key that's held down (as opposed to pressed or released) will keep firing off, even if another condition later becomes false.

That all said, I tested the waters with what little I have and discovered a few things. FPS is already dipping close to my lowest acceptable rate, and a massive amount of enemies severely slows down the game. Clearly a work-around will have to be done, since Stencyl is using a lot of scripts that I don't actually need. The big culprits being suspected are drawing the whole screen, and the Box2D collision engine.

.
June 4th: Finished up the movement system, excluding rotation controls, and it's pretty solid. However, since I want to incorporate convenience and some semblance of dynamics, I've went the extra mile to allow the ability to hold down a directional key so that instead of just moving once per press, you can continue moving across a room really fast if you hold the key. The set of conditions I'm using aren't air-tight however. I'd like to continue working on the control scheme, but I'm probably better off exploring the rest of the components needed to make the game function at its most basic.

.
June 6th: I explored ideas in coordinating information between the player, monsters, and the level. It is infuriatingly annoying unfortunately, since I can apparently define, set, and get attributes on the fly, but I can't refer to attributes of an external creature/level that "may possibly not exist"? Maybe there's a really good reason for this, but it's a barrier that I will have to overcome and work around.

.
June 7th: Worked on making the camera follow the player. It's unlike the kind of cameras I've seen used for flash movies and games. Or even the SNES. Go figure >_> I've also discovered a critical error with my movement code in the current revision if I were to proceed with my camera coding. This makes me glad that I'm looking at all fronts first before I try to bring the project forward as a whole.

.
June 9th: Fixed up the movement system, so that it now works as intended, and should work smoothly in all situations. However, it isn't responsible for coordinating with the camera system or monster movement. I'll need to figure out the best way to coordinate all of these elements, along with the scene, so that it all works in harmony. Or disharmony if you die. lol.

.
June 10th: I forgot that you can define getters and setters for your own functions and behaviors. Part of it has to do with how Stencyl and Stencylpedia is set up, part of it has to do with the fact that I haven't coded for years now. FML!

.
June 12th: I'm quickly learning that Stencyl and possibly Flixel are including tons of features and functionality that are running constantly, whether they're being used or not. I suppose it's fine if you're doing some platforming action. However, I have absolutely no use for the vast majority of their functions. Using the more in-depth knowledge, I conducted some tests. Stress testing has revealed that adding oodles of Stencyl actors causes severe FPS drops, even if they're off-screen and "disabled"; same result as the last time I tested this. In addition, the Stencylpedia claims that there's no performance impact for having multiple layers of tiles as opposed to one layer. That's a flat-out lie.

I've set up a bare-bones level that hopefully captures the optimal performance that I can squeeze out of Stencyl's engine. It has two layers, but a layer that's composed of null tiles runs faster than a layer filled with actual tiles. I'm also rigging up a system that handles the drawing and collision of the monsters. Stress testing with this system revealed that they're virtually lagless (thanks to Abigayl and Sunflower for the idea!), with the exception of when the screen is completely stuffed with them. Even in the worst case scenario, the FPS is still pretty darn high. In the meantime, the player will remain a Stencyl actor, just because it is convenient. Depending on what I can code up, I might convert the player into my own custom system.

Technically speaking, the system that handles the monsters is a series of lists, each that hold their own values. It's easily conceivable from a programming perspective that monsters can be objects, though at the moment I have no idea how this impacts performance.

.
June 18th: A worst case scenario has happened. My computer froze while Stencyl was prepping the game for testing. This resulted in all the .xml files associated with the game becoming corrupt, and all work is effectively lost.

But fortunately, I have a backup copy of my game! Unfortunately, it is from 5 days ago. Still, it's not going to take me 5 days to reproduce what I've done. In fact, some of what I did was exploring possible options for coding and tinkering around with possible effects.

I've also discovered that the game that I'm trying to emulate actually released its source code a while ago. That kinda felt like a slap in the face, but at the same time, it would be cool to see what they've done. Right off the bat, I don't understand half of what's going on, since it is written in C++, and I don't quite know the jargon of that language, especially with all their symbols and syntax. But I'm certain with enough staring, I should be able to understand what's going on. It is also clear to me that the Flash engine being used by Stencyl is incredibly inadequate in terms of performance compared to the source code. Whereas my Stencyl game struggles to make all the necessary calculations in a timely manner, the source code just laughs in its face while having a shytton more methods, classes, and flexibility. As for me, I gotta do this one step at a time....

.
June 24th: It keeps feeling like I'm derping on something and/or I'm jumping the gun on things. But as I continue to learn the nuances of the coding language, I've learned more and more about the best practices. Obviously this issue would be over 5x faster if I had an actual tutor xD

Also, this.

.
June 26th: Since the Stencyl API is shytty as hell, I decided I would dig into the Flixel API and see what I can find, since Stencyl makes use of Flixel. What I discovered was that a good amount of stuff I didn't want running in my code was to be blamed on Flixel. But Flixel was designed to be a general-purpose library that's suppose to expedite the game programming process, so I can't exactly blame them. Instead, I'll just continue to dig deeper and see what useful goodies there are.

That doesn't mean Stencyl is completely off the hook though, far from it. I've devised a simple profiling test for small operations, which basically repeats the function on the order of 10 million or so. The execution time ranged from anywhere between a fraction of a second (!!!) to nearly 30 seconds. Anything significantly longer than that, and I should either scale down the number of loops, or the game "froze". I'm amazed at the number of things that Stencyl does behind the scenes that works for the bumbling beginner game dev, but is unacceptable for a journeyman programmer. For example, if I wanted to increment a number by 1, doing it Stencyl's way (tells ... something that the variable has updated) has a test duration of roughly 13 seconds, while doing it my way (variable++;) has a test duration of 2.5 seconds. Seriously?

Despite the light in all this however, I can't get bogged down in optimization. If I had it my way with optimization right now, the code would be nearly unreadable, and I might risk having to redo everything if I find out that something I wanted to do doesn't work with my current code. At this point, all I need to do to finish the core engine is code up player death. Then it is time for the bells and whistles. I'm still a bit stumped on how to approach drawing the map, but I believe looking into the BitmapData object would provide vital answers.

EDIT: Major setback has appeared! Apparently when my camera moves, the monsters move with it. This is absolutely unacceptable, and will need to be fixed.

.
June 29th: Is it really only a month left until the Jam deadline? Dang, that's a lot of time gone!

I got really interested in stress testing my engine to see where I stand in terms of performance. It's amazing what kinds of strides you can make when you really put your mettle into it. If you tried to use Stencyl's actors for monsters, you'd start getting a lot of lag at 20 monsters or so. And at 100 monsters, you'd get horrible lagging. If my computer is struggling to breathe, what chance do most people's computers have? On the other hand, if you just have one actor and copy its sprite all over the place, while having a grid of numbers to track data, it can pass for an actual monster. I filled a single room with nearly 700 monsters, and the fps is showing at a stable 26 when everything is moving around. When you think about the magnitude of improvement, that's some wicked sick biznasty.

Of course, that was without the bells and whistles. I already had the code in mind to program the gibs when you kill monsters, so I decided to do it, iron it out, and debug. It didn't hurt performance noticeably more, but my game is looking a lot better because of the particle effects.

I can't help but feel that an expert game dev would look at my code and literally lol at how bad it is. Whatever. Make the mistakes, learn from them, move on. Gonna actually code death tomorrow....

Oh, and a matter of urgency has turned up: designing and sizing the width of the HUD. It was a decision I kept on putting off, but it has to happen soon or else the rest of the game could go out of sync.

.
July 2nd: Today, I put together a whole level to test out my engine so far. It was moderately cool, but it doesn't really have much substance to it. Probably because it has no sound, no story development, and I just threw together a level just for testing xD Nevertheless, I discovered a few more bugs that I needed to iron out. And rather disturbingly, the game crashed once for no apparent reason. Hmm....

These tests so far have all been done on a fairly high powered computer as far as flash games are concerned. It'd be interesting to see how much crap I'll have to deal with in my game when other people test out my game later this week xD

But before I can even think about rolling out a test game to the testers, I'll have to implement changeable controls. The game abuses the 10 key, and some people either don't have the fortune of a good 10 key, or it just doesn't exist whatsoever. Options to change the controls, among other things, will be required before I can proceed.

.
July 7th: I found a composer that's willing to provide music!

On the other hand, the number of complications never ends. Over the past few days, I've quickly started hating my color scheme. I mean, seriously, who really enjoys a non-action game that's all grey? And like most really complex software, Stencyl started doing strange things, such as giving me a completely white behaviors screen. To save myself from needing to do unnecessary debugging, I've decided to ignore any demands for updating Stencyl to a more current version, since things change, and some of the bug fixes would cause my code to not work anymore (mostly math-based calculations).

The first beta test round has been delayed because of these complications. If Stencyl was a veteran product, there would be no way that I should have encountered some of these errors and bugs. But time marches on.

.
August: Been a while, but better late than never. There's been several reasons that have contributed to why I never finished this project. But I will list the most important ones:

1.) My brother was having a wedding mid-late July, and there's a lot of shenanigans that go on with my mom's side of the family. Due to poor planning and an excessive amount of wading through highway traffic jams, there was a lot less time than I was hoping for.

2.) Stencyl is great for expiditing the process for making games, but unfortunately the limitations and restrictions intended to make it modestly idiot-proof got in the way and made my game unable to perform well on all machines. The alternatives were to either strip the UI (which probably would lead to lots of "what do?"), or do lots of clever transitions. In comparison, Caravel Games released the flash port of DROD: KDD, which basically blows my tribute out of the water in terms of performance.

It's too good to throw away at this point, but for the forseeable future, I'm probably going to abandon this project. I'm going to move on and learn AS3 from the ground up instead of using Stencyl, and hopefully build cool and interesting prototypes for better games. Some things I have learned from the theory:
-- Flash uses a single thread. That means all the code and rendering happen "in line", and where one takes a while, there's less room for the other. Overloading the thread causes lag in the flash player, and it will slow down. There are tricks to reducing lag, and if you really need to, you can resort to coding asynchronously, which allows the code to execute and not hang up the rendering.
-- Allocating memory takes time and sucks. This is why object pools exist, and why in certain games, it is advantageous to allocate all the memory you anticipate using from the get-go instead of during a game.
-- While the garbage collector is a nice convenient feature, it actually takes up resources during run-time. This can cause intermmitent lagging. Another reason why object pools exist!