I’ve always coded differently. Even back in the Atari 8-bit days, when coding using a basic compiler or even when coding 6502 assembly language, I’ve always taken the easiest way out when it comes to computer programming. Granted in 6502 Assembly my code was a bit more low level and optimized, but anybody that had seen my code, always said the same thing… that my code looked very high level and for the most part it was very easy to read and understand.
I’m Smart Enough To Code High Level
I was never good at math. I had a basic understanding of the more complex subjects, but as a general rule if I needed to code a complex routine I instinctively broke each task down to it’s basic part, and through a series of smaller routines, the larger routine would be completed. This way of programming later came to be known as “decomposition – the process of breaking down a problem into smaller, easier-to-solve problems.” But this was always my way of thinking when it came to computer programming, this style of thinking and programming came naturally to me. I remember seeing code published in magazines, or code from other developers that I knew, or when I collaborated on projects, and I would almost feel embarrassed by my own code. My code looked simplistic, easily understandable, while their code looked more complex, hard to follow. One developer finally made me understand the only real negative about coding the way I did….and still do. It didn’t result in the fastest execution at run time. Their code was very linear from top to bottom while my code would ultimately end up JMPing, GOSUBing, all over the place as it solves it’s various problems.
An Evolving Library
The biggest benefit of this style of programming (unbeknownst to myself), I was creating a library of reusable, stable, code I could use in any program I developed. Anytime I ended up coding something unique for a demo, game, etc, it would end up being added to the library. Over time as my computer skills grew I started optimizing some of the library routines. On the Atari ST via GFA Basic, you could call 68000 routines so I optimized some of the more complex routines which resulted in a massive increase in performance.
Each time I moved to another platform… Atari 8-bit > Atari ST > PC (VB6) > PC (BlitzMax) > Wii (C+) > PC (Flash/AS3) > PC (GameMaker) > PC/Android (Air SDK)… the first thing I would do is spend time designing a new library specific to that platform. With each iteration of the library, it clearly was becoming more of a game engine than just a library of reusable code. Things were evolving nicely on the Atari ST. Even with the primitive “GP Graphics Engine” it was clear where my brain was headed. I don’t know if I was the first one to coin the phrase “set it and forget it” 😉 lol.. but that was clearly the motivation from a programming point of view. Sprites could be created calling just one line of code, then you could launch a sprite to move around the screen with one line of code, etc, etc. I could focus on just the main logic of the game where the “engine” (called once per game loop) would take care of all the lower level stuff like rendering tile maps & sprites, moving sprites around, etc, etc. As the engine evolved I even added sound effects, screen transitions, etc, etc.
Hyper Focusing For Rapid Game Development
I remember testing myself how fast I could write a demo or even a somewhat full game using my game tools. Some of the games on the Atari ST Review Magazine took less than 1 day, and some only a few hours. The slowest part was always…the graphics. One of the longer games to code was Kid Kong. I remember creating the graphics for Kid Kong, I would look at a photo of the Donkey Kong and Rainbow.. (Island??) sprites, draw the images by hand on graph paper before drawing them in my sprite editor. Hilarious…
One Big Mistake Changed Everything
When I was about to release my new updated game tools to the Atari ST public, a fast talking gentlemen convinced me to release a modified version of my game tools in a commercial endeavor for the Atari ST. I’m not a perfect man, I have made plenty of bad decisions in my life, but the decision to get involved with this project was easily the worst decision of my life. Sadly it was also the last time I had anything to do with the Atari ST. I can safely say this publicly… my wife… saved my life.
PC – “Here I come to save the day!”
When I moved to the PC, my language of choice was Visual Basic, I believe it was Visual Basic 6 where things became a lot more interesting. Full disclosure.. from this point on and to this day, thanks to faster processors I never had to worry about optimizing my code ever again. 🙂 lol..
I didn’t move to the PC at first to create games, I moved to the PC to make a living. I’ve always been stubborn when it comes to work, I have a false ego, and that ego never let me work for anyone else except myself. well.. I did have a short lived job at a rather large company at the time called Sculptured Software. It was very cool seeing Mortal Kombat cabs everywhere. At the time I was on the team doing the Genesis conversion. This was very early in the development phase, I was part of the main interface team. Things didn’t work out, I wasn’t much of a team player, plus they were bought out by another company, things were restructured, lots of jobs lost, etc, etc. So off to the PC world I go…
Making Money Making PC Screen Savers
I had a programming bud who started a software company and he told me the PC world was a gold mine. He was right… I couldn’t believe how much money he was making all by himself. lol.. We talked and agreed that with my ability to code smaller projects quickly, we should focus on quantity rather than quality. I focused on learning Visual Basic and again coded a library of routines that allowed rapid protype development. Long story short we jumped on the PC screen saver bandwagon at the right time and made a killing. Some of the screen savers I made had animation, I even made a few animated game screen savers. Probably the first of their kind? But coding these animated screen savers brought back the urge to start coding games again. So after our little software venture dried up I learned about a little thing called Direct X.
DXGame Engine For VB6
I started exploring Direct X routines via VB6. There was a couple of 2D draw routines that allowed very fast 2D drawing to the screen. As usual I created a library of “set it and forget it” routines. This library evolved into the “DXGame Engine” project for VB6. When DirectX 8 was supported in VB6, things really took off. Now we had hardware scaling, rotation, alpha, additive blending, etc, etc. I released a free for public consumption “DXGame Engine” or simply “DXG” and at one point had 100s of developers using the kit. Plenty of demos, shareware games, even a few commercial games were written with the DXGame Engine. That was an exiting time code wise, because it was basically a public proof of concept that my high level design approach to creating a logic game engine was sound. If I may be so bold, to this day I think the DXGame Engine was way ahead of it’s time in regards to a 2D game development library. Everyone who used the DXGame Engine agreed it’s biggest selling point was the rapid prototyping it allowed. Visual Basic started moving into the net phase and I lost interest due to a lot of the ease of use features of VB6 were gone.
About this time I learned of BlitzMax and it had my attention pretty quickly. Here was a full gaming language that had a lot of familiarity to me. I was able to get something up and running very quickly. As usual… I started building a library of routines that evolved to a very useable game engine. During the development of the DXGame Engine I realized I was basically creating a game engine that for all practical purposes could be easily ported to any language. All I would need to do was fill in some code in the render routines that called platform specific api/functions.
PlayMGE For BlitzMax
PlayMGE (and later just MGE) for BlitzMax was created rapidly using the code base from the DXGame Engine. Things were up and running in a matter of days. I wrote a couple of games using MGE as a proof of concept and also released MGE as tool for BlitzMax. My time with BlitzMax was short lived because everything was about to change with something called… Flash.
Enter JV Games Part 1:
But before Flash… a long time Atari ST friend Vince Valenti of JV Games took notice what I was doing on the PC and thought it might be fun to release a version of a PC game I wrote called “Christmas Clix” for the Nintendo Wii. So we talked strategy how to get this done as quickly as possible and we agreed the best way was to simply give his team the source code from the BlitzMax version which would also contain the source for MGE, with the hope they could port the app to C+ and then have it up and running on the Wii. To my surprise and maybe even Vince’s, they had the app up and running in a matter of weeks!
Christmas Clix for the Wii’s download service was released on December 7th, 2009.
We wanted to take advantage of a Christmas game being released right before Christmas. At the time we thought it was going to be a money machine for us. lol.. Sadly it came out at the same time as some popular Nintendo exclusives did at a similar price or cheaper, so Christmas Clix for the Wii never had a chance. Looking back we agree the game should have been priced much, much cheaper. But it was great seeing one of my games running on the Wii! 🙂
May 18, 2024
