pxib is wasting time

[pxib]

I've been pissing the hours away playing unsatisfying video games and avoiding more creative pursuits. I'm getting sick of playing armchair game designer, scribbling feature lists and half baked puzzle designs on scraps of paper at work. I'm ready to educate myself enough that I can start building trifles and prototyping play mechanics and seeing if they're any fun at all.

Back in high school and college I taught myself basic C and dabbled with assembly... wrote a few programs to automate boring computer tasks and help me with higher math. I've complied no code in ten years. The transition might be easier if tried Python or a pre-made scripting environment, but ultimately I'm going to wind up wrestling with C++ so it's time to bite the bullet.

This thread's purpose is twofold:

First, I've already grabbed a few books on C++ from the library, but if anybody has had good luck with C++ resources online, I'd be happy to hear about them. Blanket advice and moral support is also accepted.

Second, every time I come on here I have a little reminder that I should get back to work. On this particular forum I imagine this post will still be on the front page to greet me in 2009.

[hal]

You go boy!! Really this is how shit gets done. Grats to you on your uber accomplishment. Well soon to be or something. No one ever succeeded with out trying.

[Krakrok]

I really wouldn't recommend C++ if you're just doing hobby prototyping stuff. You'll get farther faster with something like C#, Python, or Flash (which is javascript). Try the three indie game creators which are Torque, Blitz Basic, and 3D GameStudio to see which one you like best and then work with whatever language it uses.

[Stephen Zepp]

I really wouldn't recommend C++ if you're just doing hobby prototyping stuff. You'll get farther faster with something like C#, Python, or Flash (which is javascript). Try the three indie game creators which are Torque, Blitz Basic, and 3D GameStudio to see which one you like best and then work with whatever language it uses.

[mole, but not really]
The question you really want to ask yourself--do you want to become better at programming, making games, or making game engines. C# and XNA is a damned fine experience for making games with the least amount of struggle, and TorqueX obviously helps with that by giving you an engine on top of XNA to handle the mundane stuff (the bane of anyone wanting to make a game).

If you want to learn how game engines work, then any of the above are good--also add to the list C4, and Unity if you are a Mac guy (their PC license is kind of prohibitive currently).

If you just want to learn general programming practices, then I'd honestly start elsewhere first--games, game engines, and game design are honestly a pretty high bar to set if you just want to learn general programming, although of course the motivation factor is nice--as long as it doesn't turn into "dammit, I just want to get something done and I can't figure out why this pointer is corrupt!" like most game programming without an engine can be.
[/mole]

[hal]

Steve, You are many things on this websight. But a mole is not one of them. You are up front with your promotions. And for my self one of the things you are is welcome. I appreciate your thoughts even if I do not agree. Welcome

[pxib]

If you just want to learn general programming practices, then I'd honestly start elsewhere first--games, game engines, and game design are honestly a pretty high bar to set if you just want to learn general programming, although of course the motivation factor is nice--as long as it doesn't turn into "dammit, I just want to get something done and I can't figure out why this pointer is corrupt!" like most game programming without an engine can be.

I'm not planning on jumping right into game programming. I've wanted to get my head wrapped around object oriented programming for a long time. To an extent, using somebody else's engine will be the present I give myself once I've got this nitty gritty behind me. I don't want to get comfortable with anything before I've got the chops to appreciate it. So right now it's database management, search algorithms, and a refresher course in matrix algebra.

Foundational stuff for its own sake.

[Stephen Zepp]

Steve, You are many things on this websight. But a mole is not one of them. You are up front with your promotions. And for my self one of the things you are is welcome. I appreciate your thoughts even if I do not agree. Welcome

Thanks man, nice thing to wake up to ;) Not quite as nice as..erm, nevermind. But thanks!

[Murgos]

I'm not planning on jumping right into game programming. I've wanted to get my head wrapped around object oriented programming for a long time. To an extent, using somebody else's engine will be the present I give myself once I've got this nitty gritty behind me. I don't want to get comfortable with anything before I've got the chops to appreciate it. So right now it's database management, search algorithms, and a refresher course in matrix algebra.

Foundational stuff for its own sake.

I'd recommend using Microsoft's .Net stuff (VB.Net, C# or whatever) for learning in.  It does hide most of the pointer stuff behind the scenes (like Java does) but that's not necessarily a bad thing.

I would recommend Java for learning OO principles but it's so overly verbose that sometimes I feel like working in it is just an exercise to your typing skills.  The .Net stuff is pretty verbose also but not nearly as bloated as Java since it came to life in a bit more coherent manner.

There are lots of .Net tutorials provided by MS and they do a good job of introducing the concepts in a way that showcases their uses because you are building real things as you go along.

And, as Stephen will be happy to point out, the XNA and Torque stuff is all .Net so that when you are ready to step up the complexity level you will have a base of familiarity to start from.  There is a lot to be said ego wise for getting something interesting done quickly and without a lot of effort that can go a long way toward making sure you don't burn out and the XNA stuff with torque looks like it will help you with that (Even if I'm personally not interested due to the licensing model for X360 development I do think it's a very useful set of tools).

I don't know how the Visual C# Express IDE compares to Visual Studios but even if it's severely gimped it will probably still be a pretty good for a free IDE.  Trust me on this, a good IDE can be all the difference in your 'fun' level while coding.

I would absolutely not start with C++ as your first OO environment nor would I use a 'scripting' language that's inherently ineffective (and may not even actually fully support the principles of OO).

[Stephen Zepp]

I'd certainly get behind C# as your first OOP language, and Java as a fallback. C++ maybe, but I'd agree with Murgos on this one--in a more streamlined language you can focus on learning techniques of OOP without fighting dozens of other issues that effective C++ programming requires.

[Yegolev]

Trying to teach myself C# with the Express IDE right now.  The main roadblock now isn't that I'm not a programmer nor the IDE, it's time.  The Express IDE does an enormous amount of shit, at least from the perspective of someone that, until C#, wrote 100% of his code in vi or Vim.  This includes, Korn, awk, perl, html, and php.  I have been using safari.oreilly.com for the dry-text part because all of the MS web tutorials seem to be for VB, and because I have the sub for business purposes already.

[pxib]

After a little research C#'s vigorously class-oriented structure looks like the sort of kick in the pants that I need. I'll change directions and dabble with it for long enough to decide if it's what I'm looking for. Thanks everyone.

[Krakrok]

nor would I use a 'scripting' language that's inherently ineffective (and may not even actually fully support the principles of OO).

Scripting languages are inherently ineffective? What?

[Stephen Zepp]

nor would I use a 'scripting' language that's inherently ineffective (and may not even actually fully support the principles of OO).

Scripting languages are inherently ineffective? What?

I'm not sure he actually meant "inherently ineffective" for all purposes, just for learning programming. For example, while TorqueScript is very useful, it's the worst possible thing you could use to try to learn OOP--like he says, not only does it not fully support all OOP principles (it's not an OOP compliant language), but it fakes some of the more useful techniques--which would be amazingly confusing for someone using it to learn OOP ;)

[Murgos]

nor would I use a 'scripting' language that's inherently ineffective (and may not even actually fully support the principles of OO).

Scripting languages are inherently ineffective? What?

Scripting languages are great for the things they are meant to do and, by their nature as scripting languages, inherently ineffective at pretty much anything else.

If you seriously want to put forward a scripting language as a good example of a learning platform for OOP then write something out that's rational and lets hear it.

[Krakrok]

I think we'll probably have to agree to disagree. My background is in Object Pascal (Delphi) and I'm not down with C++. Suffice to say I don't follow institutional software processes. For me programming is a means to an end, not an end in and of itself. I use whatever is required to get the job done fastest with an acceptable level of performance. Since I've been doing web development for 9 years or so now that usually comes in the form of a scripting language. After a certain optimization point it becomes cheaper to just throw more hardware at a problem.

[Samwise]

You wouldn't want to write a FPS in a scripting language, but that doesn't necessarily make it a bad choice for learning OOP.

Not that I've done much OOP in scripting languages.  Doing OOP with weak typing feels... odd.   

[Stephen Zepp]

For the record, the wikipedia article is pretty dated--it's extremely rare to see a game engine using an interpreted scripting language. I admit that the article linked isn't focusing on game engine scripting languages, but wanted to throw that out there.

[Murgos]

I didn't fully read the article before linking it - mostly I wanted the message that scripts (and thus scripting languages) are, basically, glue to automate tasks between programs.

Krakroks web example is perfect to display this even if he doesn't think of it that way.  The classic web paradigm of LAMP is using PHP as a scripting language to pass data back and forth between Apache, Linux and MySQL.  PHP is the script glue that makes that paradigm work.  I haven't followed PHP development in years but the last time I seriously looked at it (5. something, I think) they were just starting to incorporate OOP.  Is PHP great for what it is?  YES.  Is it actually robust enough so that a noobler can pick up the nuances of encapsulation, abstraction, polymorphism and inheritance?  Doubtful.  Is PHP as a language versatile enough so that by learning it he now has a useful tool that can be applied to any problem that needs solving?  Unfortunately, no.

I think it can be easily shown that learning C# or Java provides a tool that not only fully supports OOP but actually helps enforce good practices by it's very nature.  And that once learned can be used to accomplish any task that can be dreamed up.  Want to take your skills and work in embedded systems?  You can.  Want to work in Web Apps?  It's there.  Want to do big time consumer apps?  Lots of work there too.  Games?  Yep.  Etc... etc... etc...

An argument can be made that Perl and Python and a few others have advanced enough that they are now fully featured languages.  Fine, but then they aren't scripting languages anymore, are they?

[Stephen Zepp]

Solidly agree with you there, with a possible exception of TCL and a few of the others--which falls under your caveat of "maybe they aren't scripting languages anymore".

[Samwise]

I smell a silly semantic argument coming.   

My definition of "scripting language" has always been "Do I need to compile it before I run it?  No?  Is it at least vaguely procedural?  Yes?  And is it a little bit ugly? Okay, it's a script."

[Stephen Zepp]

I smell a silly semantic argument coming.   

My definition of "scripting language" has always been "Do I need to compile it before I run it?  No?  Is it at least vaguely procedural?  Yes?  And is it a little bit ugly? Okay, it's a script."

heh...in game dev at least, I view "script" as the driver of the car, and "code" to be the car itself.

Script> Insert key and turn
Code> hundreds of things related to starting an engine
Script> Watch the pretty needles and gauges change
Script> push on gas
Code> accelerate vehicle

etc, etc.

[Krakrok]

Is it actually robust enough so that a noobler can pick up the nuances of encapsulation, abstraction, polymorphism and inheritance?  Doubtful.  Is PHP as a language versatile enough so that by learning it he now has a useful tool that can be applied to any problem that needs solving?  Unfortunately, no.

I would posit that the indie game noobler doesn't care about any of those things. If they want to learn programming thats fine. If they just want to take their idea and make it into reality that is something else. The indie is all about gluing other people's components together into their idea. Writing object code from scratch is why it takes a million dollars and two years to make a low budget video game. A product cycle which is frankly laughable from my perspective.

[Samwise]

heh...in game dev at least, I view "script" as the driver of the car, and "code" to be the car itself.

Script> Insert key and turn
Code> hundreds of things related to starting an engine
Script> Watch the pretty needles and gauges change
Script> push on gas
Code> accelerate vehicle

etc, etc.

What you're describing sounds more like layers of abstraction, which is a property that's (almost always) independent of the language being used.  The fact that you're coding in C instead of Perl or whatever does not prevent you from having a single "turn_key()" function that does all the work (i.e. abstracts away the complexity) of starting the engine.

[Stephen Zepp]

heh...in game dev at least, I view "script" as the driver of the car, and "code" to be the car itself.

Script> Insert key and turn
Code> hundreds of things related to starting an engine
Script> Watch the pretty needles and gauges change
Script> push on gas
Code> accelerate vehicle

etc, etc.

What you're describing sounds more like layers of abstraction, which is a property that's (almost always) independent of the language being used.  The fact that you're coding in C instead of Perl or whatever does not prevent you from having a single "turn_key()" function that does all the work (i.e. abstracts away the complexity) of starting the engine.

Actually, what I'm describing is how Torque, as well as some other game engines integrate "scripting" with "coding" :)

Big drift from the original topic, I know ;)

[Murgos]

What you're describing sounds more like layers of abstraction, which is a property that's (almost always) independent of the language being used.  The fact that you're coding in C instead of Perl or whatever does not prevent you from having a single "turn_key()" function that does all the work (i.e. abstracts away the complexity) of starting the engine.

Except he's not talking about having a turn_key() function.  He's talking about having a script that sets up an environment for a second program.

Maybe the script just tells the program to turn_key(1), turn_key(2) and etc... but usually it's much more than that.  Like while using libraries a,b and f begin program with normal outputs to standard directories and files but dump debug information into the test directory files foo.xml, bar.xml and nuts.txt and log results into CVS.  Next take foo.xml and move it to localhost and set permissions so we can view it as xhtml and then take nuts.txt and parse it for warnings and errors, if there are errors print "ERROR at line x" and restart program with break at y and etc...

It's not really a program but it's much more than just ./my_program --option 1.

[Stephen Zepp]

/Agree with both Sam's concept of abstraction (although not in the way he means I think), and Murgos' points.

In game dev at least, script languages are used to configure, execute, and respond to c++ code. It's an "abstraction" in the sense that you are removing the game logic from the complexity of programming in a formally structured language--letting the c++ code handle all of the mundane but very important aspects of underlying implementation, while the scripter can focus on "getting things happening in his game".

Like Murgos implies (and illustrates, although not in a game sense), properly written c++ classes, when exposed and interfaced to a scripting language, allow the scripter to control execution and define operating states at an abstracted level of complexity/difficulty--or back to my analogy, the scripter just wants the car to start, he doesn't care about the possibly hundreds of execution steps required not only to simulate the engine, electrical system, transmission and other "game" systems, but also all of the more mundane instantiation, management, tracking, and other lower level tasks of the class itself.

Back to the topic at hand--both sides of the equation (scripting and programming) have their uses, and both (in a well engineered system anyway) deal with OOP, but for learning principles of OOP itself, a scripting language is probably not the first place to start. On the other hand, low level details of game object manipulation (while strongly OOP), is probably too complex as a starting point.

Languages like C# provide a really good mix of the two: fully OOP, yet a lot of the mundane programming details are handled for you as well, so it allows you to focus on learning OOP instead of learning game engine system development.

[Alkiera]

nor would I use a 'scripting' language that's inherently ineffective (and may not even actually fully support the principles of OO).

Scripting languages are inherently ineffective? What?

Scripting languages are great for the things they are meant to do and, by their nature as scripting languages, inherently ineffective at pretty much anything else.

If you seriously want to put forward a scripting language as a good example of a learning platform for OOP then write something out that's rational and lets hear it.

As someone who's written an entire ray tracing program in OO Perl, I feel qualified to say it can be done.  Also, Perl doesn't have near the mathematical performance of a real compiled language.  On the other hand, I mostly did it as a learning experience for OO Perl.  You can do some neat things with it, and there were things I got away with that other more strongly typed languages make annoying.

If anyone is interested, I can link the site with my result images.

Not that I've done much OOP in scripting languages.  Doing OOP with weak typing feels... odd.   

It actually works quite well, at least in Perl.  A given reference doesn't care who you think it is, as long as it can look up the member function you're trying to find.  And without typed parameters, there's nothing restricting you from, say, passing a Point instance or a Vector instance into a function, if they both have members that are x(), y(), and z().

Aside from type checking(which you can do if you feel the need, it's just more work), you can write your objects with even better internal security than C++ or Java provide.... wrap internal variables up so tight even your own members need to use accessors to get to them.

I agree that it might not be the best start for someone trying to 'get' OOP.

--
Alkiera

[Morat20]

As someone who's written an entire ray tracing program in OO Perl, I feel qualified to say it can be done.  Also, Perl doesn't have near the mathematical performance of a real compiled language.  On the other hand, I mostly did it as a learning experience for OO Perl.  You can do some neat things with it, and there were things I got away with that other more strongly typed languages make annoying.

To paraphrase one of my more annoying instructors -- among any complete computer language (and many scripting languages are), if it can be done in one it can be done in all of them.

The only question is how much effort are you willing to put into it? It can be done -- but it's generally easier/faster/more efficient in some languages as opposed to others.

Still, there's nothing wrong with saying "Okay, I'm going to teach myself this language and these difficult concepts by doing something really challenging in it" -- as long as you bear in mind it's not going to be easier. I learned C# (after several years away from OOP, and two years of doing just web-DB development) by writing a GP data-miner with it. Among other frustrations was the painful relearning of the difference between "deep" and "shallow" copies. I still can't believe how much time I wasted until I figured that one out, and how stupid I felt for forgetting something so important.

[Samwise]

Not that I've done much OOP in scripting languages.  Doing OOP with weak typing feels... odd.   

It actually works quite well, at least in Perl.  A given reference doesn't care who you think it is, as long as it can look up the member function you're trying to find.  And without typed parameters, there's nothing restricting you from, say, passing a Point instance or a Vector instance into a function, if they both have members that are x(), y(), and z().

Aside from type checking(which you can do if you feel the need, it's just more work), you can write your objects with even better internal security than C++ or Java provide.... wrap internal variables up so tight even your own members need to use accessors to get to them.

Oh, I totally get that you can do it.  I've done it in a number of interpreted languages and the conventions are pretty similar.  It just wigs me out is all.     Compile-time type-checking is a crutch that I've grown very accustomed to.  I'd even go so far as to say that for someone who's first learning, having that option of being able to hit "compile" and be alerted to obvious mistakes might make things easier.

[pxib]

Yay.. C# is fun and easy.

Object oriented programming is a lot like Lisp, only with more structure. Since Lisp is how Jesus codes, I am well pleased... and yes, it's nice not to have to screw around with pointers. Thanks guys!

[Morat20]

Yay.. C# is fun and easy.

Object oriented programming is a lot like Lisp, only with more structure. Since Lisp is how Jesus codes, I am well pleased... and yes, it's nice not to have to screw around with pointers. Thanks guys!

There are times when I'd give my left foot for pointers -- I want to do fast swapping of data structures (often very LARGE data structures) and it'd be easy as pie to flop two pointers, but instead I have to implement some pain-in-the-ass recursive copying scheme to get it to work properly.

But most of the time, I enjoy not having to play "Hunt the place where I treated an address like a variable" through god knows how many thousands of lines of code.

[Murgos]

You can do that (pointer tricks) in C#.  You just have to put up with it bitching at you.  The fact that you have to be very explicit about it keeps you from abusing the mechanism except when needed and makes it very easy to focus on those few areas when debugging.

I took over garbage collection in one project because I was being very aggressive with memory allocation and it [the native garbage collection] just couldn't keep up.  The functionality, and danger, of C/C++ is there, it's just kept away from plain view.

[Morat20]

You can do that (pointer tricks) in C#.  You just have to put up with it bitching at you.  The fact that you have to be very explicit about it keeps you from abusing the mechanism except when needed and makes it very easy to focus on those few areas when debugging.

I took over garbage collection in one project because I was being very aggressive with memory allocation and it [the native garbage collection] just couldn't keep up.  The functionality, and danger, of C/C++ is there, it's just kept away from plain view.

Really? Now that I didn't know, but I was learning pretty much what I was needing (the down side of "I'll learn this through a project I want to do") and not a lot more. It all worked out, once I got the deep-copy stuff working correctly for my trees.

[Roac]

Really? Now that I didn't know, but I was learning pretty much what I was needing (the down side of "I'll learn this through a project I want to do") and not a lot more. It all worked out, once I got the deep-copy stuff working correctly for my trees.

Yes.  You'll find it in some open source examples (only place I've seen it so far - books and MS examples avoid it) but the compiler will loathe you for stepping outside managed code.

[Samwise]

I haven't done anything with C#, but I assumed it was mostly like Java, where everything is really a pointer (with "." instead of "->" to follow them).  What's this "no pointers outside managed code" business?