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!
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
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.
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)!
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
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.
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
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:
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
- ...
The Delay Factor
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.
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!
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.
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
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.
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
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. :)
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
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.
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
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.
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
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.
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
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!
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!
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
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!
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!
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
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!!!
YES!!!
A New Toadman Game
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.
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
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.
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.
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.
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
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.
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?
Screenshot from the unreleased Catloaf 5200.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
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.
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!
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?
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?
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.
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.
Subscribe to:
Posts (Atom)