I don't think learning the DirectX API in particular is n00bish at all, considering it's the most popular for games at the moment and it's what you'd be using on the XBox 360 (and very likely future Microsoft consoles). So you'd definitely have a leg up on other graphics programmers if you were familiar with the API, even though in general you shouldn't be tied to any particular code base in terms of your knowledge and understanding of graphics programming. But it's certainly a good API to know.

Other than that, I don't really think the ratio of API code to other code is that important. If it takes X API calls to accomplish a certain task, then that's what it takes. However you don't want to be too dependent on any particular API -- your library should be generic enough that you could plug in something like OpenGL, for instance, and get things up and running with minimal effort.

What does "learning DX API mean"? How do you know you've learned it? By the fact that you can recite every function?

I remember reading stories a few years back about jobs that required applicants to be able to recite function signatures of several APIs (Java-related). I see little point in that.

And learning something like DX requires lots of practical experience over a broad range of hardware to be effective at it. And it still takes tweaking, which is why so many prefer to use pre-made engines and avoid that fuss altogether.

Quote:I think his goal is quite 'n00bish' considering the systems built for games such as inherited character classes that are primarily coded in the base language being used.

What are "inherited character classes"?

Quote:So, what do you think the ratio of 'system' code to API specific code is?

It's 73.465% vs. 26.535%, with deviation of 2.435%. 64.34% of studies have shown that 39.10% of projects containing more than 88.96% of 'system' code have 22.43% greater chance of failing.

Quote:Thoughts?

Does it do the something interesting? Something useful? Is it playable? Clickable? Then the ratio they used is right.

Does it crash? Doesn't compile? Was never finished? Then the ratio, or many other things, might have been wrong.

You sound like you're the kind of person to over think things way too much. Your friend wants to learn DirectX. What's wrong with that? Does it really matter if a game is x this or y that? Sometimes, you just have to look at results. Sure, your classes may be a work of art; however, if you spend all your time on theory and design and pointless debates, you'll never get anything done. I did that for a while, and I decided to stop over engineering and just go with what works. You can always make improvements later.

Quote:Original post by programmermattc

For example, in Mario you might have an 'Enemy' class which bowser and the turtles inherit from. Then the turtles could have 2 inherited sub classes (red and green). By inherited character classes I kind of limited but in general I mean these classes and manager-type resources that are built using very little API code and instead are custom object types and lists that work with those objects.

Going off-topic here, but this is actually mis-use of inheritance.

For example, in sports, you have red and blue team. They is-a "Team", but they has-a color.

Inheritance represents is-a relation.

In Mario-like game, you'd have a Sprite class as base. Whether you need anything more from there is now debatable. You could extend into StaticTile and Actor. Actor has-a controller (player for Mario, AI for everything else). You could probably justify adding Powerup as another class, but that's about it.

This type of inheritance is quite tricky to get right, and too often is way too convoluted.

In case of Mario, collisions can be handled between Sprites only. You don't need additional information, it's all pixels inside a rectangle anyway.
Controller can be an external entity, for example, you put a sprite into appropriate container (AIController, PlayerController, NOPController). On every loop, these update entities appropriately. AIController updates based on some pre-defined rules, PlayerController processes key presses, and NOPController sits there, looking pretty. Again the question arises, do these need to know about anything more than Sprite.

Perhaps for controller, you could introduce another interface (not just base class) Controllable.

This is why entity-based systems have become quite popular, Python also offers fairly flexible object model, so does Lua. While far from silver bullet, those do offer more convenient approaches to solving such complex relations.

Probably not. If it's just one small aspect of behaviour that changes, it's rarely worth introducing extra classes for it. Or, encapsulate those changes in sub-objects - see the Strategy pattern for more information on this approach, though I wouldn't recommend that level of complexity yet.