Delta Code

Finish what you start

2011-12-30T20:00:00.001-07:00

Finish what you start! And I know what you are thinking: easier said than done. Right?

Let me elaborate.

I don't mean to throw away hours of your life on something you've grown to hate. That's for EA employees. At least they get paid. You, on the other hand, your time is precious, even more so if you have a full-time job, school, a family to support, or any combination of these. You could die tomorrow! So it's in your best interest to put your free time towards something you love.

This is why it's very important to finish what you start. Because, in the end, it matters whether your time went towards a proud achievement or a half-baked idea, a cool game that is enjoyed by millions over the internet or another project put on hold indefinitely.

But is it really that simple, to finish what you start? Is it simply a matter of dedicating more time and willpower to a project? I don't think so. Believe me. I've tried. Simply "trying harder" doesn't work.

So what does?

You need to guarantee that you will finish your project before you start.

Is this possible? Theoretically speaking, no. But it should be a goal, even if it's an impossible one.

You must assess how much time you can dedicate to your project every week. You must have a clear vision of your project, from start to finish, the more detailed the better. And you must estimate how many hours you project will take.

Will it take six months, a year, maybe more? Are you disciplined enough to work on this project consistently for an entire year, or will you lose interest after a couple months? Knowing yourself is essential.

I will lose interest after three months. That's my limit. So if I estimate that my video game will take six months to finish, then I have a problem. But I don't have to drop the project. I just need to alter my plan and re-evaluate my time. And there are some options for this.

If you don't have the time then don't do it.

The simplest is to cut back: drop unessential levels and features, forget multi-player, or reduce the complexity of some game feature like artificial intelligence. These are nice features, but your game can do without them. Simply put: if you don't have the time then don't do it. Stop! I know you may not like that statement, but don't send me hate mail just yet; there is a silver lining to this method which I will explain.

This doesn't mean that your game has to suffer so much that it becomes a minimalist piece of junk. Often you'll be cutting out features that don't affect the core theme or tone of your game. You can still have awesome gameplay, story, or graphics; but decide which is most important, figure out what you can do with the time you have, and then do it.

The good news is that, if on a later date you want to expand upon your game and include that awesome feature, there's nothing stopping you! In fact, you have a complete game to expand upon. So if that feature is too hard or just doesn't work out, then no problem! Your game is still good to go. Not to mention it is also much more fun to tweak a fully functioning game -- an additional motivational factor to help you add that extra zap and polish wherever your game needs it.

The major benefit to planning this way is that it forces you to develop what you need first, then what you want. And what you need first and foremost is a fully-functioning game. No one cares about your award-winning pizza-delivery AI system if they can't play your finished game to see it.

Dream big! But live in reality.

It's all too easy to dream big, way big! This is good. It fuels creativity and gives you tons of ideas to play with. But you need to understand just how many man-hours are required for your "big dream." Usually the games I want to make would, in reality, take a good couple of years with a team of 50. So unless I dedicate the rest of my life to making that one game, it just won't come to fruition. This is why so many newcomers to programming, fuelled by the dream to make the next Quake or Half-Life, never get off the ground. The amount of time and dedication to complete something like that is staggering. It took thousands of man-hours with large teams of very smart people to make those games; so why would you -- one very smart person indeed -- be able to do the same in roughly the same amount of time?

I'm not saying you can't have that "big dream" of that awesome game of yours. Just be realistic about it. Valve, after all, shipped Half-Life within a couple years; but they were smart about it and put together a team of very smart programmers, artists, level-designers, you-name-it! It wasn't a one-person job.

So I guess what I am saying is don't plan a project that'll take a large group of people working full-time to accomplish. You are, after all, only one person. Unless you plan to take a path similar to Valve, keep it simple.

The most bang for your buck.

Starting a project without a plan is tempting, but in the end, even if you do finish it, many hours are lost from feature creep, changes in design, changes in code, and who knows what else. Time is too precious. Each of the above points are tools to help you make a plan to guarantee that you'll finish your project with what little time you have. They're designed to give you the most out of your hours -- the most bang for you buck.

Be realistic and honest with yourself, your time, and your expectations. This is one reason why designing and planning your game beforehand, in as much detail as possible, allows for a smoother development process: you better understand what to expect, how much time it'll take, and which features to prioritize.

Likewise, when you make a plan for your game, you may find that you're just not interested enough to spend three or more months on it. That's ok! Better to find out then rather than three months later. Keep working on other ideas until you find something your happy with that you know will be worth you time.

Again, there are no guarantees. It's difficult to accurately estimate how much time a project like a video game will take. And unexpected issues are always a possibility. Many people underestimate simply because there are so many details to account for, and accounting for all of them can be challenging. It's a skill that takes practice. And it is much, much better to have a plan than to shoot from the hip. Trust me. You'll find out sooner or later.

So plan accordingly, and spend the time saved on other wholesome activities like spending time with friends and family, going to the movies, or even exercise (you know that thing where you move parts of your body and it supposedly makes you look and feel better).

Larry the Dinosaur 2: Behind the Scenes

2011-12-25T12:00:00.000-07:00

After my last post about the happenings after Larry the Dinosaur 2 was released, I realized that I didn't say much about the development of the game. I will now.

The first attempt at Larry the Dinosaur 2 never made it past a playable demo. But it was distributed online. It was awesome.

Everyone liked it, so what happened? I don't remember. I can only guess that it suffered the fate of many playable demos that were never completed as full games, that fate being this: the demo is only the beginning, to complete it is a full-time job. It's easy to slap together a rather-promising playable demo over a night or two. And it's easy to fool yourself into believing that you can expand upon it just as easily and, with a just little more effort, finish a work of pure awesomeness.

But the truth is--if it only took you a day to make a playable demo--it's probably running on top of some code you ordered through the drive-thru. This is not always the case, but it was for me.

Maybe it seemed like to much work to complete it. Maybe the code was such a mess that I couldn't expand upon it without a zillion bugs coming out of the woodwork. But somehow, the game vanished, people were let down, and so was I.

Then the summer came. Sunny skies and warm weather. Maybe it was too warm and it cooked my brain, but I thought that making a prequel to Larry the Dinosaur would be awesome! I'd call it, Larry the Dinosaur: Zero (original, right?). This would have pixel-by-pixel scrolling whereas the last attempt had only static screen-by-screen progression like Larry the Dinosaur 1.

I charged at it as furiously as I had the last. And it was awesome. I had a playable first level. It was plush and green. It had animating waterfalls and pixel-by-pixel scrolling. It even had a boss at the end of the level you had to defeat; it looked like a giant mutated mosquito and it flew across the screen as it dropped slimy spit balls that Larry had to dodge.

Well, you might ask, what happened to that one. It got erased!!! Yes. I didn't back it up regularly. I was heart-broken...and also pissed at Linux for erasing my hard drive when I just meant to install it on another partition.

Whatever. It was my fault; it's never a wise idea to keep only one copy of your code. I did think about backing it up, just in case, but I ignored my brain and let stupid take over.

So that brought me to my third attempt at another follow-up to Larry the Dinosaur 1. I had an idea and spent all night developing a...wait for it...playable demo; didn't I mention something about those earlier? Anyway, it had pixel-by-pixel scrolling and I think you could run around and shoot at things.

So how did this one make it to the finish? It didn't. At the time, "complete" meant to me a game that takes hours for the player to complete, not just 15 minutes, and the game seemed stretched thin even at that length. So I bought some wrapping paper and a bow and released it online under the guise that it was "complete." Though, there was no "real" plan, so technically it was complete at any time I wanted it to be.

Ok, so if I didn't finish it, how did I make it past a playable demo? Well, for starters, I had some practice: it's much easier to do something over once you've done it before. I already made some programs that had playable characters running around shooting at things, those were known as the last two attempts, so getting up to speed was easy. And I also wrote better code. The code was still bad, but a bit better than what I had done before.

I didn't know what I was doing (not that I ever do). The game could have failed just as easily as the other two. I just started coding-a-blazing.

It started the same as the other too. So why did I this one make it to the finish line? Did I just get lucky? Maybe. Or maybe I was just smart enough this time to not start over and to backup the game.

Actually, now that I think about it, those are the two major mistakes I made that contributed to the games not being completed.

It makes sense, doesn't it? I assume I cancelled the first demo because I lost interest or because I was tempted to start over and "make something better." I put that in quotes because I think, if I finished the first demo, it would have been just as good in its own way. It's all to easy to fool yourself into thinking that you should just scrap everything and start over because you dream bigger, or possibly because you received some negative feedback from someone. Don't do it! Finish it, even if you cut corners, and you'll be happy that you did.

The second time I failed to properly backup my code. I'm sure I had some copies on my computer. But I lost everything on my computer! So always backup your code to removable storage or to the internet. Better yet, learn source control!

So I take that back. I don't think it's a bad thing to start from a playable demo. After all, that could be the spark that ignites your drive to finish the game. Don't worry too much if your code is messy, you can always clean up afterwards.

Larry the Dinosaur 2: Nine Years Later

2011-10-31T16:00:00.008-06:00

It was Halloween evening, October 31st, 2002. A game I had been working on since the summer was almost finished. I wanted to released on this day, for some odd reason. Honestly, it still needed a ton of work; it had many bugs, and it had some poor design issues that needed to be addressed. But at the time, my programming skills weren't too great and I had enough of the project. I played through the game several times that night, fixing up what I could, and then I submitted it to various sites. The game was Larry the Dinosaur 2.


The title screen.

It received fairly good feedback from the then Qbasic community. Amongst other 2d platform games developed in Qbasic, Larry the Dinosaur 2 held up well. It mixed action and puzzle elements and had a progressive story line that rewarded you with cut-scenes at certain points throughout the game. You could pick up and drop items; mixed items with other items (shotgun shells mix with the shotgun to increase your ammo supply, for example). You could fight enemies with your fist, pistol, shotgun, machine-gun, or desert eagle. There were non-playable characters that served the narrative. There was a villain, a friend, and a could-have-been-worse script.


The story is revealed through in-game dialogue.

Outside the world of Qbasic the game received positive feedback as well. It was posted on the front page on freedownloadscenter.com (http://www.freedownloadscenter.com/Reviews/r912.html). Somehow my game fell into the hands of someone there and it hit all the right notes with him (or her), and so he gave it a pleasant review. It was really a surprise to find my game on the front page of a non-programming related website.

In addition to the online review, I was contacted by a representative of a German game magazine, who wanted to publish a blurb about in their next issue. I don't remember what it was named, but I couldn't find the magazine online. I had to sign a disclosure agreement, so that makes it true right? Well, maybe. I don't think anyone would waste their time if it wasn't real, so probably. If I ever find it I'll have to post about it.


The weapons locker.

I also had another representative call me, but this guy was trying to promote an anti-spyware program and wanted me to place an ad. Here's how it worked: when anyone clicked on the link to download the game, it would first direct them to an offer page, giving them the chance to buy the anti-spyware program, or to continue and download the game. A bit annoying if you are just trying to download the game. However, if anyone bought the anti-spyware program I'd get like half the profit. The ad page tracked stats and I was able to see just how many downloads my game was getting. Heh, it was actually what made me decide to stop the ad placement and just go back to a direct download. I got about (or over) 3,000 hits. Holy shit! But...the stats showed how many people made it to the ad page versus how many people continued on to download the game versus how many people bought the anti-spyware program. About a third of the people who made it to the ad page gave up and didn't download the game. So yeah, 2,000 downloads is still a lot. But man, I lost a thousand downloads! The good news is that one--yes, just one--individual out there (out of the 3,000) bought the anti-spyware program. I received a check in the mail for eleven and something dollars; I should have framed it, heh. My brother joked at how that meant that it averaged to about fractions-of-a-cent per hour of the time I spent making the game. Whatever, that was an exciting time. At least I made something! And after seeing those stats, it just wasn't worth it, I wanted more people to download my game! So I removed the ad-placement and just made it a direct download again.

There are a total of 24 areas to explore, all accessible through the elevator. If I did this again, I would have locked most of the floors at the start, only allowing you to access them via key cards you collect as you progress throughout the game; you'd be introduced to new places progressively instead of all at once and having that confusion of "where the hell do I start?"

Unfortunately, the game download was hosted on a server of a shotty ISP. Back then I was using dial-up. The terms of the contract stated that if I went over 90 hours (or some number) per month, my account would be deactivated and I'd have to call in to reactivate it; this means downtime--no one can download the game when my account is deactivated. The downtime wasn't the bad part. The bad part was that they wouldn't just reactivate my account; they have to create an new one with a new user name, each time! Part of the URL to download the game had my user account name as part of it. The original download link, when my user name was joeking1, was http://users.sisna.com/joeking1/deltacode/downloads/dos/ld2v10.zip. So the first time we went over the hours and my account was deactivated, the download link became invalid. I could reactivate my account but those bastards wouldn't give me my old user name back, so the new download link was http://users.sisna.com/joeking2/deltacode/downloads/dos/ld2v10.zip. Only the user name changed, joeking1 to joeking2, but that's all it took to kill the traffic my game was getting. Then the user name changes went on and on, to joeking3 and so on each time we went over the limit. I couldn't control my brother's activity--yes, I blame him!


Halfway through the game you meet this nasty guy.

If only the ISP was the issue; but no, no matter how many times I contacted freedownloadscenter.com to update the link to the new one, they wouldn't do it. Instead they just posted the text from my email on a new page of their site. Who does that? (it's still up: http://www.freedownloadscenter.com/Games/3D_Action_Games/Larry_The_Dinosaur_2.html)

So the awesome downloading spree was over. No one could download my game from there anymore. The excitement was short-lived. Another drawback about this whole experience is the compatibility of the game. You could run it on Windows 98 and only Windows 98. It was a DOS game at its core, but the sound drivers were written for Windows, so you needed a Windows 9x system to run the game; you couldn't just run it in DOS alone. If you had Windows XP, you could run it, but without the sound. I've tried on Vista and 7 and I can't get it to run at all. And DOS emulators don't work because of what I said about the sound drivers (though you can still play it without the sound). It's like a catch-22. And Windows 98 was already an obsolete system by the time it was released anyway, so the game didn't have much of a life span.


You can view a detailed description of each item you collect.

Though some few years later it came back into the spotlight for a brief moment and received an in-depth review on Qbasic Express (http://www.petesqbsite.com/sections/express/issue9/index.html#larry2). It was much appreciated. :)


The final boss. Look out, Larry!

Every once and a while I'd google the game and find some discussion of it pop up hear and there. Nothing substantial, but any talk about it made my day. Even with all its issues, it was still well-made enough that quite a many people were able to enjoy. So happy 9th anniversary, Larry the Dinosaur 2! You will live on in my mind as a glowing achievement of someone who had way too much time on his hands.

You can still download the game of course! I'm not hosting it; however, you can find it on any of these pages (or just do a Google search):

A special thank you goes out to all who are hosting a download of the game on their site.


Definitely NOT Larry the Dinosaur 2.

Hold on one second! What about Larry the Dinosaur 1 or the uncompleted Larry the Dinosaur 3? Good question! Those are each a story of their own. I'll post about them soon. Until then...


The end.

Game design ain't everything

2011-10-08T22:00:00.000-06:00

I've done a lot of talk lately about planning and design. It is an important step in the game development process; but if you struggle with this part of the process, don't let it become an obstruction. It's meant to help, not to get in the way. Like all things, it takes practice. You do your best with what you can and then you move on. You may not have the greatest design, but at the very least you have a clearer picture of the game you are trying to develop. So whenever you are ready, move on to the next step and have fun! That's what it's all about, right?

Game design on one piece of paper

2011-10-01T11:19:00.000-06:00

Can you fit your game idea onto one 8.5x11 piece of paper? I think you should be able to show a good idea of the game with many of its core concepts, from the story to gameplay mechanics to concept art and even some mockups. A stranger should be able to understand your vision of the game by only looking at this piece of paper. Is your game idea strong enough for that? Does it have enough solid ideas and a unified, focused theme? Does it have enough content to go beyond a simple one or two-level demo? If it doesn't meet all of these points, then would it be wise to start coding the game until you do?

When you get down to it, making a game takes a lot of time. Brainstorming ideas of paper takes virtually no time in comparison. It's fun to jump in and start coding something, but having a good idea of what you want to see at the end will save you countless amounts of hours from redesigns of code, graphics, levels, and sound.

The rule of thumb is that the more time you spend designing your game, and the more complete that design is, the more smooth the game development process will go. You realize problems with your design early on; and when you catch them in the design phase, all you need to do is cross them out, so to speak. It doesn't take a massive overhaul of the code, depending on how complex the problem is to fix.

Something I run into when designing is that I realize how incomplete my game is. It challenges me to think about content and ideas to keep the game interesting through to the end. Sometimes I realize that I don't like my idea or the direction I'm taking with the game, so I stop there, and it only took a couple hours of my time as opposed to hundreds of hours developing the game to the point where I realize the same problem.

It does take practice. If you're used to jumping in with both feet and coding your way along, learning to think about the game in the design process can be frustrating. You don't "see" your game in action, but only what's on the paper. However, every problem you encounter along the design process you'd encounter in the implementation (coding) process anyway. Designing your game beforehand allows you to tackle all these problems head-on and sort them out beforehand so you have a less frustrating (and more fun) time implementing your game, and a much better chance of following through to the end and releasing a quality game.

Don't focus on the details

2011-07-20T21:10:00.000-06:00

One of my biggest mistakes when it comes to video game development is spending too much...I mean way too much...time on the details. I have this problem. From the start I spend more hours tweaking things like graphics and sound way before there is anything resembling a game. And when I do have something resembling a game, such as a simple one-level demo, I spend even more time messing around with minute details than on moving the game forward.

Everything has to be perfect before I can move forward. The problem with this is if I want to change something down the road; hours of work gets thrown away with more hours of work required for the changes. An example may be redrawing an entire tile set because I decided to go with a jungle level instead of a desert one. Another example would be continually redesigning levels as the game evolves. These all take time and lots of it.

The most effective way to save time is to layout your entire game in advance, and then fill in the details after the core functionality is completed. This pattern not only applies to video games, but to other creative practices as well. Take drawing for example; many great artists will sketch out an outline of their drawing first, then draw the shapes, and finally -- when everything is how they want -- fill in the details. The same logic applies: if I being a drawing by working out the details of every square inch, and if I want to change something halfway through, it's going to take a lot of eraser and time to fix (not to mention the time wasted by all the work that was just erased). This approach just isn't effective anywhere.

So if you're still the perfectionist, then be perfect with the planning and design. Don't move forward with the details until you are happy with your design. Then don't move forward with the details until you have built a robust framework that can support your design. Then once that is all done, don't yet focus on the details until you've built most of the game; use temporary or placeholder graphics and music (they aren't important at this stage; what's important is finishing the game). Then finally, when all there is to do is fill in the details and to polish your game, you can have at it and be rewarded with an actual game when you are done (and not a game still in the making).

These are just guidelines though. "Easier said than done," you might think. I agree. For me, it's a goal and not an actual practice -- a skill to improve upon. What's fun about game development is, well, developing a game and not having to worry about the less-entertaining work of documentation and low-level coding. Though, sometimes documentation and low-level coding can be fun for geeks like myself. But seeing your game in action as you craft it is an addiction.

No code is clean code

2011-07-14T07:15:00.000-06:00

Think about it. The less code you can write the better. And I don't mean by cramming lines of code together or shortening variable names; I mean things like consolidating repetitive code into functions, separating game logic and presentation code from the rest of the program into data files (like XML), and being clever with your code like being clever with words on Twitter (keeping it short, simple and to the point).

Cap your time

2011-07-12T13:00:00.006-06:00

Here's an idea. Break your project into phases. The first phase is something playable with a couple levels; the second phase adds a bit more and has all the levels, story, bosses, and music implemented; and the third phase is for polishing your game and filling in the gaps.

Now break each phase down into hourly estimates of categories. For instance: planning and design, programming, artwork, level design, music and sound. Here's an example for a small game:

Phase I
Planning and design: 2 hours
Programming: 15 hours
Artwork: 10 hours
Level Design: 10 hours
Music and sound: 10 hours

Phase II
Planning and design: 3 hours
Programming: 30 hours
Artwork: 20 hours
Level Design: 30 hours
Music and sound: 15 hours

Phase III
Planning and design: n/a
Programming/bug-fixes: 10 hours
Artwork touch-up: 5 hours
Level Design fixes/changes: 10 hours
Music and sound touch-up: 5 hours

175 hours! Initially I was thinking it'd end up around 50 hours, but breaking it up into phases showed me that I greatly underestimated that. And when I estimate my hours I like to overestimate, because things aren't going to go as smooth as you think they will half the time. Breaking your game up into phases does 2 things: first, you focus on reaching the end of the phase and not the end of the game's development (so you're less likely to be caught up with feature creep and the like), second your hours are better estimated because you are estimating hours with more concrete markers than just "finishing the game."

Here's the second part of my idea: DO NOT GO OVER YOUR HOURS!!!

Why? Because if you go over the when will it end? Ideas and the quest for perfection always get me spending more time on little details than I should. Also, you if keep to your word, when the time gets close and you're not quite there you will have to finish up with what you have, even if that means putting in plain (placeholder) graphics and just the raw bones of your code. The goal is to reach the end of the phase, not to complete the game. And once you reach the end of the phase, you can assess where you are at and where you want to go and plan your next phase. This type of planning/execution/planning pattern is used in commercial software companies in one form or another; some examples are Scrum and Agile development. There's power in this strategy as it keeps you focused on more realistic (and closer) goals. It also allows for changes to be made if needed (re-planning a phase, for example).

A programming language is not a game development framework

2011-07-11T23:37:00.000-06:00

I think many people fall into this trap. You have an idea for a game, so you start coding. Everything goes well at first and by next week you have an awesome demo to showcase your upcoming game: your player can do some awesome moves, the graphics are slick, and it all looks promising. But then...months go by and progress has sharply declined. Sometimes there is nothing more to show. What happened?

From the programming side of things, the game starts to collapse under its own weight -- the code structure that supported the demo cannot handle the complexity of a complete game; and building upon such a flaky framework leads to mounds of spaghetti and buggy code.

There are many assumptions, but I believe the core issue is that the programmer relies too much on features of the programming language rather than a well thought-out and planned framework to support the game. What does this mean? I'll explain.

The idea of a game framework (sometimes referred to as a game engine) is to have you only writing code that deals with the game logic, fun stuff like: weapon properties, special moves, power-ups, level dynamics, etc. That's all you need to define your game anyway, and you send that game data to the framework (or game engine). The framework is the inner-workings of the game. It consists of helpful methods (subroutines or functions) that load levels, organize and render graphics, calculate objects on the map, churn the physics for each frame, and so on. It's important to keep the framework separate from the game logic by providing an interface. The interface is a set of methods that you use to send the data the framework needs to run a game and nothing more. One example is a method that accepts a file name of a map to load for the current level. Another example is a method that accepts properties for an object and then creates and adds that object to the map (like for a demon that throws fire you'd pass its strength, speed, skill, etc.); the framework would then be responsible for rendering and moving the demon under the rules you provided (through another method). The idea is that the game logic is separate from the lower-level logic that the game is running on top of; and you communicate with the framework via its interface. When people try to code these two parts together...well...it gets messy.

A suitable framework for your game should be developed first or in phases as the game progresses. If you are not sure how to go about it then you can look at some examples. Old-school games like Quake have their source code available. Use of frameworks apply to web design as well, so if you understand web development check out the source code for frameworks like Wordpress or Magento. If you want to save yourself the time of writing your own framework, and you want to jump right into game development, then a quick search of Google for "game development frameworks" will give you more than plenty to chew on.

Back from hiatus

2011-07-11T12:15:00.003-06:00

A good amount of time has passed; life happens...you know. Even so, I could have kept up on this blog. There is nothing new gaming wise. There are a lot of days where I am irked by the fact that I haven't release anything...not even a simple game...since 2007. What's the big deal? Why is it so hard to finish something today? Blah blah blah, whatever.

Anyway, I'm back and am going to give this blog another shot. Weekly postings about...I don't know...stuff. Good strategies for game development may be the focus for a while. I'm not writing another line of code until I have my next game on paper! Seriously, like a solid plan that'll get something done, and soon.

A Sense of Progression: Keeping your game interesting

2010-01-05T22:05:00.000-07:00

Keeping a strong sense of progression really adds to gameplay. If you're not careful, your game could become just one boring level after another. A sense of progression is a way of rewarding the player as he or she progresses along the game. You might think that you need to overhaul your game or add tons of code to have a nice set of rewards, but so isn't the case! I will present some simple, easy-to-implement rewards that add much depth to a game:

Different tile sets:
Levels that look and feel different from one another will keep them interesting. Even simple things such as changing the colors around or making one tile-set more worn-looking than another add to the feel of the level.

Spreading out enemies:
If you have a handful of enemies in your game, don't throw them all into the first level. Save some of them so they can be introduced in later levels. So, for example, level 2 won't just be known as just "level 2," but rather the level that introduces that scary monster!

Spreading out weapons:
Same as above, but with weapons.

Secret areas:
It's a nice feeling when you stumble upon a secret area in a level. Hide some in your levels and stuff them with goodies to reward your player when he or she finds it.

Story:
I'm not talking about adding complicated dialog or cut-scenes. Think about this example for instance: level 1 is a forest, level 2 is a castle, level 3 is a dungeon, level 4 is a lava cave where you fight the evil demon. That scenario has a type of storyline progression to it; each level leads to the next. It indirectly tells of a hero venturing through the forest to find the castle that leads to the evil demon that he or she must annihilate. Try to think of a scenario more original or creative.

Conclusion:
So you see, you can add much depth to your game already using what you already have. These are just some of the basic ways implemented in most games. Try to think up other ideas than what I presented here to make your levels more interesting and to add a sense of progression.

Site is Down

2009-12-11T08:55:00.000-07:00

The Delta Code site has been down for a couple months. I am aware of it; I've just been lazy.

I'll see if I can get it back up and running sometime this month.

I don't wanna grow up!

2009-10-19T17:00:00.002-06:00

Between work, school and life, I don't know how I manage to get anything done. Actually, I haven't really done much this year at all. That seems to be the trend for many people: they get older--grow up or whatever--and move on from their childish game projects. Not that I have been trying to, but it would be nice. I'm tired of starting so many things that I don't finish. Maybe I could move on to a hobby that's more social. But I still want to finish some of my projects I started years ago--it's hard to let go. So I continue on with my childish projects with hope that one day in the future they may be completed. Then I can put them to rest and feel proud of myself that I have what it takes to finish those type of projects.

Keeping up-to-date with the world

2009-09-01T17:00:00.001-06:00

FreeBasic is fun, but I want a career in IT, so spending all my time working on FB projects doesn't help much in that area.

Still, I want to contribute to FreeBasic with my own projects, but every once in a while I need to do something with what the industry uses. I also need to keep my memory fresh with courses that I took in school on C#, Java, databases, etc. You easily forget that if you don't use it.

Thankfully Microsoft has free versions of Visual Studio, the Express editions, for hobbyists such as myself. I downloaded C# and C++ and plan to work on projects with those. I'm also interested in the game library they have for C++, The Game Creators GDK. I need to work up a portfolio, even if it's with simple demos, so that I can show that I have competency with these languages.

This doesn't mean Toadman 3 will be put on hold; I still have plenty of time for that. I just need to make the most out of my free time that isn't spent working on FreeBasic projects. Hopefully I don't burn out. Like how I stated in my previous article, Code Beyond Your Comfort Zone, I just need to spend a little time every once in a while to learn something new.

Should be fun.

First Screenshots of Toadman 3 (in development)!

2009-08-15T21:10:00.002-06:00

First screenshot of Toadman 3 very early in development. I decided heck to it with my sprite editor project and am using PixelPlus 256 for the graphics at the moment. The graphics are already turning out better than expected. You should see him hop; that's the coolest part. Unfortunately you'll have to wait until a demo comes out. For now I'll just tease you with screenshots.

Nothing too much to show off for now. These screenshots were taken on the 11th (4 days ago) ; the game has been worked on since then. I decided to take some early screenshots so I can look back on the development of the game. I'll post more screenshots in the future as the game progresses.

Site Changes

2009-08-10T17:00:00.002-06:00

I did quite a bit of work on the site this weekend. I changed the look and moved some things around. Overall, I think it looks much better.

I plan to update the site 2-3 times per month. An update will be an article, tutorial, or game review. I want new, fresh content on the site. I don't like to see all those old articles and reviews decaying the site.

Updates also include articles that are posted to the blog (postings that are tagged 'article'). I usually post them around the same time. Maybe I'll stop posting articles here as you can get to them on the site.

So we'll see how that goes.

Code beyond your comfort zone

2009-08-07T19:00:00.000-06:00

When is the last time you learned something new about programming? Was it a day, week or month ago? Has it been longer than that? If it has been longer than a month, then make yourself a goal to learn at least one new thing before the end of next month.

Take advantage of your time. Before you know it, a year may pass and you'll be no wiser if you didn't set aside any time to learn. You can't get that time back.

You don't have to set aside much time for growing your programming skills. No matter how busy your life is, you should be able to find some time, perhaps just 15 minutes each week. An hour each month is better than nothing. The more time the better, but don't burn yourself out.

Spend that time to learn something new or to program something difficult. I'm not asking you to start a project. Just work on a demonstration. Your code doesn't have to be pretty. The point is to learn something, not to make something.

It can be about anything you want, perhaps some new GFX algorithms for your next demo or part of a game engine for your next game.

You might not get your program working, but that's good! It means you are out of your comfort zone. This is where learning takes place. Maybe you can try it again next time, or perhaps you feel you've learned enough from the previous experience. You be the judge.

Some examples of the top of my head are:

use a file format you haven't before (such as BMP, WAV or MP3)
learn a new language (perhaps a simple tutorial or two, don't overwork yourself)
read an article on networking
touch up on 2D and 3D math (one small bite at a time of course)
learn a new tool such as a graphics editor or an API
refresh on programming concepts you've learned before but haven't used for a while
...

And the list goes on. Use your imagination. The point is to learn something new and push yourself beyond your limits comfort zone. Don't push yourself too hard. You don't want to dread each session. You should have fun with it. There's a difference between a challenge and frustrating yourself.

The Delay Factor

2009-07-30T17:00:00.000-06:00

One of the major difficulties in game development is to make your game playable on as many computers as possible, and on as many newer (and possibly older) computers as possible. Games written today need to be programmed to run at the same speed on all PCs. If not, then your game may be unplayable for someone else, ruining their experience.

This is what I call the delay factor: a variable that changes relative to the speed of the computer, to which you base all your time-dependent functions on, such as movement and animation.

Perhaps you can remember playing an old game on a new PC, only to find that you can't play it because it runs too fast. Chances are they didn't program speed control into their game, or they used a hack-method that worked at the time but doesn't work today.

I will start off by telling you what NOT to do. I have made a lot of these mistakes before, and because of that I can't run many of my older games; I have to edit the source code to slow things down, or it's just too much work and I give up.

The WRONG Way

The worst thing you can do is something similar this:

DIM n AS INTEGER
FOR n = 0 TO 500000: NEXT n

This may solve the problem on your computer, and some speed control is better than no speed control. But if you want to share your game, or look back on it in the future, you need something better.

There are a number of ways to approach this issue. You could count how many times a loop runs within one second and use that as your delay factor, or you can make the loop count (500000) a variable and make the user adjust it him/herself. But these are poor methods and will likely frustrate other people, and they'll never truly know what speed you meant the game to be played at.

Another way is to utilize the vertical retrace. The vertical retrace waits for the monitor to refresh. Most monitors refresh at 60hz, or 60 times a second. So programming the speed of your game around this is a more viable option. Today, most computers will probably run your game, but some monitors refresh at 70hz or 75hz. In the future monitors may refresh at 120hz.

The RIGHT Way

The best solution, as far as I know, is to track how much time goes by between one cycle of your main game loop and use that time as the delay factor.

Of course with this way, the faster the computer, the shorter time and thus delay factor. So you can't throw the delay factor into a for loop unless you invert it, but a better way is described below.

Multiply all of your movements, animations, and other time-dependent objects by the delay factor. Don't code any stupid empty loops to slow things down. This way, if your game runs at a quadrillion cycles per second, the delay factor will compensate and everything will run at the same speed.

Another advantage of this method is that slower PCs will run your game also. If you're coding your game on a PC that runs it at 60fps, a PC that can only run it a 30fps will compensate by moving things twice as fast.

You still should test your game on both slower and faster computers as you're making it. Chances are you won't have everything running perfect the first time. Sometimes I make the mistake of slipping in an absolute value without multiplying it by the delay factor, and testing it on other computers is a way to catch that.

Use FreeBasic's TIMER command to do this. First you take the time before executing your game loop. Then once the cycle is complete, call TIMER again to get the new time. Subtract the old time from the new time to get the cycle time.

Example Code

I made a module below that you can use if you don't feel like coding your own.
Save this as DELAY.BAS. Include it in your game, then just call UpdateSpeed() after each cycle. It will return the time between the first time you called it and the second time. You can also call GetDelay() to get the delay factor again without recalculating it.

Keep in mind that you should call it at least once before your main game loop to initialize it. It will return the value of TIMER the first time it's called (which is usually a big number). A good way is to render a couple frames of your game first to get the speed before performing calculations that depend on the delay factor. The rendering process is usually the most processor intensive, so it'll give a fairly accurate time.


DECLARE FUNCTION UpdateSpeed () AS DOUBLE
DECLARE FUNCTION GetDelay () AS DOUBLE

DIM SHARED DelayDelay AS DOUBLE '- odd spelling as to not conflict with other variables in your code

'- Calculate the global delay factor
FUNCTION UpdateSpeed () AS DOUBLE

  DIM speed AS DOUBLE
  STATIC timex AS DOUBLE = 0.0f

  speed = TIMER-timex
  timex = TIMER

  DelayDelay = speed

  RETURN speed

END FUNCTION

'- Return the delay factor
FUNCTION GetDelay () AS DOUBLE

  RETURN DelayDelay

END FUNCTION

Fail!

2009-07-27T17:00:00.006-06:00

It's now the last week of July. Where's Toadman 3 or that sprite editor I was talking about earlier? They haven't come very far. I typed up some ideas, but Toadman 3 hasn't picked up any momentum. The sprite editor was moving along well, but development on it stopped a while back.

Stuff happens, I guess. It just seems harder nowadays to finish something, or even start something for that matter.

It makes me ponder what has changed since the days when I was really active and coded a number of projects in a small amount of time. Between 2000 and 2002, I finished six games: Toadman, Toadman 2, Unofficial Tournament, Torched Earth, Larry the Dinosaur, and Larry the Dinosaur 2. However, between then and now, nothing, except for a little ascii game I released back in 2007.

So, what's happened? I work and go to school, and sometimes that wears me out, but I'm still a single man with plenty of free time. Maybe I try to make projects that are too big in scale, and I need to cut back and make simpler games.

There's some truth to that. Whenever I finished a game in the past, I felt that I needed to top it in the next game. When I finished Larry the Dinosaur 2, I was pumped up for the sequel. It was going to be in C++, have better graphics, larger levels, faster gameplay. It would put #2 to shame.

Well, I made it pretty far on the sequel, but I bit off a little more than I could chew on that one.

So maybe I need to take a step back. Start with simple games again, original games instead of sequels, so I don't feel the need to top the previous game in the series. I am only one man after all.

Cool Transparency Formula

2009-06-15T17:00:00.000-06:00

While I was thinking through a way to implement transparency in my graphics engine, I thought up a cool and fast way to render pixels at 50% transparency:

BASIC:
col0 = col0 SHR 1
col1 = col1 SHR 1
col0 = (col0 AND &h007F7F7F)
col1 = (col1 AND &h007F7F7F)
newcol = col0 + col1

C:
col0 >>= 1;
col1 >>= 1;
col0 = col0 & 0x007F7F7F;
col1 = col1 & 0x007F7F7F;
newcol = col0 + col1;

ASM:
mov eax, [col1]
mov ebx, [col2]
shr eax, 1
shr ebx, 1
and eax, 0x007F7F7F
and ebx, 0x007F7F7F
add eax, ebx
mov [newcol], eax

All these examples do is take the average of the two RGB values by using bit shifts and bit logic. Instead of adding by two and then dividing, it divides by two (shift right one) and adds them together. But before it adds the values together, it chops off the bits that may have bled over into the other bytes using the AND operator.

0x7F7F7F is 011111110111111101111111 in binary.

DOS is dead, so is 320x200

2009-06-01T18:00:00.000-06:00

DOS may live on amongst a community of zombies who were once among the living in the 80s and early 90s, but for those of us who don't crave the taste of human brains, we've moved on.

One thing that didn't really need to die, but has anyway with the new graphics cards, is the 320x200 and 320x240 resolutions. Other resolutions smaller than 640x480 may be in danger too.

It was some years ago that I noticed, while working on a game of mine, that 320x240 looked fuzzy, blurry, and just not as sharp as it used to be. My game looked fine on older computers, but not on mine. And I've noticed this on other newer computers also.

My theory is that the graphics cards are using OpenGL or Direct3D to render a 320x240 texture on a slightly higher resolution like 640x480. Because of this, filtering is applied to the texture, making it appear slightly blurry. However, that's just a theory, but you get the point.

The other issue is that some computers just flat out don't support resolutions under 640x480. One example of that is my laptop that I bought last year. It's an Acer, so that might explain it, but it still goes to show that the old resolutions are going the way of DOS.

But I'm not saying that anyone should stop making games and programs that run in 320x200 or 320x240 resolutions. But what I would like is if they made sure they had an option to run the game in 640x480, but with the graphics scaled onto the screen so that I can still play that game full screen and see it as sharp as it should be seen, so that I can play the game as it's meant to be played.

I'm not against new releases of retro-style games, I just want to be able to play them. :)

Obstacles

2009-04-30T21:40:00.000-06:00

Well, I was about to start on Toadman 3, but then I realized that I had no sprite editor to draw the graphics with. I used to use Pixel Plus 256, but it's a DOS program and my laptop won't run it, because either I have Vista or because my graphics card doesn't support 320X200 resolution. I can use DosBox, but that's just not convenient. I don't have Photoshop, and Gimp is a nightmare to work with.

Instead, I've been working on my own sprite editor in the mean time. Just something simple but good enough to get what I want done. Besides, I've always wanted to make a sprite editor, one that's customized my way. I hope to having it functioning well enough in a couple weeks so I can start using it.

Forum Back Online

2009-04-16T20:45:00.000-06:00

Delta Code's forum is back online. I added a simple CAPTCHA system for now. CAPTCHA is just some fancy acronym that basically means any test to fight off web bots. The test I added is a validation code. The code you enter must match the code displayed in the adjacent image before you can post to the forum.

We'll see how the system works. If it's not enough, then I'll have to make it more complex in the future.

Forum Under Attack

2009-04-09T17:00:00.000-06:00

Delta Code's forum has been spammed heavily lately, that's why it is currently down.

When I first made it, I didn't add many spam defenses since, let's face it, Delta Code's not that popular of a site.

But the site has received a large boost in unique IP hits. The visitor counter has shot up from about 10 a day to about 1,000 a day. I highly doubt that these numbers are credible. Spam and spider bots are likely the culprit.

So until I patch up the forum's weak areas, it'll be down for the time being.

Time to Begin

2009-03-31T20:00:00.000-06:00

Well, I haven't progressed much on the documentation for Toadman 3, but I have an overall idea of what I want to make, somewhat. I'll begin graphics and coding for the next step. I won't have much of an idea of what I want for levels until I have most of the game engine complete. Hopefully this will move along gracefully.

Spring is here!

2009-03-20T20:30:00.000-06:00

No news for Toadman 3. It's that time of year when I have everything else on my mind, such as taxes and school, credit and bills, and I've also been moving to another apartment. Man, responsibility sucks. I hope to get all of that behind me within the next week so I have some energy. It's not that I don't have the time, it's just that when I get everything done for the day I want to get away from the computer.

The good news is that winter is finally over! It's that time of year when the cold weather goes away, and also that short time of the year before all the nasty insects come out to play...with your blood!

Toadman 3: The Scoop

2009-03-05T20:30:00.000-07:00

I haven't coded anything yet, but I've been working on a script for the game. Unlike the last two Toadman games, this one will have a single player story mode. I also plan to include the classic split-screen mode for two player battles.

The graphics will be kept simple. In fact, they'll look just like the last Toadman games, but with a bit more depth and floor tiles as well. There won't be a black vast of emptiness to represent the ground.

Single player mode will be puzzle-like with obstacles and enemies along the way. Simple cut-scenes will appear between levels to reward the player and progress the story.

I haven't thought the weapons through yet. I want to keep everything from the previous Toadman games at the very least. One addition will probably be weapon pickups or weapon swap points, where you drop your current weapon for a more powerful one. Actually, I think Toadman 2 had that feature, but just for the short-range weapons and not the guns. This will be for guns as well, so you'll have that added variety to the gameplay too.

There is more to come! I want to finish this game by May or June. I'll post news and screen shots as the project progresses, and maybe even a beta version for testing. Stay tuned!

Firebox It Up!

2009-02-20T22:00:00.000-07:00

This is a side-project of mine. I've always wanted a tile-editor I can use over for different projects. That's what this project is going to be. It's called Firebox. If you haven't guessed it already, the name is a play off of Firefox.

Most projects have very distinct level formats, so in the past I've had to build a new tile editor for each project that can support the complexities of the level format. Many games have more to their maps than just tiles. Things such as scripts, tags, and touch-plates add complexity to level maps. The goal of this project is to make a scalable tile editor that I can reuse for any number of projects.

I'm not quite sure yet how to make it support multiple projects. One idea I have is to make it very basic and flexible, so one can take the source and easily add modifications for his or her project rather than building a new one from the ground up.

Currently, Firebox supports multiple resolutions. You can load bitmap files or binary sprite files into the tile selector window. It also supports multiple map layers.

Much of the options are hard coded, like resolution and map size. In the future, I will create a menu to adjust these options, or at the very least load them in from a text file.

I've been using this for my 3D raycasting game and will be using it for Toadman 3. I need to make some adjustments to it. I made it a little to specialized for ORE, such as adding tags (the numbers on top of some of the tiles) that identify dynamic objects. So I'll need to run through my code and clean things up so I can also use it for Toadman 3 when the time comes.

Delta Code's New Home

2009-02-18T22:00:00.000-07:00

Delta Code is now located at http://www.deltacode.net. I've been waiting for this domain for some time. I wanted to buy it back in 2007, but one of those domain scalpers got to it before I did. I thought I lost my chance at it forever. I lucked out though, because it apparently expired and was up for grabs, so I purchased the domain.

YES!!!

A New Toadman Game

2009-02-17T21:21:00.000-07:00

I've decided on making another Toadman game. I've been planning some things out on paper. I want to keep things as simple as possible for the most part, and I don't want this project to be plagued with feature creep.

It may be as simplistic as Toadman 2 with 8x8 sprites, or I might do something a little different. A lot of it will depend on how good my drawing ability is and how much time I want to invest in graphics.

I'll post updates of the project as it moves along.

Project Upkeep

2009-01-29T18:00:00.000-07:00

We all do it, or have done it in the past. We work on a project, and as it grows bigger, it begins to look ugly. You have to remember where everything is and exactly how everything works. And if you leave your project for even a week and come back, you're lost in your own code and have to re-remember how it all works. Your project becomes a nightmare to work with.

This often comes with lack of planning, feature creep, or lazy coding. But for many of us hobby programmers, who like to just jump right into coding, how do we deal with these issues as our project grows bigger?

Every so often, I take the time to do the things that I've put off, such as adding comments and organizing my code. I'm not always in the mood to write clean code. But I make sure, before everything turns into spaghetti, that I take some time to clean things up.

Some days I don't feel like coding, but I still feel like getting something done. So instead of coding, I work on commenting my project. I'll add comments, or reword existing comments to make them understandable for my future self. I'll also spend the time to think about how I can make my code more organized, simplified, and structured. It doesn't take too long and it is time well spent.

Don't be discouraged into thinking that it's a waste of time. You'll be more productive working with cleaner code, and it makes it that much easier to come back to if you ever put your project on hold. And as your project grows larger, it'll be much easier to manage.

Also, try to break things down into simpler components and processes when things start to become large and complicated, but not before things becomes so large and complicated that it becomes a full-time job. It's similar to taking a few minutes to vacuum the living room every week as opposed to taking a whole day to clean living room every six months. Though, when it comes to coding, it could take days, weeks or months to clean up after six months of lazy coding. It might even be so discouraging that you decide it would just be easier to start the project over.

I've been able to come back to projects a year later and, without any problems, resume where I left off simply because I did this maintenance every once in a while. It's a great feeling knowing that all the time and effort you put into a past project wasn't in vain, so that you don't have to scrap your old project and start over.

Backup your code! Tips for avoiding catastrophe.

2009-01-26T11:40:00.000-07:00

There have been a number of times in the past where I've lost projects, code, and precious time to power-outages, computer crashes, stupid decisions, and other annoying miscellaneous phenomena. I'll provide some tips so you can have peace of mind in knowing that you always have a recent version of your code saved in the event that any of these things happen.

The first thing to get in the habit of is to always save your code. I almost always hit CTRL+S every time I enter a new line of code. If you're coding hours between saves then you need to get into the habit of saving more frequently. Even an hour's worth of coding is a bummer to lose.

If you're making changes to your code that you don't want to save, say if you're trying something new or debugging, backup your project folder so you can effortlessly go back to where you left off after wards, rather than manually undoing all your code changes.

Always make backups of your project. The more frequently the better. I'm pretty lazy when it comes to this, but when I reach a milestone or make some excellent progress, I'll copy my project folder, zip it, and save a copy on my hard-drive, on my web-server, and I'll email a copy to myself. You don't want your backups all in one place. Make sure that you have at least two places to store your backups, so in case one place dies, you still have your backups at another location.

Backup your project before going off on a tangent. If you want to try something that diverts your project in a different direction, like recoding the AI or experimenting with different physics, make sure you backup your project before proceeding. I've made the mistake of not doing this. I either didn't like the new feature or it made my project unstable. And I found it very difficult to revert back to where I was, or I just gave up on the project.

For example, I wanted to recode the enemy system for a game I was working on in the past. The enemy data was stored in an array, and I wanted to recode it all as a linked-list, to make it easy and efficient to add and delete enemies. After I did this, I had a whole slug of new bugs and I just wanted to go back to where I was before. Unfortunately, the last backup I had was of a very old version that I didn't want to go back to.

Last tip, but very important: make sure your backups can compile! It's no fun going back to a project that won't run. Maybe back when you made the backup you knew, but now you're stumped and have to spend hours figuring out how to get the damn thing to run. This also includes stripping out all the absolute paths in your code and replacing them with relative paths, so your project will run when it's in a different location. You want to do this work before you make the backup, when you know where everything is, rather than spending time after you've forgotten most of your code.

I've learned these lessons the hard way. Learn from my mistakes and hopefully your projects will be successful, or at least completed for that matter.

Path-Finding Woes

2009-01-23T20:03:00.000-07:00

I've been developing a path-finding module to use in my games. The idea is to place nodes on a map, add those nodes to the module, and interface with the module anytime I want to find the closest path between two nodes.

Nodes are just geometric points within my map that are placed strategically as to allow enemies to find their way around the map without running into walls. Instead of going off the raw map data, they use these nodes as guidelines to find their way around. This is much like finding your way around a maze blindfolded by following a rope that connects to other ropes. The ropes may break off into many paths, but one path on the rope leads to the end.

I coded a recursion algorithm to find all the possible paths between node A and node B. Then it would return the next node on the closest path to B (or A, depending which way you are going).

After I coded it, I tested it and it worked alright. So I added more nodes to my map and adjusted my algorithm a bit. Then it just froze my program whenever I called the path-finding code. I've been stumped on this for a couple weeks. I couldn't find anything wrong with my code!

Then I finally found the answer. Turns out that it's just way too slow to find all the possible paths, depending on how many nodes and possible paths there are.

I became suspicious of this and did a test. I ran my program and I walked away for a bit, made a sandwich, and came back. And when I returned, the algorithm had finished! It wasn't broken, just slow.

There are a few things I can do to remedy this. I just need to make sure that I keep my node count down and try to keep my paths as linear as possible, to reduce the number of total possible paths. That way it should keep up to speed. Or I can just try another approach to path-finding. We'll see.

Catloaf 5200: What happened to it?

2009-01-17T21:17:00.000-07:00

Screenshot from the unreleased Catloaf 5200.

Not too long ago, I announced that I was working on a sequel to Catloaf 2600 entitled, Catloaf 5200. I even put up a page to promote the game here with a release date of August 8, 2008. As you can see, that date as long since passed. So what happened?

Catloaf 2600 was a simple ascii game consisting of common, easy-to-program puzzles. The puzzles were ordinary obstacles such as unlocking doors, trap-avoidance, memorization, and Sokoban-style block pushing.

The game was a fun project. Why not make another? So I started on another, to be called Catloaf 5200. If you haven't figured it out yet, the numbering is a reference to the old Atari consoles of the 80s.

Though when I got into programming 5200, I hit a wall. I wanted to introduce fresh puzzles, so that 5200 would stand out on its own from its predecessor rather than being just an extension of it.

I came up with a couple ideas, but not enough to fill the map. So that's what halted the project. I guess I'll have to make some compromises to finish the game, but right now it's currently on hiatus until I get some inspiration.

Blew A Tire

2009-01-14T20:34:00.000-07:00

Today's Wednesday the 14th. Two days ago on Monday, I was driving on the freeway when I blew a tire, the passenger-rear tire. It was a somewhat new tire and still had much tread left on it. So I'm glad that I purchased the road-hazard warranty for it, and I got the new tire for free.

I never blew a tire before, so at first I thought there was an earthquake happening. Then I saw the smoke in the rear-view mirror. Unfortunately I was on my way to class and had some assignments due in an hour that I didn't yet turn it. So I pulled into a parking lot and jogged down to the nearest hotel. They were nice enough to let my use their wireless to turn in my assignments. Phew! Close call.

Tomorrow's my birthday!

2009-01-10T19:00:00.000-07:00

I turn 24 tomorrow, and what better way to celebrate my turning 24 than to watch the season premiere of...you guessed it, 24? Heck yes! Maybe I'll buy some cake too.

So what is the "big" project?

2009-01-09T19:57:00.000-07:00

It's a first-person shooter. It makes use of my 3D software renderer: an old school raycasting engine. Not raytracing, but raycasting. It's all semantics really, but technically there's a big difference between the two. Raycasting casts rays on a 2D plane, whereas raytracing casts thousands of more rays on a 3D plane. Raycasting is like a stripped down version of raytracing, giving it a major speed boost, but the downside is that the world is only 2D but tricked to make it look as those you're in a 3D world (you can't truly look up or down). Old games like Wolfenstein 3D used this technique.

So you might be asking yourself, "Why is this looney using an outdated style of graphics rendering?" Well, I could spend my time on a true 3D polygon rendering engine, but I was amazed by raycasters when I first read about them and saw some demos. I've always wanted to make a game using something like this. So far I've yet to make one. So really I'm just trying to finish something I started many years ago when I began researching this technology.

Here's another screenshot from the game. Here I am shooting plasma balls at a goblin-like creature.

This raycasting engine supports 24bit true color mode, textured walls and floors, animation, sprites, semi-transparency, and some other cool stuff. Everything, from the game to the engine, is being programmed in FreeBasic.

I am programming and organizing this engine to be easy to use so anyone can download it and use it for their game if they wish.

Game Programming, What's next for me?

2009-01-08T21:11:00.000-07:00

It's been over a year since I finished a game. I've been working on something new on and off for a bit now. It's a big project, so I might take a break from it to take a month or two to make something simple. That way I can add something to my catalog for 2009.

Some ideas on the list:
Another sequel to the Toadman series.
A sequel to Catloaf 2600.
Something new and original.

Either way, I have to clean up the code on my current project so I can come back to it without feeling lost.