...because it is arbitrary, cryptic and seriously difficult to read.
Let's take a quick example, using std::map< filename,sample> m_samples:
const BOOL AUDIO::is_playing(const FILENAME sound_file)
{
return (m_samples[sound_file].is_playing());
}
works, but this doesn't:
const BOOL AUDIO::is_playing(const FILENAME sound_file) const
{
return (m_samples[sound_file].is_playing());
}
Why?
Well, std::map doesn't have an operator[] that returns constant references, of course. Gnngh.
No, you have to use this gem instead:
const BOOL AUDIO::is_playing(const FILENAME sound_file) const
{
return (m_samples.find(sound_file)->second.is_playing();
}
This forces you to use two major usability criminals, obfuscator-in-chief std::pair, which throws in a less-than-clear 'second', and partner-in-crime iterator, or in this case the snappily titled
std::map< filename,sample>::iterator
Honestly. And oh noes! Heaven forbid you should want to use an STL container for storing resource classes as it unavoidably makes copies of things on insertion, so you'd better be using smart pointers or it'll be throwing things away left and right.
And another thing. Do you think it would be useful if a container class had a function called, oh I don't know, contains()? Nope. you have to cryptically look for something, and then compare it to an element off the end of the (not necessarily linear) container.
Good code:
if (samples.contains(sound_file))
STL code:
if (samples.find(sound_file) == samples.end())
Well, we could write our own contains() function by just extending the std::map, surely? But no! You can't inherit from STL objects.
And this is why STL is still widely ignored. It's useful, but that comes at the cost of code that will seriously slow down your reading if you ever want to come back to it.
Friday, 13 November 2009
Tuesday, 7 July 2009
Action!
Well, phew! Lots of actual work going on right now, so no time to talk.
Also, mildly deafened by Brian Blessed shouting loudly in my ears yesterday.
Also, mildly deafened by Brian Blessed shouting loudly in my ears yesterday.
Monday, 18 May 2009
Testing Times
I'm an Extreme Programmer, no make that a Goddam EXTREEEEEEEME Programmer. Yee haw. etc.
'Extreme Programming', for those of you who don't know seems to stand for, 'Extreme-ly sensible combination of the last thirty years lessons in software development. Programming'. Fortunately, it's got a catchy and GODDAM EXTREEEEEME marketing name, otherwise y'know it might sound a little dull.
What it boils down to are a few sensible principles designed for building software, rather than trying to crowbar software into a system used to make bridges or circuits (ie Software Engineering).
The principles are:
Test First, Code Second - AKA Test Driven Development. Simple one this, all programmers want to get stuff working as the first thing they do. And the second. And the third. Pretty soon you've got a very complex system going, at which point it starts to break. And you fix it. And it breaks somewhere else. Bums. If only you'd written some tests to check the code was working. You can't do it now, where would you start? So you fall back on a combination of manual testing, and crossing fingers.
Test driven development demands that you write the tests a little at a time, for a bit of code before you code it. This makes you nicely disciplined into doing it, and gives you a great batch of tests that'll tell you if your new changes have broken anything. Believe me, this is a great relief. As a nice side effect, structuring code to be testable generally forces you to have a clean design.
Keep it simple - Only write the code you need to pass the tests. If you need more code, write more tests. This saves you writing code to solve problems you might never come across.
50% now is better than 100% never - Get something working as quickly as possible. Use placeholders, simplification, whatever, just get it playing. This way you can see if it's any good as quickly as possible, and you haven't wasted effort over-desiging something you're about to ditch.
The design is wrong and the customer is right - And if you've got something working, get players to play it, see if it's what they want, and if not, change it. Do not have a fixed plan for your destination or you may end up building a lovely white-elelephant that nobody wants to play.
Two heads are better - Get two people to work together on everything. This not only reduces bugs by about 60-odd percent, it also stops you wandering off down pointless paths and lets you bounce ideas off your partner. Ideally, one of you writes a test and the other implements the code (then vice versa) so you don't prejudice the implementation. I'm obviously not going to do this, because there's only me.
'Extreme Programming', for those of you who don't know seems to stand for, 'Extreme-ly sensible combination of the last thirty years lessons in software development. Programming'. Fortunately, it's got a catchy and GODDAM EXTREEEEEME marketing name, otherwise y'know it might sound a little dull.
What it boils down to are a few sensible principles designed for building software, rather than trying to crowbar software into a system used to make bridges or circuits (ie Software Engineering).
The principles are:
Test First, Code Second - AKA Test Driven Development. Simple one this, all programmers want to get stuff working as the first thing they do. And the second. And the third. Pretty soon you've got a very complex system going, at which point it starts to break. And you fix it. And it breaks somewhere else. Bums. If only you'd written some tests to check the code was working. You can't do it now, where would you start? So you fall back on a combination of manual testing, and crossing fingers.
Test driven development demands that you write the tests a little at a time, for a bit of code before you code it. This makes you nicely disciplined into doing it, and gives you a great batch of tests that'll tell you if your new changes have broken anything. Believe me, this is a great relief. As a nice side effect, structuring code to be testable generally forces you to have a clean design.
Keep it simple - Only write the code you need to pass the tests. If you need more code, write more tests. This saves you writing code to solve problems you might never come across.
50% now is better than 100% never - Get something working as quickly as possible. Use placeholders, simplification, whatever, just get it playing. This way you can see if it's any good as quickly as possible, and you haven't wasted effort over-desiging something you're about to ditch.
The design is wrong and the customer is right - And if you've got something working, get players to play it, see if it's what they want, and if not, change it. Do not have a fixed plan for your destination or you may end up building a lovely white-elelephant that nobody wants to play.
Two heads are better - Get two people to work together on everything. This not only reduces bugs by about 60-odd percent, it also stops you wandering off down pointless paths and lets you bounce ideas off your partner. Ideally, one of you writes a test and the other implements the code (then vice versa) so you don't prejudice the implementation. I'm obviously not going to do this, because there's only me.
Wednesday, 13 May 2009
Stand by for Action!
Confirmation received that my own spare time work does not clash with my day job...
Anything can happen in the next half-hour!
A nice cup of tea, for example.
Anything can happen in the next half-hour!
A nice cup of tea, for example.
Take Art
You'll notice I haven't said anything about pictures (or music) yet. Well, I'm not going to do these myself and I shall be throwing myself onto the mercy of some artist and musician friends later, but how do we get by for now? We use placeholders, and there are two traditional ways to get them.
1) Theft
2) Programmers
Both have the advantage of speed, so we don't waste too much effort on something we aren't ultimately going to use.
Theft
Well, piracy. Simply use somebody else's graphics (sounds, fonts) from someone else's game, or the Internet. Very quick, and you get good quality results straight away. You can get away with it, as nobody will ever see (hear, read) these 'borrowed' assets. There is one major drawback, however.
You will forget.
You will forget to remove something from the final game, and then you can be in hilarious* legal trouble with your finished game. Not good. For this reason, I'm completely going to avoid this route and go with...
Programmers
Programmer art! It's great! Or not! Yes, programmers can do pretty much anything as long as all you want are some correctly formatted data files. We're spending no time here, so doubly bad. Programmer assets do have a big advantage though: they're noticeable. You aren't going to accidentally leave your enemy marines as bright pink rectangles. With any luck, they'll be so bad that artists will replace them on sight. Bonus.
*Not hilarious.
1) Theft
2) Programmers
Both have the advantage of speed, so we don't waste too much effort on something we aren't ultimately going to use.
Theft
Well, piracy. Simply use somebody else's graphics (sounds, fonts) from someone else's game, or the Internet. Very quick, and you get good quality results straight away. You can get away with it, as nobody will ever see (hear, read) these 'borrowed' assets. There is one major drawback, however.
You will forget.
You will forget to remove something from the final game, and then you can be in hilarious* legal trouble with your finished game. Not good. For this reason, I'm completely going to avoid this route and go with...
Programmers
Programmer art! It's great! Or not! Yes, programmers can do pretty much anything as long as all you want are some correctly formatted data files. We're spending no time here, so doubly bad. Programmer assets do have a big advantage though: they're noticeable. You aren't going to accidentally leave your enemy marines as bright pink rectangles. With any luck, they'll be so bad that artists will replace them on sight. Bonus.
*Not hilarious.
Monday, 11 May 2009
And The Bodies of Your Enemies Will Float By
The annoying thing about the Internet is that whenever you try and do something, a quick Google search shows that you might as well not bother, as it's already been done.
The great thing about the Internet is that whenever you want to do something, a quick Google search shows that you don't need to worry, as someone's already done it for you.
I've been practicing the great art of achieving lots while doing nothing. If you remember, I can't write any code until some contractual issues are resolved, but that doesn't stop me making progress.
I've sorted out the map editor, and all my developmental foundations: the low-level graphics and sprite system, the memory and string handling, and a maths library, and all without doing a single thing. These are all things I've had to write from scratch in the past, often slowly and painfully, but which can now be had for the price of a little research due to the generosity of programmers, and easy communication over the Internet.
First off, I've downloaded and compiled the Allegro SDK. This provides all the basic functions I should need, and being a venerable framework will have many years of nice bug testing behind it. It's free and it has no restrictive licence at all. As there's source code, if I find any problems I can fix them and pass the fix back to the main development community too. Although it supports 3D, it was originally 2D based which will be perfect. 2D is very much the poor cousin to 3D these days. DirectX 8 for example did away with it almost completely, making you use a sort of odd, flat 3D, but the outcry was so bad (and people stuck to DirectX 7) that they had to bring it back for DX9. Nobody, of course, will touch DX10 unless forced, as you can merrily wave good bye to any customers using Windows XP or earlier. A quick glance at the Steam hardware survey shows that as of today less than 30% of systems can run DX10, and that's gamers not just general users. Still, looks like it's up 4% since last August, so it'll be viable real soon now! Honest!
Anyway, backing me up in the tools department is respected tile map editor Mappy. There are several tile map editing programs around, but at a quick glance it looks like is the one for me. It covers both top-down and isometric views, as I haven't decided which to use yet, and joy-of-joys it even has source code for integrating it with Allegro applications. Ace.
All this means that I don't have to faff around builing the structure to let me make a game, and that I can get on to actually making one.
The great thing about the Internet is that whenever you want to do something, a quick Google search shows that you don't need to worry, as someone's already done it for you.
I've been practicing the great art of achieving lots while doing nothing. If you remember, I can't write any code until some contractual issues are resolved, but that doesn't stop me making progress.
I've sorted out the map editor, and all my developmental foundations: the low-level graphics and sprite system, the memory and string handling, and a maths library, and all without doing a single thing. These are all things I've had to write from scratch in the past, often slowly and painfully, but which can now be had for the price of a little research due to the generosity of programmers, and easy communication over the Internet.
First off, I've downloaded and compiled the Allegro SDK. This provides all the basic functions I should need, and being a venerable framework will have many years of nice bug testing behind it. It's free and it has no restrictive licence at all. As there's source code, if I find any problems I can fix them and pass the fix back to the main development community too. Although it supports 3D, it was originally 2D based which will be perfect. 2D is very much the poor cousin to 3D these days. DirectX 8 for example did away with it almost completely, making you use a sort of odd, flat 3D, but the outcry was so bad (and people stuck to DirectX 7) that they had to bring it back for DX9. Nobody, of course, will touch DX10 unless forced, as you can merrily wave good bye to any customers using Windows XP or earlier. A quick glance at the Steam hardware survey shows that as of today less than 30% of systems can run DX10, and that's gamers not just general users. Still, looks like it's up 4% since last August, so it'll be viable real soon now! Honest!
Anyway, backing me up in the tools department is respected tile map editor Mappy. There are several tile map editing programs around, but at a quick glance it looks like is the one for me. It covers both top-down and isometric views, as I haven't decided which to use yet, and joy-of-joys it even has source code for integrating it with Allegro applications. Ace.
All this means that I don't have to faff around builing the structure to let me make a game, and that I can get on to actually making one.
Friday, 8 May 2009
Time to Develop
No, I haven't started yet, but from my previous post I thought I'd outline some of the constraints I'm working with to give some better context. They boil down to time and money.
Time
Phone me up at any time and chances are you'll catch me either at work, looking after my children, or asleep, sometimes all three. In any case, I'll be grumpy.
Take a throw at the dartboard of my life, and you'll have to be in the big points. There's the double-top of evenings when I'm not doing something else, or the treble-top, very special occasions when I actually get an afternoon or morning to myself (like now - the family are at a friends house, hence the posting binge) . Any greater length of time would be the elusive quadruple top.
This means that I have to be able to pick up work again quickly, possibly after a very long period of inactivity.
What I'm looking for then is the absolute minimum of administration and fuss, not even 'just a bit', none at all. Once something is set up, it needs to stay set up.
Familiarity is also of great concern, as I can barely remember the controls for Tetris for more than a week, so don't expect me to remember your keyboard shortcuts, handy application.
I will also need code that's as clear as a windowpane, so when I come back to it I don't have to spend an hour just trying to understand the crazy world of my previous self. Fortunately, after many years of wishing to be able to go back in time and assassinate my former self, this is how I program anyway.
Money
As time is money, apparently no time is no money. No money is what I have to spend on this project. Actually, that's not strictly true. What I have is hobby money, which is a lot less than company money. For example, I'd gladly use Slickedit to speed up my editing if it was £30, but as it's £200 it can whistle, and I'll waste a months worth of free time setting Visual Studio up to use the right buttons instead, providing my own whistling. Surely it's worth buying it to save those evenings? No, because it's not like I can use the time saved to actually generate £200. If I could do paid overtime on demand, it might be different, but it isn't. Sorry.
So there we go, I've no time or money to make my game, and I'm hopefully going to show how this can be to my advantage, but best not hold your breath waiting for it to come out, eh.
Time
Phone me up at any time and chances are you'll catch me either at work, looking after my children, or asleep, sometimes all three. In any case, I'll be grumpy.
Take a throw at the dartboard of my life, and you'll have to be in the big points. There's the double-top of evenings when I'm not doing something else, or the treble-top, very special occasions when I actually get an afternoon or morning to myself (like now - the family are at a friends house, hence the posting binge) . Any greater length of time would be the elusive quadruple top.
This means that I have to be able to pick up work again quickly, possibly after a very long period of inactivity.
What I'm looking for then is the absolute minimum of administration and fuss, not even 'just a bit', none at all. Once something is set up, it needs to stay set up.
Familiarity is also of great concern, as I can barely remember the controls for Tetris for more than a week, so don't expect me to remember your keyboard shortcuts, handy application.
I will also need code that's as clear as a windowpane, so when I come back to it I don't have to spend an hour just trying to understand the crazy world of my previous self. Fortunately, after many years of wishing to be able to go back in time and assassinate my former self, this is how I program anyway.
Money
As time is money, apparently no time is no money. No money is what I have to spend on this project. Actually, that's not strictly true. What I have is hobby money, which is a lot less than company money. For example, I'd gladly use Slickedit to speed up my editing if it was £30, but as it's £200 it can whistle, and I'll waste a months worth of free time setting Visual Studio up to use the right buttons instead, providing my own whistling. Surely it's worth buying it to save those evenings? No, because it's not like I can use the time saved to actually generate £200. If I could do paid overtime on demand, it might be different, but it isn't. Sorry.
So there we go, I've no time or money to make my game, and I'm hopefully going to show how this can be to my advantage, but best not hold your breath waiting for it to come out, eh.
Subscribe to:
Posts (Atom)
