I was talking to my friend Brian the other night when he suggested I keep a dev log on my latest in-progress game. I explained that I had planned to, but that my line of thinking always seems to go something like this: “Hmm…I have somehow discovered a few free hours in the day in which I can do something with. Let’s see, I can either work on my game and actually make progress, or I can spend the rest of the day writing about working on my game and make no progress. Yeah, I’ll just work on the game.” Plus GoDaddy seems to have issues hosting WordPress for some reason, and it will occasionally crash when I attempt to save an article. This usually results in the deletion of whatever I had written since I last saved, as just happened. Why does technology still have such blatant shortcomings? I mean, WordPress should have been able to do something halfway intelligent, you know, like attempt to save but present an error message if the request failed or timed out. At least I wouldn’t have lost my work. Is it too much to ask for good, solid software?
Anyway, my friend pointed out that taking the time to write about my development experiences is a more balance approach over programming all day. Plus it helps me to step back and analyze what I have been doing, which is very valuable in the long term of things. That said, let’s jump in (and rewrite a few paragraphs.)
The Title
PuzzleCode is the name of the game. The very basic, generalized, may not be fun yet, inkling of an idea in my head goes something like this: “There is a puzzle. Create a program to solve the puzzle. Rinse, Wash, and Repeat. ”
The overarching goal of the game is to teach the player the core concepts of computer programming, hopefully spurring enough interest to get the player to learn a ‘real’ programming language on their own. It makes sense to relate the concepts over just teaching one language because programming is a transferable concept. If you teach someone how to use a for loop, that person can, in a fairly short time, program a for loop in Python, Java, C# , C++, JavaScript, etc.
Where Are We?
In terms of the actual game I’m not really…anywhere. I’ve been working on the core game engine that will run PuzzleCode and future games I (and possibly others) develop. Now, a lot of semi-experienced to experienced devs out there upon reading this will think, “Dude, if you want to make a game drop the whole Game Engine BS and use something like Unity or ‘whathaveyou’ framework.” Now, I’m not no novice. Yes, its true that using the Mono Framework or GameMaker or XNA or Torque or any of the other engines or frameworks out there would allow me to build my game much much faster. But you see, I’m one of those types of people who derives enjoyment out of engineering. I like game development too, but I get very bored and apathetic if it is all game dev and no logic crunking engine building. The same goes in the opposite direction. All engine building and no game dev makes Johnny a dull boy.
I discovered this relationship that my mind demands when creating Project NERD for the Cyber Center using the Unity Game Engine, and I discovered it again when designing another game using Unity for a client on oDesk. I simply hate using game engines. I eventually hated it so much that I had to quit the oDesk job and move on to something else. The game engines that are available today don’t work the way I think they should work. They are inefficient to use. They are buggy. The interfaces are clumsy. They are not built with multi-threaded CPU architectures in mind. And they are, generally, overpriced. I build my own because I have more fun building then dealing with a slew of shortcomings offered by third-party game engines.
There is also something very…I dunno sublime about building a complex system. It becomes a direct extension of the creator’s mind. It encapsulates the way the builder views the world. The logic has a certain feel about it. This is true of pretty much any game engine. The games built atop Valve’s Source Engine have a very particular feel to them. Half Life 2, Zeno Clash, and Left for Dead all have different art styles, and were developed by different teams, yet they all feel as if they belong to the same family. I can describe the Source Engine as feeling ethereal, while the Unreal Engine (ironically) feels very base and gritty. I’ve heard consciousness defined as the ‘the feeling of processing information.’ I like this concept. When I read, I can feel it go through my head. When engineering I can feel the logic flowing from some hidden stream at the core of my mind. Game Engines then, are, in some way, the embodiment of the consciousness of the person or persons who built it. The logic feels as it feels for the creator to have thought of the logic.
PixelBurst
PixelBurst has a very long, unofficial history. I have essentially been working on variations of this 2D Game Engine since I started fiddling with XNA in 2008. Every game developed with it would bring about extensions, modifications, or, in some cases, complete revamps. I first developed PixelBurst in tandem with a puzzle game I was working on in 2008 called MindBog. I worked on MindBog and PixelBurst for months, before finally coming to the conclusion that MindBog’s concept simply wasn’t going to work. Frustrated and apprehensive with my shortcomings, I challenged myself to make a game in a single week using PixelBurst. This game turned out to be QuadTrix.
QuadTrix revealed how hideous the whole thing was. PixelBurst was messy and slow and difficult to use. I would have been better off simply writing raw code to do what I wanted. But I was also a newcomer to the whole game programming thing, and as any game programmer will admit, starting down the path of becoming a game programmer is daunting. You have to learn so many different skills at once that it is impossible not to become overwhelmed. It feels as if every piece of knowledge is a prerequisite to something else. All you want to do is draw an image on the screen, but before you do that you must understand how the entire universe works on a sub-quantum level….that’s how it feels anyway. So yeah, major kinks were to be expected.
But it wasn’t all bad. I just opened up the ancient Visual Studio 2008 solution to take a gander at QuadTrix and the version of PixelBurst it runs on, and it’s amusing how many ideas have survived the cuts over the years. Really, even the C++ version of PixelBurst I am working on now follows a nearly identical vein of logic at the core. So even the old version had some good ideas in it, it was just covered over by noob cruft.
After QuadTrix I knew some major redesigns were necessary. I kept a bunch of the code, but I also redid a huge portion of the core. I call this version PixelBurst 2.0. I started building Nut Harvest 360 using this engine, but, as I stated in past biographies, the lack of a proper visual editor and monetary burdens put this game on indefinite hold. So I built Didgery instead.
It is somewhat interesting to me that my best game (imo) was built on an engine one generation away from a bunch of beginner mistakes. I was able to build Didgery fairly reasonably, but there were still a number of issues I had to deal with that slowed me down a good bit. Things were also too rigid ( a problem I discovered when building MindBog. ) I would like to go into detail of why this was, but I’m afraid it would take much more time than I currently have available.
Things were slow for a while after Didgery. I was going to school at Shawnee so I didn’t really have any time to do anything. But then, on some spring or winter break, I decided to put a lot of ideas in my head into action. PixelBurst 3 was built, and, for the first time, it solved the long standing rigidity issues by using an Entity-Component system. The problem was that it was less of an Entity-Component system and more of a Component-Component system. The thing was so flexible that it was laughably unusable. I’ve heard stories of athletes who stretch so much that their joints will pop out of place if they are not careful. It felt somewhat like that. It was also incredibly slow, and, due to the flexibility, complicated to use. Greg and I started the yet unfinished Platforming Block 360 on this engine.
I then worked, for real money, for two real years. Though I didn’t do anything with PixelBurst during that time, the development experience I gained during these years shaped my views for the latest and greatest PixelBurst.
So now…here we are. I have been working on the forth incantation of PixelBurst for about a month now. Unlike the previous versions of PixelBurst that run on C#, PixelBurst 4 is written in C++, so none of the code from the old versions are reusable. It’s kind of nice to get a clean slate of things and write it the way it should have been written years ago. The interesting thing about PixelBurst 4 is that it is engineered it in such a way that the engine itself is generic. What I mean by this is that one could develop a 3D game just as easily as a 2D or a 2.5D game using the same engine. There is no other engine out there, that I am aware of, that touts this sort of behavior. It is also trivial to switch the rendering APIs. Right now it is using DirectX 11 to render the sprites, but I could switch it to OpenGL 4.3 or DirectX 9 within a day, and I can do this because the inherent ‘decoupled’ nature built into the engine. The design of PixelBurst has enormous potential, and I look forward to seeing where it leads.
Anyway, that’s pretty much where I am. I’ll try and write my progress at least once per month. Hopefully the next time I write I’ll have some sparkly images to display. Wish me luck :)







