I am so restless lately in my programming. You'd think 8 hours a day of it at work, 5 days a week, would turn me off on doing the same thing in my spare time. But no, it doesn't. Instead, I've become enthusiastic from the things I've learned at work, and when I go home I try to apply them to my projects. The problem is, there isn't just one project on the table.
I received requests to finish Bwock, a puzzle-pusher game in the style of Adventures of Lolo. I really, really need to get that done. But something else has also nabbed my attention, folks - something much bigger. Something that could potentially get my name OUT there, and get vasilisagames.com some serious hits. I wish I wasn't doing it alone, but if it works then I may not have to in the future.
I'll say a few things. It's going to be open source, Java, and similar in some ways to a popular project called "Inform". It's for interactive fiction, but it's so flexible that even I'm not sure what it's limits are yet, and I only have the basic engine partially done. I've had to create my own scripting language for the thing, which was some of the best fun I've had behind a keyboard. I think people will like the simplicity of it.
I'm debating the license for it, but currently it's documented as MIT, which means it's ultra free. This could potentially mean a big company can modify it into their own program and sell it, but they couldn't stop anyone else from doing the same thing. I might switch the core to LGPL, if I can make it work with java correctly, and let interfaces be MIT so that the project itself can't just be yanked out from under me. I'm still thinking.
I'm not a huge fan of java, but it's really great for open source. Every platform can run the exact same file, it generates beautiful javadocs, etc. Besides, this is not a process-heavy program - no heavy math, no polygons, no massive data trees. Its just text parsing... with a twist ;)
And now lunch is over, so I'm getting back to work. Fare thee well.
Friday, March 6, 2009
Friday, February 20, 2009
Mmm minty
I want to come on here and sing praises for something known as Linux Mint. I've been a user of the Ubuntu flavor for quite a while now ( a few years, to be sure. ) I've come to favor Kubuntu, but I was disenchanted with Intrepid Ibex because it basically undid everything I had found convenient about the previous versions. Well, KDE did anyway. I backtracked to Hardy Heron and was there for a little while, but then I got a new, powerhouse machine with an XP partition for my gaming. So I decided to start over and look for a new flavor to try.
There must be a different version of linux per user of the actual operating system, because hunting one down is not easy. I realized what I wanted was something that was ready for me, from the instant I installed it. I love the Debian approach to repositories, but their GPL-only ethos is a pain. For example, who ISNT going to install mp3 support? Seriously, now. I wanted that hot-and-ready feeling you get from Windows, except without the eventual meltdown. This brought me to look at linux mint.
Mint offered what I was looking for, but they did better than that. Their system is based off Ubuntu directly. That means that I am instantly comfortable in the new environment, because I know it. There are some new things to look at, but nothing is missing. And everything just works, even wireless detection - which usually sucks in linux. I seriously think I could give this OS to my mom and she'd get cozy in just a few minutes. It uses gnome, but the mint desktop is configured to have a sort of KDE feel to it in a lot of ways. As you might expect, everything's really green, including the many wallpapers you get by default. I think the offset of green and black/grey they use is calming. Reminds me of a 7-Up can.
I've gotten quite comfy and I just wanted to reccomend it, since I have a small voice here. You can find out more at: http://www.linuxmint.com/
Oh, and for those of you who don’t know already… it’s 100% free. In more ways than one.
Friday, February 6, 2009
Cool Programming Tricks Episode 2: Anonymous structs
This is a C++ trick that I learned at work. Similar concepts must exist in other languages, but I do not know of any. Additionally, this won't do much for EMACS or vi users who don't have auto-completion. How do you live by the way?
Anyway. You may be used to viewing structs as an inferior form of a class. Actually, they're technically the same in C++ with visibility differences, but in practice they are totally different! A struct is made for organization. Try thinking of them as tables inside a document, with several fields apiece that you can change separately. The uses of such might seem limited in programming, where you want to cut down on the amount of variables in each scope to simplify your efforts ( i.e., a new class with private variables. ) However, you will always wind up having a lot of things to choose from regardless of this simplification. Sometimes making a class to hold your many variables is not the answer. After all, what's the point of a class that's all accessors and mutators?
My sorting trick is an anonymous struct. I didn't even know these existed. They wear no type name, therefore you cannot instantiate it, ever. It exists once and only once: in the scope it's created in. Take a look:
class Game {
private:
struct {
BITMAP* player;
BITMAP* enemy;
BITMAP* background;
} graphics;
struct {
SOUND* music;
SOUND* hit;
} sfx;
}
These structs, graphics and sfx, ONLY exist inside this class. So they become like folders of data, and thanks to the power of IDEs, you can take advantage of this. For example, if you start designing a level for this game, you need to remember what the bad guy's BITMAP pointer was. Well you don't have to go to the header if you remembered 'graphics'. Simply type "graphics."(with the dot) and any IDE worth ten cents will pop up a box listing each of the images. If you don't want to have to memorize all these structs, put THEM in a struct called "media", and remember that. It's just like managing your desktop. You could take this really far and have every single one of your classes put all its private data in an anonymous struct called 'pdata', and never look through your headers again. A real time saver!
I do this frequently since learning at work. No problems so far. Do let me know what you think!
Anyway. You may be used to viewing structs as an inferior form of a class. Actually, they're technically the same in C++ with visibility differences, but in practice they are totally different! A struct is made for organization. Try thinking of them as tables inside a document, with several fields apiece that you can change separately. The uses of such might seem limited in programming, where you want to cut down on the amount of variables in each scope to simplify your efforts ( i.e., a new class with private variables. ) However, you will always wind up having a lot of things to choose from regardless of this simplification. Sometimes making a class to hold your many variables is not the answer. After all, what's the point of a class that's all accessors and mutators?
My sorting trick is an anonymous struct. I didn't even know these existed. They wear no type name, therefore you cannot instantiate it, ever. It exists once and only once: in the scope it's created in. Take a look:
class Game {
private:
struct {
BITMAP* player;
BITMAP* enemy;
BITMAP* background;
} graphics;
struct {
SOUND* music;
SOUND* hit;
} sfx;
}
These structs, graphics and sfx, ONLY exist inside this class. So they become like folders of data, and thanks to the power of IDEs, you can take advantage of this. For example, if you start designing a level for this game, you need to remember what the bad guy's BITMAP pointer was. Well you don't have to go to the header if you remembered 'graphics'. Simply type "graphics."(with the dot) and any IDE worth ten cents will pop up a box listing each of the images. If you don't want to have to memorize all these structs, put THEM in a struct called "media", and remember that. It's just like managing your desktop. You could take this really far and have every single one of your classes put all its private data in an anonymous struct called 'pdata', and never look through your headers again. A real time saver!
I do this frequently since learning at work. No problems so far. Do let me know what you think!
Tuesday, January 27, 2009
Cool Programming Tricks Episode 1: The “It’s me again!” technique.
I thought I’d divulge some of the coding tricks I use most often for my fellow programmers visiting this blog. Mainly I would like to get some opinions on them; after all, I’d like to know if I’m walking on a short pier. However, I think they’re fairly useful little tricks and I’m proud of how they’ve worked out for me so far.
By the way, I’m not familiar with ALL the major design patterns, so some of my tricks might have names I don’t know of, in which case – fill me in!
Now, on to my favorite trick by far. You can do this in just about any language that supports inheritance.
As we all know, a pointer to an interface or base class can be assigned to any children of said class, provided you use only the methods available in the pointer’s type ( if you don’t know what I’m talking about, get a design patterns book FAST! ) One of my favorite things to break up into small encapsulated classes is the program’s interface. A game’s loading screen, game play, credits, score board, etc, are often crammed into a single driver class or even called in the main loop with a ton of conditionals. I prefer them to be in separate classes.
So try this. You have your main class with its main loop. There are a series of functions that get looped through in any mode, usually draw() and update(). Whatever the current mode is, the loop delegates to that mode and it runs until a switch is needed. Normally, programmers will have some kind of return value or other check to see when to make the switch. But I prefer to have the MODE do the switching. If update() gets called once a loop, why not have it return the next mode to switch to?
By the way, I’m not familiar with ALL the major design patterns, so some of my tricks might have names I don’t know of, in which case – fill me in!
Now, on to my favorite trick by far. You can do this in just about any language that supports inheritance.
As we all know, a pointer to an interface or base class can be assigned to any children of said class, provided you use only the methods available in the pointer’s type ( if you don’t know what I’m talking about, get a design patterns book FAST! ) One of my favorite things to break up into small encapsulated classes is the program’s interface. A game’s loading screen, game play, credits, score board, etc, are often crammed into a single driver class or even called in the main loop with a ton of conditionals. I prefer them to be in separate classes.
So try this. You have your main class with its main loop. There are a series of functions that get looped through in any mode, usually draw() and update(). Whatever the current mode is, the loop delegates to that mode and it runs until a switch is needed. Normally, programmers will have some kind of return value or other check to see when to make the switch. But I prefer to have the MODE do the switching. If update() gets called once a loop, why not have it return the next mode to switch to?
mode * nextMode = curMode->update();
if( nextMode != curMode ) {
delete curMode;
curMode = nextMode;
}
If you have some way of only keeping one of each mode ( singleton, or something else, ) simply don’t delete. This is even easier with boost’s smart pointers or your chosen language’s garbage collection. Long story short, your current mode will keep returning itself ( “ITS ME AGAIN” ) until it needs to switch, in which case it returns an instance to the appropriate mode. You can even have one return NULL for something else, say, ending the program.
This trick does not stop at game modes. Anything which delegates functionality to different child classes using the strategy pattern can use this in some form. For example, a game I am currently working on nests the use in two cases. The game’s mode is done this way, but within one of them I use the trick again, for dialog boxes. In the case of my game I don’t even need singletons or such.
I have yet to run into even a small amount of trouble doing this. Tell me what you think.
Friday, January 9, 2009
The Windmill of Quixotic Code
When you program, are you a perfectionist? Do you take to heart all the lessons you learned from your shelf of computer books - lessons like, "always make your code reusable"? Coming into my recent job, I truly felt like being that way was going to help me exceed all their expectations. I was going to give them the ideal code - a comment for every variable and function, everything in a class structure, no globals. Then I opened up the project I'd be working on for the first time, and saw a "goto".
What you learn when you leave school is that perfect code doesn't exist for large projects. It's a pie in the sky, and if anyone preaches it to you, they are trying to make themselves seem like better programmers than they probably are. In the actual "biz", you get three adjectives for computer software, of which you may only have two at any given time:
Efficient.
Good.
Cheap.
My workplace, EDAS, is strictly the first two, but even then there are tradeoffs between "efficient" and "good". I consider "good" programming to be modular, since new features only need to affect certain elements of the code. But nothing's as "efficient" as code created with a specific purpose. So we have to keep things about 50/50 if we want a good name in our industry. Sometimes that means a goto, or a global variable.
If you go into a project charging at windmills, you'll quickly find very little accomplished. Seek what is useful, not what is ideal. If you are a hobbyist, I encourage you to try everything in your code. Try all the things you've been told not to try, and attempt to figure out where they're most useful. You'll get an occasional geek on a soapbox telling you that your code's inferior, but if nothing else it will be YOU and not them that actually knows why something must be avoided, rather than doing so dogmatically.
This is a lesson I myself have learned, and thought neccessary to share. I wish I had fully understood it myself when I came aboard with this company. But, at least I'm doing a good job now, and luckily I unlearn as quickly as I learn.
What you learn when you leave school is that perfect code doesn't exist for large projects. It's a pie in the sky, and if anyone preaches it to you, they are trying to make themselves seem like better programmers than they probably are. In the actual "biz", you get three adjectives for computer software, of which you may only have two at any given time:
Efficient.
Good.
Cheap.
My workplace, EDAS, is strictly the first two, but even then there are tradeoffs between "efficient" and "good". I consider "good" programming to be modular, since new features only need to affect certain elements of the code. But nothing's as "efficient" as code created with a specific purpose. So we have to keep things about 50/50 if we want a good name in our industry. Sometimes that means a goto, or a global variable.
If you go into a project charging at windmills, you'll quickly find very little accomplished. Seek what is useful, not what is ideal. If you are a hobbyist, I encourage you to try everything in your code. Try all the things you've been told not to try, and attempt to figure out where they're most useful. You'll get an occasional geek on a soapbox telling you that your code's inferior, but if nothing else it will be YOU and not them that actually knows why something must be avoided, rather than doing so dogmatically.
This is a lesson I myself have learned, and thought neccessary to share. I wish I had fully understood it myself when I came aboard with this company. But, at least I'm doing a good job now, and luckily I unlearn as quickly as I learn.
Subscribe to:
Posts (Atom)