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.
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)