I am using SDL for the graphics and keyboard events for my hobby never-to-be-completed computer game coding project. I think it’s a bit more friendly than DirectX and OpenGL, and it’s platform neutral
I’ve considered C# and plan on using it eventually but wanted to start with C++ first.
Good idea, you’ll like it when you switch to C# and the pain goes away. :)
the SHARP pain. OH HO HO!
Other than my smart assed comments, how far away are we from being at a point where C#(or any other language really) is a viable dev environment for games?
For AAA games? Not going to happen anytime soon, if only because the console vendors won’t bother to support anything besides C++.
For smaller games with web distribution? Already happened. Tons of Java and Flash games out there, and text adventures run in their own virtual machine (see thread in the Games forum).
The ARM is a great book, but it’s way outdated. You are better off with “The C++ Programming Language (Special 3rd Edition)”.
McMaster - why don’t you build a text-only game or an FPS mod? A text RPG or maybe a Zork clone would be more than enough work for a first attempt. v2.0 could have have graphics!
Has anyone used the Torque 2D engine for anything? For $100 I’ve been thinking of trying it out.
Yeah the Torque demos do look pretty damn nice.
Failing that, I would recommend Managed DirectX in C# is a sensible choice for a hobbyist. There’s no reason to code in C++ if you don’t absolutely have to, really.
Here’s a question for game developers: How much C++ is enough?
C with classes?
Proper use of the STL?
Template usage?
Full blown template creation?
My perception may be a little skewed. A lot of my experience in how proper C++ is supposed to be was with someone who ate drank and breathed templates. Heavy into designing templates. Then again, his idea of a “hello world” type program for beginner students was a parser for a calculator.
I need to get back into the programming side of things. Current job is completely on the analysis side, with heavy networking. All I really get to do is write the occasional python script.
Two problems with using C#. One, the .NET runtime is far from ubiquitous, so installing your game is going to be a multi-step process for many people – a big turn-off, for a casual game. Two, until the Mono guys get their shit together, it can only target Windows, and even after they do, I’m imagining it’ll be a while until they port DirectX over as well. At least, those were the problems a couple years ago. Maybe the situation has improved since.
Hm. Actually, I was impressed by “Processing,” recently: http://processing.org/
Check out the thumbnailed examples in the left column. I haven’t actually tried to use the language, but at first glance, this solves the ease-of-use, distribution, and platform user base problems all at once.
That’s true if Jason is aiming to make money off his games (and if the games themselves are very small compared to the runtime). But if it’s only for his own amusement or perhaps freeware distribution it’s not an issue. I think the latter is the case, at least for the first few projects, since he’s just getting into it.
Two, until the Mono guys get their shit together, it can only target Windows, and even after they do, I’m imagining it’ll be a while until they port DirectX over as well. At least, those were the problems a couple years ago. Maybe the situation has improved since.
Mono will certainly never run Managed DirectX – in fact I bet it won’t ever run the full Windows Forms. I understand its main purpose is to allow porting .NET server applications to Linux. But is this in any way relevant? It’s not like Unix users ever buy or expect games for their systems anyway…
You have to be familiar with template use and creation, but in a lot of cases they aren’t necessarily used as heavily as in some industries because of memory bloat they can cause. On consoles, huge amount of templates and instantiations can cause huge executable sizes. On PC it’s not as much of a problem.
As for the STL, that really just depends on where you work, but nowadays it seems even if people aren’t using the STL itself, they are using stuff made with a similar mindset, so it’s worth knowing.
Just had to point out the stealth name change.
Hell is having to debug STL code written by other people.
Sure, it’s fine if you intend to write games for yourself. But if you’re distributing games for free, the installation procedure is by far the biggest barrier to entry for a potential player. Even if there’s no money involved, you want people to play your game, right?
The portability issue is mostly political, I admit. Again, if you’re writing games for yourself or your friends, Windows-only is no big deal. In fact, even if you’re writing games for money, Windows-only is no big deal. I would just have personal issues with locking myself into a single platform.
At my last job I would’ve agreed with you. At my current job, I’m debugging someone else’s LISP macros, and I can tell you with some confidence that you don’t know what pain is.
I highly recommend the game programming gems series, as others have mentioned. They are reference books, not books you read from cover to cover. In addition to those, I recommend “code complete” and “writing solid code.”
None of these are really game programming books though. The gems books offer solutions to problems you will have writing a game, but it does not tell you HOW to write a game. I can’t think of any game programming books worth the paper they are printed on.
As for a language, Id stick with C++. C# has a lot of nice syntax and grammar, but if anyone is going to use your game, they must have the .NET framework installed. Its’ speed is also questionable. No one writes major games in it, maybe there is a reason.
If VS 2005 is VS8, Id go back to VS2003 (VS7). I have heard nothing but bad things about VS8.
General advice Id give you so to modularize your code and make your basic game engine first, and then make your game code. It will be a good exercise on architecture.
Write your graphics set that lets you set a screen up, and render basic models. Then write a basic sound and input system (keyboard, mouse, etc). If your going to use animations then write each one of those and figure out how to plug them into your render. IE: Animated textures vs Animated models.
After that is all done, you will need to add a few higher level systems which might include a sky box, ‘Terrain’, and a collision system. Normal the terrain (things you stand/drive on or fly over) is a special system and not just a collection of objects. I am not sure why its done this way, I never got that deep into engine code.
At this point you can easily write basic game code and be able to compile and run it to test it. From here you extend the engine as you need things (maybe dynamic lighting, shader effects, 3d sound, etc…) and are free to make whatever you want.
As far as code design, do not follow a lot of formalities you would follow in a non-real-time application. This does not mean throw structure and good coding practices out the window, it just means you should be aware of the costs involved of those choices.
For example, lets take the function FOO which takes a CString and returns its length (lets ignore the fact that CString has this operator):
int FOO(CString MyString)
{
return MyString.GetLength();
}
In a formal context this is fine. In a game code, it is not. Why? It passes a copy of a string in, and that means allocation and deallocation. This is very bad in game code. By game code, I mean the code executed during the real time game-play, not loading or unloading of levels. Sticking in an & before mystring will greatly improve efficiency. You could also inline the function too.
Are you writing a class that has public, protected, and private members? Did you forget to data accessors? No? Well you just messed up. Make everything public and access the members directly. Who else is going to be using the class? Some guy from Zimbabwe? All it does is slow you down if you make the formal setters and getters.
Anyway, good luck with that.
DeepT,
I’m sorry, but you say conflicting things.
General advice Id give you so to modularize your code and make your basic game engine first, and then make your game code. It will be a good exercise on architecture.
Are you writing a class that has public, protected, and private members? Did you forget to data accessors? No? Well you just messed up. Make everything public and access the members directly. Who else is going to be using the class? Some guy from Zimbabwe? All it does is slow you down if you make the formal setters and getters.
???
As for your FOO function, I suspect the optimizer would optimize that away, and you really want a const CString& anyway.
You shouldn’t use CStrings anyway. You want to use MFC? Are you crazy?
It all depends on what Jason wants to do. Write an AAA game? I doubt it. Learn programming and the concepts of gaming? Ok.
C#. Seriously. I write C++ everyday. I lurrrve STL templates and boost. C# is like “ahhhh this is so much nicer… as long as you can run on Windows and have the .Net framework”…
I think you greatly overestimate the difficulty of installing the .NET Framework. My little Galactopedia had over 8,000 downloads so far, and it requires .NET 2.0. So I guess it can’t be so bad…