Link Bar

Home | Games | Programming | Tutorials | Donate | Legal (These are mostly empty right now. Placeholders!)

warning code

This website contains adult content.

Thursday, February 23, 2012

Day 9: The Alexandrian Solution

After reading some more about the Playskool programming that is RPGcode, I grew despondent at the idea that anything I learn here is going to need to be re-learned or un-learned whenever I get my Big Boy programming in gear - because some things will work and some things won't, and I'll probably have to learn which is which one by one.  Hmm... let me think for two seconds here.

OK, I'm not doing that.

So has all this been a waste of time?  Absolutely not.  I've learned a lot in the last eight days, not only due to the reading I've been doing but also by playing around with things.  I now have a much clearer picture of what goes into a video game.  Look, here it is:

Green means "I get it."  Purple/Blue means I'm fuzzy on it.
Red & gold mean I'm fucking clueless.

So yeah.  There's this big, mysterious hurdle right there in the  middle, and it turns out it's the part that actually holds everything together.

I don't know how to untie this Gordian knot - at least not in any way that I would consider to be an effective use of my time - so I'ma straight-up cut the fucker in half.  I'm just gonna learn how to program.  It's a valuable skill, it will help me accomplish my goals, and it's bound to be less time in the long run.  I feel farther from finished game, but I know I'm closer to good game, and that's better to my mind.  However, this means that my daily progress is going to be much less interesting.  Actually, looking back... maybe not.

I'll probably also be able to research the things I'm interested in more directly, and take better advantage of Stack Exchange.  We'll see how this goes.

...ahem.

Doop a doot doo.

What?  You're still here?  Oh, right.  Progress.  Y'know, that thing I said I'd do a little bit of every weekday.


There was a minor tab explosion and I took a walk around the internet.  I learned a little bit o' FORTRAN way back when I was doing undergrad theoretical physics research (ugh, I let the professors write my bio and now it's stuck like that forever... that's what I get, I guess), so this shouldn't be too difficult.  Although I bet it'll be much harder than writing a program that brute-forces a square root approximation and laughs at you if you enter 1 or 0.  From poking around the 'tubes, it's looking like my best bet is C++.  Python seems easier, but I'll just have to learn C++ after it, anyway; and I bet I can learn Python faster after C++ than the other way 'round.  DarkBASIC could also be easy, there's a free version that runs only on ads, but I have little mini-versions of the same issues I've got with Python, and I don't want to wind up in any kind of legal limbo if I actually make something salable (or just have to do it all over in C++ anyway, which may or may not be worse).  Anyway, here's the best of what I've read today:

  • Stack Exchange:  What are good games to "earn your wings" with?  Several perspectives on how to go about learning game development from scratch.  Lots of agreement, and well-articulated disagreement.
  • The Game Programming Wiki:  Beginner FAQ.  More grounding on exactly what the Hell I'm getting myself into.  Getting many sides of the same issue is really helpful; repeatedly seeing the same ideas reinforces those ideas, and also "filters" some of the mere opinionating because it isn't repeated.
  • TGC:  Newsletter.  These guys sell software (they made DarkBASIC), which does not interest me.  But they have a newsletter, which does interest me.  So I signed up for it.  Hope that doesn't bite me in the ass... now I just gotta make sure I read it.
  • Nisan & Schocken:  The Elements of Computing Systems.  Zach once explained to me how computers work at the transistor level.  I understood that part.  I then asked him how you get from "physical logic gate" to "game on screen," and I was unable to comprehend his explanations (due in no small part to the fact that we were drinking that night).  This is a course on pretty much exactly that.  I now have great weekend filler for twelve weeks!  (Fourteen, if I stretch it.)  Here's a sweet video with one of the authors explaining what the book/course are about in more depth:


At Zach's behest, I also downloaded everything I need (I hope?) to use C# for xna.  That's gonna be my fallback if I suck so bad at C++ that I hate it.

2 comments:

  1. The trick with C++ -- the biggest pain in the ass -- is figuring out what libraries you need to build your game and linking them properly, which usually involves creating a makefile, which is its own subset bullshit language.

    Anyways, if you're deadset on C++, a good starter graphics package is always SDL (http://www.libsdl.org/). Android actually uses a subset of SDL for its handheld apps, meaning it's in use by a heckuva lotta people.

    When you're starting off programming, focus more on control structures and layout and formatting and naming and things like that than on particular uses of libraries -- that's what APIs and wikis are for. The basic rules of thumb (rule of thumbs?) are the most important -- RAII, good function and class delineation, spacing, OOP.... those are the most important.

    (RAII, by the way, means Resource Acquisition Is Initialization. In C# and other garbage-collector-controlled languages it's not an issue, but in C and C++ you have to manage your own data. What it means, roughly, is that whenever you acquire a resource (memory) you initialize it -- set up all the starting parameters and make sure it's in use -- and whenever you destroy the object you've initialized you free the memory. Memory in, Memory Out.)

    (OOP stands for Object-Oriented Programming, and it's the main reason people use C++ instead of C. It sure as hell isn't for C++'s nightmarish templating system. OOP is the most logical style of programming structures and it basically means that you have objects, which represent, well, objects. Objects have members that define what they are, and functions that define what they can do.)

    ReplyDelete
  2. Thanks for the tips, Z! I read your comment before I headed out this morning, then again just now. It makes much more sense now that I've actually done some coding, even if it was Level Teething Ring. :)

    ReplyDelete