dabroz.scythe.pl

Using high-level stuff is fun. As long as it works.

Consider this C# code:

var s = new WebClient().DownloadString("http://foobar.biz").Replace("<br/>", "bar");
Console.WriteLine(s);

Cool, isn't it? Now imagine that you have to do the same thing in C, UNIX-like way (sockets etc). Yeah, seems like a real pain. And this is why high-level coding is fun.

But now assume something gone wrong. If you're "lucky" you'll get a nice exception. If you're not, you'll get some mess not related to expected result. What can you do next? Google "DownloadString mess" and read first three Stackoverflow topics? If this works, high-level programming is not as great as before, but still quite fun. But let's say that Google knows nothing. You can read API documentation. Oh yes, a lot of docs before you find something useful. And what if you find nothing?

The worst category of such bugs are "everything theoretically works, but I see nothing/crap". For example imagine you have high-level 3D engine and use such line of code:

engine.Render("car");

If it doesn't work as you expected, number of possibilities is +infinite. What can it be? Buffers? Shaders? Rendertarget settings? Where have you done it wrong? In loading stage? But there is no loading stage, engine loads everything from XML files itself, blah blah blah. And that is of course if you actually have knowledge about buffers and shaders and stuff. If you do high-level only, chances are you won't.

What I am going to say is that the only way to learn every tiniest details of some stuff is to code it COMPLETELY using most low-level you can afford. You can of course know no deep details of some stuff and still be happy human, worker and husband. But you won't know that tiny bit that makes it work. And if it fails, you'll be left alone on the ice floe.

Examples. You can know a lot about containers and algorithms, their Big O and characteristics. But will you ever be 100% sure what they exactly do to your objects? Another. You can happily use some UI library for years but when it comes to coding your own controls, their input handling, don't you feel a little nervous? If your control is on the scrollbox, in what exact order will they get mouse inputs? And why?

It is actually very easy to know if someone coded something or just used/read about it. One minute of talking and you know that he doesn't know all drawbacks, problems and dark sides.

But the sad fact is that things are getting now more and more complex. In 80' you actually could code just everything. And now? To be honest, to know every single details, you should start with x86 (and GPU, and HDD and...) emulator (VM), then do some OS programming, then code your C compiler (if you expect to reach 90+ age you can try C++), then most low-level libraries, and so on.

Yes, you could spend your whole life doing this. But... you would be surprised by NOTHING. :)

People often say: "never start creating your own engine. If you do so, you will never finish a game".

This may be true. But those people won't tell you what by creating your game, you won't finish it as well.

You can of course create simple game, let's say Tetris, for example. You probably can even write nice, well-organized, object-oriented-and-other-stuff code. OK, few hacks here and there, it's nothing. What next? You can code Snake. Or Arkanoid. How many simple games can you make? But ater how many of them your learning curve will go flat? If you've completed Tetris, Pacman, Snake, Arkanoid and Space Invaders, what can you actually learn from making Bomberman?

You can go deeper and create game with more content. But can you do it by yourself? Most programmers have very inferior graphics skills. You will need a team to do this. But again, most programmers don't have team-management skills. In the end, you'll finish with spending 80% time on team-related issues, and you'll still need to do some artwork by yourself. And that's optimistic scenario. I give a 5% chances of success. In the other 95% your team will just broke and you'll be left with nothing.

That's not a failure. After all, you are programmer, not game-director & team-manager & artist-level designer-musican & everything else. You need to write code.

So we have following charts so far:

creating simple gamesteamwork

But what if you start coding your own engine? Well, you won't need anybody else (profit in non-commercial "bussiness"). You won't have any specific needs nor deadlines. You can throw out 10KLOC just because it's poorly written -- no need to worry about compability issues, something you'll never afford during "real thing". You can experiment and implement every single new graphic technique you'll read about. You can optimize every bit of code down to assembly level. You won't need hacks to do things "fast". And you learn. And don't stop. So the chart for engine programming looks like this:

Yes, it's a spiral. Because you constantly start over and over, but every time with new skills.

You will, of course, never finish such engine. But why should you? After few years of such programming you'll have enough skills to do every single programming job you can imagine (assuming you have Not Invented Here disease and code everything from memory managers and containers to high-level networking stuff). You'll know a lot of APIs and ideas. You'll read tons of documentations and publications. What could "simple games programmer" write in his resume? I've done Pacman, Tetris and Arkanoid. Also Space Invaders, twice! I've never gone into deep details but I can code simple game for food. And someone who has tried teamwork? I am good candidate. I have never finished anything, well, to be honest, I have never gone further than concepts and DD.

And even if you're not going to be a professional (game) programmer, you can always have a decent hobby. Some people fix cars, some take care of plants. You can always polish your engine.
:)

I wonder how many games have a multiplayer that doesn't really suit them. And why? Does every publisher really require it (especially in PS3/X360 games)? I’m aware that most developers are afraid of game’s reception (about both gamers and critics), but is “shitty multiplayer” really much better than no multiplayer at all? Yeah, I can see possible opinions like “dude, this game is only 8 hours long and has no MP”, but… aren’t two additional hours of SP more attractive than multiplayer nobody would play anyway?

My final point is that there are games that are simply multiplayer friendly or unfriendly. For example most story-based FPS have very poor MP. FEAR2 is a great game if we talk about “story mode”, but what about its online mode? Yeah, it’s just totally average, and has no relation with original game whatsoever. Gears of War, Crysis and other similar games - same story. Stop. GOW has great co-op mode. Yeah, but it’s double single-player mode, not multiplayer one. But co-op is a good option for story-based FPS. On the other hand we have action-based shooters like Unreal Tournament that feature poor single-player mode.

Finally, there are “bonus” multiplayer modes, like in Red Faction: Guerilla. The team demolition mode is something completely different, but at least fun.