Programming Code needed to make game?

[Dullstar]

So, I can write a game in C?

[ccexplore]

Object-oriented more or less just means that the elements you declare have code attached to them.

That's a rather shallow way to define OOP.  I'd say you aren't really using the full power of OOP if you aren't making use of features like information hiding and inheritance.

it requires a considerable amount of processing overhead and unnecessary memory management when the program actually runs.

Depends on the language.  C++ supports a majority of OOP features, but since it does allow objects to be stack-allocated, you don't have to hit the heap if you don't need to.  As far as I can tell, the "processing overhead" and "unncessary memory management" you're thinking of are specifically regarding languages like Java and C# that does garbage collection and doesn't support stack allocations.  Those features are not prerequisites for OOP.

Remember: from the perspective of the CPU, there's no such thing as object-oriented programming. That chip simply takes one instruction at a time and processes it. You can do that with structs. You can't do that with classes. Structs have inherently higher performance.

For someone telling me to read the C spec, this has gotta be the most misleading statement I've ever heard.

CPUs deal with primitives like bytes, "words", floating point values, and addresses (which you can think of as pointers).  Structs are nowhere at the level of such primitives, any more than classes.  Some struct member access may be translatable into a single CPU instruction depending on the CPU, but so can some cases of accessing a class member variable.

As for "inherently higher performance", I think you may be way overstating the supposed overhead of classes.  For a language like C++, where structs are actually equivalent to a special case of classes, there should be close to 0 extra overhead, and for languages like C# and Java that doesn't allow (or greatly restricts) stack-allocated structs to begin with, you simply don't have a choice to begin with.

Besides, even if we're doing the "worst case" comparison of a heap-allocated, garbage collected language with C, the overhead might not matter if your performance bottleneck is not directly in your own code, but in things like graphics processing.  Even the most efficiently written machine code might not matter if there are simply too many pixels or polygons or textures etc. to be processed by your graphics card for whatever it is your game is trying to do.

Another way to look at this is, consider making a game in something like GameMaker.  Now I don't claim to know exactly how GameMaker works, but most likely it'll be interpreting rather than compiling any script/code that your game project may contain, and we're not talking about any fancy JIT optimizations either, just a simple interpreter.  Yet it has been adequate performance-wise for beginners to make games with.  I'm also aware of commercial games created using languages like Blitz 3D, which are compiled but not efficiently so (I can say with personal experience since I've seen the disassembly), and they perform just fine for the games in question (I should note that they are 3D games too).  I think it's fairly safe to say that someone's first game is not likely one that will require every bit of performance to be squeezed from the computer.

So, I can write a game in C?

Oh yes, definitely.  In fact I would guess that assembly, C, and possibly C++ covers like 99% of all commercial games past and present.  C's capabilties as a general-purpose programming language was never part of the question, it was just a matter of which language suits you best.

[GuyPerfect]

Example 1:

Q.ConvertToOrange();

What is Q? Let's say Q is a pointer to an element in an array of classes of type Convertor. Depending on the inheritence used, significant memory allocation may be required when initially declaring the object, as all applicable parts of inherited classes need to be declared as well. Do this every time a function is called and you can bog things down rather quickly.

Is ConvertToOrange() a method in class Convertor? Is it native or is it inherited from another class? Is it overloaded according to this context and instead pointing to a different function than the one in the class definition? After the indirection is applied, is the ConvertToOrange() method still in the picture at all?

When processing ConvertToOrange(), are the member elements of Convertor native to the actual object called or were they inherited from a different class? Are they able to be accessed by the Convertor class at the time the method was called?


Example 2:

ConvertToOrange(&Q);

What is Q? Q is a pointer to something. For all intents and purposes, let's call it a struct of type Convertor. Structs, when declared, simply allocate the number of bytes required to store the struct in memory. Even in dynamic array situations, this can be done quick and painlessly using a single call to malloc().

Since ConvertToOrange() is a function on its own, and one that accepts a pointer to Convertor as its argumnent, it is guaranteed to unambiguously represent a single process, which is defined in the body of the function itself.

The members of the Convertor struct are merely offset from the location of the struct itself in memory, and are always accessible.

For someone telling me to read the C spec, [...]

You have a funny way of saying "Don't waste your time reading my posts," but I kept reading anyway.

[Simon]

Several valid points, but a straw man argument as a whole, IMHO.

Making a class Convertor and derive every single thing from this is seldom a good choice. Of course the memory grows for an object of a thrice-derived class. Virtual methods are sometimes the very best thing for a job, and C++ is at least as fast with these as a C equivalent of virtuality. If one needs it, it's there. But if the code gets unreadable, it doesn't have to be used.

A struct on the stack/heap is the very same thing as a class on the stack/heap. I assume you know the byte alignment for C++ classes without or with inheritance, thus I don't know how you think C structs and C functions are significantly faster than C++ classes with member functions. Assuming you pass pointers and references, and not by value.

The same argument you bring here can be turned this way: Why do you use a slow, overhead-rich higher-level language than assembly?

The answer is: Because you like to think in C. I like to think in C++. A lot of my programming is of procedural nature, still, as C++ supports several styles other than pure OO. I also believe to know when I have to use bit-fiddling to speed things up. Which comes up every now and then, but not often.

-- Simon

[ccexplore]

Example 1:

Q.ConvertToOrange();

What is Q? Let's say Q is a pointer to an element in an array of classes of type Convertor. Depending on the inheritence used, significant memory allocation may be required when initially declaring the object, as all applicable parts of inherited classes need to be declared as well. Do this every time a function is called and you can bog things down rather quickly.

You seem to be confusing declaration with initialization.  If your Q has a lifetime outside of the scope of the function this line of code is in, then you would've needed to do something like new Q().  This would be no different than if you malloc the struct-equivalent and run some additional code for whatever initialization you need to do to make Q usable.  In both cases the work is done only once, not every time you call the member function.  As for initializing the applicable parts of the inherited class--if you truly needed to use inheritance in the first place, then you would've had to do the same initialization work if you implement it using structs and function pointers anyway.

If your Q's lifetime can be confined to the scope of the function, so that you can stack-allocate Q in a language like C++, then this is no different from using struct.  The constructor is there because you may need to initialize the values of certain members in order to use the object.  That same initialization would've been needed if you use a struct.  If you can leave the constructor with no code, then a decent compiler should easily be able to inline it to no code if given the information (eg. you define it inline in the header file).

Languages like C++ even allows your Q's lifetime to be "static", ie. essential available for the entire duration of the program's execution.  Those are either stack-allocated or allocated at the static data section of your program's memory, and works similarly to the stack-allocated case.

Is ConvertToOrange() a method in class Convertor? Is it native or is it inherited from another class? Is it overloaded according to this context and instead pointing to a different function than the one in the class definition? After the indirection is applied, is the ConvertToOrange() method still in the picture at all?

It sounds like you don't realize that all this consideration you're mentioning are resolved 99-100% at compile time by the compiler, at least for the languages I'm thinking of.

When processing ConvertToOrange(), are the member elements of Convertor native to the actual object called or were they inherited from a different class? Are they able to be accessed by the Convertor class at the time the method was called?

You're referring to information hiding.  This has nothing to do with run-time performance, it's just semantics enforced by the compiler to keep you from depending too much on the existing implementation of some class or interface.  For the languages I know, none of these considerations required any runtime processing AFAIK, unless you're thinking of something like Reflection in Java, which is not the usual way you'd be accessing class members in the first place.

ConvertToOrange(&Q);

What is Q? Q is a pointer to something. For all intents and purposes, let's call it a struct of type Convertor. Structs, when declared, simply allocate the number of bytes required to store the struct in memory. Even in dynamic array situations, this can be done quick and painlessly using a single call to malloc().

But you're forgetting that depending on how you're using Q, you may need to set some of its member variables to some appropriate values before you start passing a pointer of it to functions like ConvertToOrange.  So you're implementing the so-called "extra" processing yourself.

Since ConvertToOrange() is a function on its own, and one that accepts a pointer to Convertor as its argumnent, it is guaranteed to unambiguously represent a single process, which is defined in the body of the function itself.

This has nothing to do with performance, since again the compiler can figure out how to do the right thing at compile time.  This works because with inheritance and virtual functions, the class data contains an array of function pointers representing the true destination addresses to call.  The compiler simply emits code to index into the array and execute a CALL into the address given by the function pointer.

If there is no inheritance involved, then you wouldn't need to make the member function virtual in the first place, and the compiler can just call the member function directly.  Depending on how often the call occurs, the overhead of the extra indexing from using a virtual function may be negligible.

The members of the Convertor struct are merely offset from the location of the struct itself in memory, and are always accessible.

Again, this has nothing to do with performance.  The reason for restricting access to certain members is when they are not part of the interface your object wishes to expose, but instead are implementation details that are subject to change.  If you have full control of the source code of the class, you can always elect to make everything public and named uniquely.  Some languages also gives you a way to access a member hidden by the name of another member in a derived class (eg. casting).

[edit: and one more thing, since you referred to memory layout also.  Class members are not stored that much differently than struct members.  You may not be able to accurately "predict" their exact locations if you merely read the source code of how the class is declared (because of all the extra "hidden" memory for virtual function pointers, if you elect to use it, plus members inherited from base classes), but otherwise, if you account for the extra stuff (none of which is code, which is never stored with the class data if that's your mental picture), it's no different from a struct.  Besides, C doesn't guarantee any alignment for individual struct members either (your compiler might, but that's compiler-specific.  Some compilers even have switches or preprocessing directives for setting the alignment to use).  In any event, it would not be good practice for portability if you have any need to know exactly how the compiler lays out the members of a struct or a class.]

For someone telling me to read the C spec, [...]

You have a funny way of saying "Don't waste your time reading my posts," but I kept reading anyway.

I don't know what you mean by this, but the fact is, during the last argument over C, your responses show it is you in fact who fails to understand some of the finer points in the C spec, and I'm not sure you still quite grasped that.  Your current foray into OOP shows you seem to have even less understanding of how OOP languages get compiled.

You're right that with the greater semantic complexity of OOP languages, you can more easily write code that have more overhead than you realize, but that's as much a lack of understanding of how the OOP features work.  You told me you shouldn't blame C for the user's incompetence, so I'd say you shouldn't blame an OOP language for the user's failure to understand how its features work.  In any event, if you're talking about micro-managing performance at the individual CPU instruction level, then you would've been arguing for using assembly language, not C.

And the final pointer about where the actual perf bottleneck is still holds.

[ccexplore]

Several valid points, but a straw man argument as a whole, IMHO.

Ha, maybe I should've read your post first before responding to GuyPerfect's stuff point-by-point, since that's exactly what it is.  I'm starting to think GuyPerfect purposely do this just to waste my time because he thinks I can't resist going through his posts point-by-point.

Actually, the real issue is that comparing C with OOP, rather than a specific OOP language like C++/Java, is kinda pointless because there are many many ways the concepts and constructs of OOPs can be implemented by the compiler.  Also, many of the languages have other features that are more of concern when we're talking about performance.  For example, we can talk till the cows come home about how much performance impact the OOP overhead incurs in Java, but then we'll be forgetting that Java compiles to bytecode that is in turned interpreted (with some JIT magic every now and then)--that aspect of the language already puts Java at a disadvantage performance-wise regardless of OOP.  Similarly, C++ gives you a remarkable amount of flexibility over how much OOP feature you want to include in your classes, which can pretty much render a lot of the comparisons somewhat of a moot point.

And let's be clear here that I have no problem at all with GuyPerfect sticking to C.  In fact, given some of his forays into explaining OOP, I'm not sure how confident I'll be if he does try to program in something besides C. http://www.lemmingsforums.com/Smileys/lemmings/wink.gif" alt=";)" title="Wink" class="smiley" />

[GuyPerfect]

I assume you know the byte alignment for C++ classes without or with inheritance, thus I don't know how you think C structs and C functions are significantly faster than C++ classes with member functions.

For C versus C++ specifically, the difference in performance in the example I gave is negligible. It is worth noting that my post was not made to be specifically for C or against C++ or any combination thereof.

The same argument you bring here can be turned this way: Why do you use a slow, overhead-rich higher-level language than assembly?

I use assembly any time I code something to work with a specific target platform, such as video game systems. I use C in a general-purpose environment because it can be compiled for various architectures and easily modified to suit alternate uses.

You seem to be confusing declaration with initialization.

When authoring the post, I'd assumed that none of the objects used were initialized. When referring to inheritence, declaration itself needs to look backwards all the way to the top of the chain to make sure all the needed memory is allocated.

It sounds like you don't realize that all this consideration you're mentioning are resolved 99-100% at compile time by the compiler, at least for the languages I'm thinking of.

From a strictly OOP point of view, I refrained from making such assumptions. I had JavaScript in mind when making my post, which can reorganize the object collection on the fly and adapt with changes to accessible members and methods... and even generate its own code to run and switch between data types, though that's not OOP stuff.

You dismissed additional arguments claiming the compiler would handle things, but don't assume that compilers will be used.

For what it's worth, to explain that C++ essentially converts OOP code to procedural code at compile time is not a good way to support the OOP argument.

Besides, C doesn't guarantee any alignment for individual struct members either (your compiler might, but that's compiler-specific.

I didn't mean to suggest that the programmer knows where the elements are, as, like you said, he may not. What I meant is that the code will always say Address + Offset to retrieve any elements of a struct regardless of where or how it's used.

You're referring to information hiding.

I was referring to the literal removal of certain elements or methods depending on the state of the object hierarchy. This is namely an issue with JavaScript, as I'm not even sure C++ can mess with things like that.

Ha [...]

Another good spot to stop reading, but I'm so deviant!

In fact, given some of his forays into explaining OOP, I'm not sure how confident I'll be if he does try to program in something besides C. http://www.lemmingsforums.com/Smileys/lemmings/wink.gif" alt=";)" title="Wink" class="smiley" />

Your mother smells like burnt cabbage and you shower with your socks on.

...What? My argument is valid! Take me seriously!

[ccexplore]

In fact, given some of his forays into explaining OOP, I'm not sure how confident I'll be if he does try to program in something besides C. http://www.lemmingsforums.com/Smileys/lemmings/wink.gif" alt=";)" title="Wink" class="smiley" />

Your mother smells like burnt cabbage and you shower with your socks on.

...What? My argument is valid! Take me seriously!

Okay, fair enough, I probably was thinking too much about C++ when reading your examples.  I do agree that some OOP languages will pretty much give you no choice but to take a near-worst-case overhead on every object.  But from what has been cited so far, it seems that for any arguments about perf hits from OOP that applies to a specific OOP language, invariably you can find other features in that language, unrelated to OOP, that also do not compare favorably with C performance-wise.  Some such features may even be of more concern performance-wise compared with the OOP overhead in that language.  (Especially if you include interpreted languages into the mix, which totally throws off the comparison just from the interpreter processing alone.)

So I think it's not so much a question of OOP, as it is simply that in a sense, C abstracts away low-level machine code the least of all high-level languages, and as a result has the least potential of introducting overhead that can be unnecessary and possibly performance-impacting in specific cases.  OOP is merely but one of many possible features in a high-level programming language that could introduce such overhead.

========

On a somewhat unrelated note, I'm not sure this would make a good argument to turn someone away from learning OOP.  They don't have to use an OOP language if the performance tradeoff is unacceptable for specific projects, but learning the underlying concepts I think is still useful.  Interesting for example that you mentioned Javascript--if Dullstar needs to do that sort of programming on a web page in the future, C would not really be a choice anymore, and then he'd still need to understanding the basics of OOP so that he can learn to use something like Javascript.

[GuyPerfect]

Of course, this is all ignoring the fact that most game process threads aren't limited by the efficiency of their code, but rather simply have a target time of whatever the display rate happens to be.

I was also thinking of JavaScript being executed from file in much the same way your typical Perl or PHP script would be... That is to say, not necessarily used on a web page.

[Mindless]

First off, this whole thread is ludicrous.
Secondly, I didn't write this for my health (honestly, I don't know why I'm wasting my time), and I don't plan on wasting my words/time further if this post doesn't sink in.

@GuyPerfect:
Using JavaScript as your token OOP language and making statements about OOP based on how JavaScript works is ridiculous.  Using that logic, I could make similarly ridiculous statements about how horribly inadequate procedural languages are because "it doesn't work that way in Brainf*ck."

OOP is a design choice.  I can write C++ code until the cows come home and never design a single module using OOP.  Some would even go so far as to say, "http://www.signitek.com/Philosophy.htm" class="bbc_link" target="_blank">If you are a class provider, your classes are not object-oriented until someone else benefits from re-using them."

@dullstar:
GuyPerfect was completely correct in his intentions when he said

If you're only looking into programming because of the end result of what you could do with it, you've already doomed yourself to fail.

Computer programming isn't something you pick up one day because you think "oh, it'd be awesome if I wrote a video game," and you go straight off to write this game.  No, you start off writing "hello world," and a few years later you'll have completed the mindset necessary to program a complex game.

You compose all these threads talking about how you'd like to do all these things, but it ends up being all talk.  Where does that get you?  Browse Sourceforge for a while and the endless lists of projects with a project summary and no source code, and you'll discover that the answer is NOWHERE.

If you're going to program something, you go off into a cave and program away until you have something to show for your efforts.  Until then, there's no purpose in talking about what you think would be awesome to do.

In short, talk is cheap.

Do I think this post is harsh?  Yes.  Then why am I posting it?  Because you're not getting the point:  You have the most posts of anyone on the forum, so stop posting and go actually accomplish something.

[ccexplore]

To be fair, I believe Dullstar did start some basic programming exercises like writing a calculator in C# or something like that.  I guess you can say he's trying to jump the gun on doing much more complex programs, and is probably getting lost because he hasn't even started to think about all the subtasks involved.  And as you have suggested, it's also likely that he doesn't quite grasp how programming is like the art of learning to write an essay (nay, maybe more like a novel).  There're a lot of fundamentals you need to address first, such as vocabulary, grammar, sentence structure, sentence/idea organization, and so forth, all of which you need to be on solid footing first before you're truly ready to write great essays/novels.

I myself have relatively limited experience specific to programming games, so take my suggestions with a grain of salt, but I think here are some possible intermediate steps toward getting the mastery required to start writing games for real, besides the obvious of getting solid footing on the fundamentals of programming (for which I suggest taking a programming class for real if you're truly serious into it):

1) Get some basic exposure into 2D graphics programming.  At the end of this, you should be able to write a program that displays a bouncing ball bouncing around a screen or a window.  Don't worry if it looks bad (eg. the screen flickers a lot because you have to keep erasing and re-drawing the ball); just get it to the point where it resembles the description in the preceding sentence.

2) Get some experience into programming the logic, aka game mechanics, of a game, that is, the rules and behaviors that define the interactions between all the entities in your game:

    a) as a first start, I believe you should deal with simple games that are based on real-life games like card games, or board games.
       - The simplest one is to do a 2-player tic-tac-toe app ("2-player" means you don't even need to think about truly advance subjects like AI).
       - Then try to go on with a card game, whichever one you like, again limiting it to all-human interactions with the computer's main role to make sure the rules of the game are followed, to display the progress of the game, and to keep track of scoring (if any).
       - Then if you want, you can move on to a board game like Checkers, Chess, or Othello, again make it all-human so you don't deal with AI.

   Nice thing about these sorts of games is that you can even get by without worrying too much about graphics.  At the extreme, you can make those games entirely out of ASCII art and other textual representations basically (although you might be stretching it a little with Chess...)

    b) As a next step, if you're thinking of computer games, you need to get familiar with what basically are fundamental object-oriented programming (even if you insist on sticking with C structs and function pointers; don't fool yourself into confusing the syntax with the design principles).  It's no accident that a lot of OOP programming classes tend to introduce the ideas by having you write some sort of, if not necessarily a game, then possibly a simulation of real-life things, because in a sense it's one of the things the OOP paradigm is intend to address.  This helps you get familiar with the idea of how you can represent an entity in your game with a collection of data associated with the entity's current state, and methods that you invoke to manipulate the entity (changing its state as a result) and for managing interactions amongst entities.

I don't have a solid idea of what can serve as an "end-game" program for this stage of learning.  I'll let you know if something good comes to mind.

3) Now it's time to go back to graphics, in particular more advance things like bitmaps, collision detection, and animation.  This will take a lot of learning if you intend to write all of this from scratch, so be very patient.

Also a good time to learn about handling keyboard input.  This is much easier than graphics so you should be able to learn both at the same time.

The end game program for this stage of learning should be a program where you can use the arrow keys to move an animated sprite around the screen/window.

=======================

At this point I'd say you're probably 60% on your way towards being able to write your own games for real.  Congratulations!  There's of course a lot more that can be addressed (you'd noticed that I haven't talked about sound or music or even using the mouse; and I've stayed away from 3D and AI for obvious reasons).  If you're serious about it, you may want to consider buying books on game programming, or even just scour your local library for some (although the disadvantage with the local libary is that you may end up with lots of old books with specific techniques geared towards old computers like DOS).

This reminds me, I actually have a book on DOS game programming from like 15-20 years ago.  Maybe I should take a look at it and at least give you an outline of how the book addresses the various areas pertinent to game programming.  I won't recommend the book itself because it's written for the DOS era so a lot of the technical details are not as applicable today, even if the concepts still are.

[Dullstar]

Good thing is, no mouse needed in my game projects, only a keyboard!

HOWEVER, at last, something to use to tell what concepts to use.
Unfortunately, I don't know of any programming classes around here, and even if they were something tells me they wouldn't accept people my age, so I'll teach myself.  I might get a book sometime about it, though.
The basic point is, they should be playable within the limits of an SNES controller.  If it can't, there is a problem (that doesn't mean it will be SNES controller compatible, but it will mean that the controller has enough buttons,  http://www.lemmingsforums.com/Smileys/lemmings/laugh.gif" alt=":D" title="Laugh" class="smiley" />).

Another little note:  They have been planned 2D anyways.  AI will eventually be needed, but we'll not have anything terribly strategic.  I'll eventually provide basic concepts, but that can wait until we have the ability to move the character around.  I'll have a lot more to program next week, though, because the marching season will be over PLUS a four day weekend!

[Dullstar]

I found some decent tutorials, and have a progress report in the form of an image.
Not completely done with the tutorials either...  at least the Python ones are going pretty fast.

Also, I'm going to provide a link for the tutorial - http://rene.f0o.com/mywiki/LectureThree" class="bbc_link" target="_blank">http://rene.f0o.com/mywiki/LectureThree
They also have basic Python tutorials, but as I look into basic stuff from any site, I see nothing more than the stuff I used to write that Python command line calculator.  (I skimmed through Lectures 1 and 2, nothing much I didn't know, although there is something that is somewhat complicated that I'm not sure if it's going to be useful or not, as I recall it saying it doesn't even work in some other programming languages, so I'm just going to come back to that if I need it)