Day 31.5: Employment!

I didn't want to say anything about this, not out of some irrational fear of jinxing it, but for the very practical and rational reason that I didn't want to risk saying something foolish and thereby screwing it up... but I am employed now!  In accordance with the prophecy, I shall be reducing my output to Mondays and Fridays.  So the next post will be Day 35, this coming Friday.  Hooray for gainful employment!

Day 31: More learning, more coding

Still working on Solitaire.  Also realized just now that I completely forgot to update on Friday.  Whoops!  My best friend came down from out of town to hang out, and it slipped my mind until just now.  Still, losing out on one day in thirty isn't exactly terrible...

Solitaire still isn't ready, though.  I've beefed up the header some, and have read further in a few of the tutorials, but it's still not working.  So, more on that as it develops.  Later!

Day 29: Solitaire-ish

Nearing 300 lines of code in Solitaire.  Mainly for how the interface is going to work out, since I haven't programmed card images or anything.  But it's a proof of concept!  I can make text-based Solitaire, dammit!

Just see if I don't...

You start the game in a room with a dealer, and the dealer can shuffle the cards, and that's about it right now.  But soon... soon... I shall be able to have the dealer deal the cards so that I can play the game.

And by extension, so shall you be.

Day 28: But I am le tired...

I did Google-maps'ed it, and between walking South to my job offer and North to the testing facility, I walked 16 miles today.  I got home and was beat and laid down for a nap, then just woke up.

Well, obviously I needed the sleep, and I'm going to be up for at least a couple hours, but it's already past midnight and I'm just poking around in Solitaire anyway.  So this is here for "something up around midnight," there should be something more substantial tomorrow evening.

Day 27.5: Two steps back...

Internet went down last night.  I tried to access the blog around 8, and that's when I first noticed it was down.  At 10, it was still down, so I went to sleep... because I had a job interview this morning!  (Cue excitement and applause!)  Just got back and the 'net is back up, now I have to go do the drug test.

You guys didn't miss much, honestly.  More reading, on how classes are made up of other classes, and can inherit things from parent classes, and so forth.  I'm learning (slowly) how things can be arranged into gangs of four, and how two-dimensional arrays can be "faked' from one-dimensional arrays, and it's all very fascinating and giving me lots of ideas.  But I'm having trouble scaling it down to the point where I can actually write the code; so once I've got that hacked, I'll be able to explode it up from there.

So... about that code-writing... the thing I wanted to be doing on day 26 (Monday)...

So, let's see... I told myself I'd have to start over at least six times.  If I work on a Solitaire game now to figure out objects, that will be my fourth time starting over (the RPG Toolkit world, Noob Game, Hula, and now this Solitaire game).  This is within acceptable bounds.  And then I can put objects in Hula.  And then I will know how I should have put them into Noob Game.  Maybe I'll have to re-do that, as well... Noob Game 2.0.  Then once I've got Noob Game's objects up and running, I think that might be at least the skeletal structure of an engine... so if Noob Game:  Objects is now the skeleton of an engine (and my fifth time starting over), then the game I was making with RPG Toolkit will be the sixth time starting over when I give it its own skeletal engine from scratch.  Except now I will know WTF I am doing.

OK, this is all within tolerance so far.  I'm leaving now to take the drug test, but it's across town and I'm walking, so that will eat up my time well into the evening.  When I get back, it will be time to work on Solitaire by coding objects for it.  If I don't get anything ready before I go to bed, I'll at least post to say so (giving at least the appearance of maintaining a schedule, and hey, I'll at least have learned a thing or two at any rate).  That gives me Thursday to also work on Solitaire, and Friday too, and then we'll see what's up by the weekend (hopefully I'll be scheduled for the orientation next Tuesday!).

Day 26: Object-Oriented Programming

So I pulled up a bunch of stuff to read on OOP over the weekend.  I started with Wikipedia's page on object-oriented programming, and when I got to methods, I thought, "Gee, this looks important.  Wonder what it is?"  New tab.  That article fairly swiftly mentions classes, so that meant another new tab.  And somewhere in there was a mention of UML, which term I did not recognize, so I checked it out for good measure.

Hmm... with the other pages I've got pulled up (introductory lessons for C++ from gillius.org, tenouk.com, and desy.de which looked interesting, then this from cplusplus.com and that from intap.net), this was starting to look suspiciously like a wiki walk.  I started with classes and read it all the way through, then back up to methods and finally into OOP generally.  Whuff, that's already quite a bit of reading.

What's more, it's informationally dense, too.  Check this out:

In a language that supports inheritance, an abstract class, or abstract base class (ABC), is a class that cannot be instantiated for it is either labelled as abstract or it simply specifies abstract methods (or virtual methods). Abstract classes specify virtual methods via signatures, that are to be implemented by direct or indirect descendents of the abstract class. Before a class derived, directly or indirectly, from an abstract class can be instantiated, all abstract methods of its parent classes must be implemented by some class in the derivation chain.
 - Wikipedia on abstract classes


Now, I had to read that a second time to really get it.  But now that I do, good Lord, is that last sentence important to remember!  And the whole thing is like this, pretty much, for a beginner like me.


I got to Chapter 3 in the tutorial at gillius.org and was referred to a page with information on dynamic memory allocation (covered way back in reg'lar C++, and now taken for granted in object-oriented C++) for not knowing about the "new" and "delete" commands.


And after more reading like this, it's becoming clear to me that OOP is much more complicated than I thought it would be (...surprise?).  I guess I'm back into a reading phase, then, since I'm not really sure quite how to start coding my objects.  And by "start," I mean how I want things to be organized in the grand scheme of things so that I know what classes I'll have and what individual objects will belong to what classes and so on, all of which it looks like I'll need to plan out in some manner of detail beforehand - oh, gosh, this means I need a Big Boy design document.  OK, so I guess that's the next step before I get objects into Hula, and then I can worry about instantiating the items in the game once I've got some classes & such described from which to draw when representing the game world.  Well, let's just start with one, like in Noob Game, and then blow it up to two, and then many, and we'll see where that takes me.


Oi, I love reading and learning and filling my brain with exciting new things... but this is tough sometimes!  Zach, things are certainly "spiralling out of control naturally," just like you said they would.

Day 25: TECS Project 2, and Arguing on the Internet

Arguing on the internet is like competing in the Special Olympics:  it doesn't matter who wins, you're still retarded.
 - Internet Wisdom


I was playing an online game last night, when I got into quite the disagreement with another guy in my group.  I casually mentioned that I was teaching myself how to program, and he offered his help as a professional programmer, which was very nice of him to do.  He suggested I dive right into OOP, and asked what I was doing now, and I said I was learning some C++ with the help of a friend (Zach) and going through TECS to learn how computers work from the bottom up.  Then came that fateful moment where someone says something which maybe they don't really mean, but then they stick to their guns and everything blows up in everyone's face.

He said, "No, you should start with a top-down approach.  Top-down is always better than bottom-up."

I added emphasis to "always," because that was the one word that stuck in my craw.  I am a philosopher, and I know from my philosophical training that the word "always" should almost always be preceded by the word "almost."  So I said, "Not necessarily."  To which he responded, "Yes, necessarily.  I do this for a living, I know what I'm talking about."

Oh, boy.

So I offered to cook him up an example of a situation where you'd want a bottom-up approach instead of a top-down one, and he was receptive.  I went on to say that if you wanted to simulate an ecosystem but don't know how it works, you should start at the bottom and tweak the parts until the high-level interactions look acceptably like what you see in reality.  I thought this would be a knock-down argument, since ecosystems do in fact emerge from the bottom up and not from the top down, and designing an ecosystem from the top down requires precisely the sort of understanding which the example stipulates to be lacking.  He replied that no, a better way would be to simply simulate all the high-level interactions without worrying about the bottom-up organization, because the internal structure doesn't matter so long as the output is correct (and fair play to him, that latter clause is true).  Having sprung my trap, I pointed out that this presupposes exactly the understanding which is missing from the example - in other words, if you could design the simulation accurately from the top down, then you've already got what the simulation is for.

It gets better.

Then he says, "Well, that's just one specific example.  In general, the top-down approach is better for achieving professional results."

I replied, "Wait, you just changed the subject!  You said that top-down is always better than bottom-up, which means that 'just one specific example' of bottom-up being better is all that's needed to show that top-down is not always better."

"Fine, but in a professional environment, you've still got to do things from the top down."

"But I'm not doing this in a professional environment!  I'm doing this as a hobby."

"Top-down gets results faster, though.  Working bottom-up usually engages you in a bunch of aimless wandering that doesn't get anything done."

We then discussed the virtues of curiosity-driven exploration and the importance of enjoying one's work, and it was all very edifying.  There was a happy ending, too.  I asked him if he had any hobbies (he does:  writing), and then asked him how many hours a week he spends working with his agent and trying to get published (answer:  zero).  Then I told him that he'll never get a good publishing deal without an agent to help him tweak his book for maximum marketability and so he's never going to make it as a professional writer with his current approach - and said that that's how he sounded to me during the last ten minutes.  Then he understood where I was coming from, and now we're friends again.

Jeez, some people (and in case it wasn't clear from my opening quotation, yes, I know that I am some people, too).

In Other News:  I built the half adder, full adder, 16-bit adder, and incrementer.  Oddly, the incrementer gave me the most trouble of the four, but then I had a flash of inspiration and facepalmed at the obviousness of the solution.  I still can't hack the ALU, though, and apparently that's the centerpiece of the virtual machine I'll eventually be building.  Moreover, it's not like I tried a bunch of different things and just kept failing; I don't even know where to start.  My instinct is that I'm intimidated by it at some level, probably because of all the different pins and the fact that it's just a black box on the inside and I need to specify everything that goes into the box.  But in the greater scheme of things, knowing how to build an ALU is tangential to my long-term goals at best, so I'm skipping it and moving on for now.  I gave it an honest effort (I re-read the chapter, and I'm a little clearer on what it's supposed to do, but no clearer at all on how I need to get it to do that), and maybe I'll come back to it after the next chapter or two and see if I have any epiphanies.  And anyway, I'm repeatedly finding myself thinking, "This would be so much easier if I could just write the function of the chip in C++ instead of the HDL," which A) means that I'm learning to think like a programmer, if nothing else, and B) shows that I still have a ways to go, because I wanted to use software to tell the hardware how to do what it does on its own.  But hey, at least I realized that.

OK, so that's week five down.  Over the weekend, I'll be reading up on OOP and classes and such, and Monday should bring another substantial update to Hula.  Y'all have a good one!

Day 24: "Hula" Beta Update

New and Improved Hula beta here.  Source code below the jump.

Notes:

• Fixed levels, thanks to Zach's excellent suggestion.  Now working as intended.
• Added NPC "The Janitor."  Still no NPCs in the world, though.
• Finished the introduction blurb, smoothed the transition into the game proper.
• Refined the "consult device" mechanic; still not quite sure how I want this to work, but it's backburner material for now.
• Put fish in the world for the player to mine, one per location (except inside the CoW or the Inner Hoop).
• Added a "hunger" stat:  each action adds 1 hunger, player receives suggestions to eat at 90+ hunger, loses health at 101+ hunger (eating a fish restores all health and removes all hunger).
• Sneaking through the CoW's armory now provides ten bullets to the player.  I'll make it a one-time thing later, but I'll need infinity bullets for future playtesting.
• There is now an empty pistol at the starting screen.
• Note to self:  not quite sure if cover is working like I want it to (even in the rudimentary build I've got at the moment).  Probably not.  Display auxiliary counters to check.

Zach's been encouraging me to look into object-oriented programming, and I've been putting it off because I have so many good ideas for my simple conditionals and so I wanted to just run with them while the creative juices were flowing.  But I am now thoroughly convinced that OOP will make NPCs way the Hell easier to handle, as I've been thinking about just exactly how to handle them without it, and it seems like a terrible exploding brute force problem.  So I'm going to read up on that over the weekend, and we'll see what I've got by Monday.

OK, that's all for now.  Tomorrow:  back to project 2 in TECS.  Ciao!

Day 23: TECS, Project 2

Holy carp, you guys.  Getting a computer to do math is hard.

Project 2 looks pretty simple at the outset:  build a half-adder (which I get), a full adder (which I also get), an adder (which I kinda get), an incrementer (which I so get that I almost forgot about it), and an arithmetic logic unit (which I don't get at all).  Something about that ALU is just irreducibly magical to me right now, and I'm not quite certain why.

I gave up and went to sleep, resolving to get up in the morning and take another crack at it.  I had hoped that the magic would go away, perhaps by more magic, but no dice.  I'm beating my head against the wall right now on this, which means it's time to do something else and then come back to this later.  If this were one class among many, I'd be tempted to "look for outside inspiration" (i.e. cheat); but I am under no such constraints, and that would simply defeat the purpose of the intellectual exercise (i.e. to learn).  So I'm calling it quits for now.

After today's errands, I'm going to take another pass at Hula and update the beta (assuming I don't just break it over and over again).  So that's something for day 24, and on day 25 I'll take another crack at project 2 after I've had some time off to let my failures sink in and learn some lessons from them.  OK, plan is planned, now execution just needs to be executed.

Day 22: "Hula" Open-Source Beta!

I got the "help" button working.  Turns out, back when I had thrown a "}" in at the end (because one was missing), I should have put it before the Help subroutine, because that's where it was missing from.  But I put it in after the Help subroutine, which subordinated it to the Inventory subroutine.  Dammit.

I don't want to admit how long it took me to figure that out.

I also think I've figured out what's causing playerLevel to start out at minus two billion, even though I know by math that it's supposed to start out at zero.  See, the exact player level on a new game is -2,147,483,648.  Recognize that number?  Yup, it's -2³¹, the lowest number that can be displayed in 32-bit number-crunching.  I wanted "XP to next level" to always be twice what it was the last level - which is given by the function:

[LEVEL] = log₂(([XP] + 1) / 2) +1

At zero XP, then, you're level zero, because log₂ of 1/2 is -1 (and then add one to make it zero).  Take one action, and BAM, you're level one.  Two more actions and you're level two, and so on and so forth.  For some reason, though - probably because of how the logarithm function works under the hood - it's making it (for all intents and purposes) negative infinity.  This could be caused by the fact that I'm calculating the binary logarithm as "log₂n = log₁₀n / log₁₀2," which is mathematically correct but might be causing the 'puter to throw a fit.  Hmm.

Anyway, that's a headache for another day.  Here's the Hula beta, source code below the jump.  Also, I learned how to make the binary logarithm function here on Stack Overflow, since Microsoft decided to excise it from cmath.  Because who would ever want to take a binary logarithm of something?  Huge dorks and lesser dweebs¹, that's who.

Notes:
1.  I swear by the stars that I got this from Strong Bad, but I can't find it right now.

Day 21: "Hula" in development!

...and already in tiny Development Hell!

Alert Readers and long-time fans will recall that, like, three weeks ago, I came up with a cockamamie scheme to make a simple game with the little bit of knowledge that I had at the time.  Of course, like all my ideas, it worked perfectly in my head and then immediately went to Hell as soon as I started trying to make it happen.  Well, now that Noob Game is launched and complete, I figured I could just make a Big Boy Hula (to Noob Game's Playskool) and thereby force myself to make legit versions of all the things I conveniently worked around in Noob Game.  For example, rather than having exactly one NPC per area and governing all aspects of NPC interaction based on player location, I will need to figure out a way to make "real" NPCs which can be present in arbitrary quantities.

I'm some 300-odd lines of code in, after drawing up a little design document over the weekend and coding like one of those typewriter monkeys you hear about in misunderstandings of probability and the infinite.  I've got a game world, experience mostly works (but you start at level minus two billion, which should be zero, and then proceed to level one as intended), and all the buttons work except the "help" button which tells you what the buttons are.  But whatever.  I'm continuing to learn, and that's what counts, right?

Tomorrow, I'll be reading the full chapter 2 from TECS at the temp agency, and either I'll start on the project or I'll tinker around some more in Hula and put up a public beta.  Fun times!

Day 20: "Noob Game" launched!

Early update today, since I stayed up writing my tutorial.  Feels good to be ahead of schedule for a change!  Now if only I can find some work today...

Noob Game can be downloaded on the free right here!  Below the jump is a tutorial on how to write this game (or something like it) all by yourself in C++.  But be warned:  the source code contains spoilers.  Because I know you're super-concerned about those.

GAMES?!

Indeed, games!

This is my central game download page, where you can find all the games I've made.

Noob Game:  This is the first game I ever made all by myself.  It's short & shitty, but it's got all the right elements for a game:  NPCs, dialogue, levels, and quests.  Can you slay the vicious troll of Pro Mountain?  Will you anger the gods and live to tell the tale, venturing forth into the Wild Blue Yonder?  Or will you be whupped soundly by the Noob Trainer and perhaps killed by a guard for attacking a civilian?  YOU DECIDE!  (Note:  the link is to a naked .exe file on Dropbox; your 'puter may turn up its nose at it, but I assure you that there are no viruses).

More coming soon!

Day 19: A quest! And a world!

So I recoded everything from scratch in a new project called "Noob Game," rather than keep everything in "Hello World."

You start in Noob Camp and can talk to the Noob Trainer, who gives you a quest to take some Noob Shit to Noob Town.  If you keep trying to talk to the Noob Trainer, he tells you to get going.  You can then turn the Noob Shit in to the Noob Civilian, who gives you a gold piece.  Now you're on a first-name basis with the Noob Trainer!  That's some status right there!

The source code is beneath the jump, for anyone who is curious and/or wants to compile and play this pile of a game before I "officially" release it.  There are still a few bugs, like levels don't work right (also, attacking is a lie and does not work), but I have ideas of how to fix them and just wanted to put something up on the blog before midnight.

EDIT:  Uhh... finished the game?  Compiled and released before midnight.  Lots more quest, figured a couple neat new things out, posting a tutorial tomorrow.  Who knows of a nice free place to make .exe files available for download?

DOUBLE-EDIT:  Aaaaand... BAM!

Day 18: A game, at last!

It's not much, but I have the rudiments of a game here, now.  Thanks to Zachary's superior tutelage, I now have a game with a functioning victory condition, failure condition, and means of quitting.  You can't save, or talk to anyone, or do anything besides win/lose/quit... but still!  I have something functional here, and now it's just a matter of scaling it up until I get something worth distributing.

For those of you playing along at home, this is how Noob Game works (so far):
#include "stdafx.h"
#include "HelloWorld.h" //this header is empty at the moment, but I have a feeling I'll be using it eventually
using namespace std;
int _tmain(int argc, _TCHAR* argv[]) //this is the main function!
/* If I'm reading it right, the main function is simply an integer (albeit a really, really big one in binary).  What this means is that any possible game state could also be represented as an integer, Library of Babel-style, such that there is a set of integers which in aggregate represent all possible game states.  Whoah. */
{
cout<<"One Man Show"<<std::endl;
cout<<"Welcome to Noob Game.  Enter 1 to win, 2 to lose, or 3 to quit."<<std::endl;
char choiceOne[100];
std::cin.getline(choiceOne,100);
if(choiceOne [0]=='1'){
std::cout<<"You win!  Thank you for playing!"<<std::endl;
}
else {
if(choiceOne [0]=='2'){
std::cout<<"You lose!  Please play another time."<<std::endl;
}
else {
if(choiceOne [0]=='3')[
std::cout<<"You quit!  Fuckin' quitter."<<std::endl;
}}}
std::cout<<"The game is over.  Enter anything to close."<<std::endl;
std::cin.getline(choiceOne,100);
;
return 0;
}
And that's it!  I have extra comments in there & stuff, but I don't really care about that on such a small program.  I compiled it and ran the .exe on my computer many times!  It works!  Well, entering "4" or anything else besides 1, 2, or 3 will simply advance to ending the game, but as far as I'm concerned right now, entering unacceptable input is a failure condition.

I'm working on a replay module right now; I'll probably have to learn something else to make it work the way I want to, since I can't use "goto" any more.  Or at least shouldn't...

Anyway, even that was the result of an embarrassingly long session of poking, prodding, and just trying different things.  I'm going to go back to doing that now; just wanted to share that I've actually got something!  The simple fact that I'm using a program I created myself, no matter how rudimentary, is giving me a bit of a rush.

Day 17: Program runs!

Well, after much hemming and hawing, I finally sat through the MS Visual Studio tutorial and followed along instead of just watching it.  Within minutes, I got this:

Fig. 1  A window that asks for a 1 and everything!

It works!  Working code!  But then when I entered "Hot cha!" as you can see above in Figure 1, I got a run-time check failure - apparently, some stack around the memory of "myLine" was corrupted.  I can Break or Continue, and I don't know what those mean.  Glad I can JFGI before I decide!

OK, I didn't find anything in two minutes and I'm too excited, so I clicked "break."  Apparently, breaking things is the wrong thing to do.  I don't know how I could have possibly known this in my previous life experience.  Now I can't close the window.  I ctrl+alt+deleted and tried to end the process, and it just won't die.

I was all set to reboot, and then VC++ asked me if I wanted to stop debugging when I closed it.  Then the window closed on its own.  Not spooky at all.  This magic box is haunted.

Back up and running, and the machine tells you you've played even when you press 2.  Hmm... I thought that maybe that "if(myLine[100]=1" bit might mean "if it's true," so I tried putting the 1 in quotes, and got, "1>c:\users\d\documents\visual studio 2010\projects\helloworld\helloworld\helloworld.cpp(23): error C2440: '=' : cannot convert from 'const char [2]' to 'char'; 1> There is no context in which this conversion is possible."  That's at least intelligible, but it doesn't fix my problem.

OK, that's it for today.  I also did a bunch of art stuff, but it's sketches at this point and nothing really presentable.  Toodles!

Day 16(+1): Oops!

It got to midnight last night before I really knew what time it was, and at that point I didn't have time to write a post.  Sorry about that.  I also had lots to do today, but now I'm done.  So this is what's up with yesterday, and there ought to be something up about today's doings later on this evening.

Yesterday:  trying to get SDL to work.  Lazy Foo says that if I get an error, I probably skipped a step.  I double-checked to make sure I didn't skip a step, but I don't know, maybe I'm glossing over the same part each time and then forgetting that I did it.  That could also be happening.

I also read the lecture notes for Chapter 2 in TECS.  Whooole lotta math in there, glad I had some calculus from my physics days or some of them thar numbars would've really screwed me up.  Also, getting a clearer picture of how a computer does so much math so fast.

OK, time to get down to work.  Err, play, that is.  Hobby?  We'll go with hobby.  Time to get down to hobby.

New look!

I don't know why I keep going for green, since orange is clearly the color of awesome.

Anyway:  Like?  Dislike?  Suggestions?

Site is easier to read now, which also means easier for me to stare at, and has a search module & tag cloud (which involved tagging all my posts retroactively).  Hooray!  I accomplished all my weekend site update goals!

Day 15: Wiki Walking

A Wiki Walk is a train of thought that left the track and is Riding into the Sunset. When going for a Wiki Walk you know where you begin, but no one knows where you'll end. Are you a Mad Scientist building an orbital death ray? Well, too bad, inspiration struck and now it's the world's biggest dancing dish washer with a fully adjustable cup holder. You want to have a serious talk about the Middle East? Within ten minutes you'll be arguing whether Darth Vader could take Gandalf in a fight. Just want to check the Rule Of Cool page? Before you know it you're adding examples to Bungling Inventor. You, my friend, have just had a Wiki Walk.
 - TVTropes:  Wiki Walk

Bit of a late start (that's my King Understatement for today).  Well, on writing this entry, at any rate.  I've been reading and organizing ideas all evening (more on the ideas later).  I'm starting to see the wisdom in the Chinese proverb, "Better to be deprived of food for three days, than tea for one" (and that's from before researchers scientifically established the health benefits).

I finished project 01 in TECS.  I'm going to keep posting my progress through the course by chapter and project,  because otherwise I'll probably fall off the ball and publicizing my progress increases my commitment to it.  But I'm stopping with the "step-by-step herp-a-derp" because it probably won't be helpful to anyone just getting started any more, and so will just amount to cheating for anyone who's actually taking the class.  If I am struck by some kind of inspirational tangent, I'll blog about that, but the focus will be on where the tangent ends up and not on the project/chapter itself.

I also poked around quite a bit on LazyFoo.net.  This guy's got a load of tutorials ranging from setting up libraries and displaying images to game saves and joysticks, and articles covering topics ranging from the nature of pixels to making a level editor.  Like any good neophyte, I'm gradually coming to terms with the fact that the more I learn, the more I'll be able to appreciate just how much I have left to learn.  But just as my knowledge of computer systems becomes clearer and more concrete the more I do it, so shall my programming knowledge grow.  In this vein, Lazy Foo's page on Nerd Girls:  The Game also has a very illuminating (not to mention humbling!) list of "Ten Things About Game Development They Didn't Teach Me in School."  I have a feeling I'll be learning a lot from this guy.

So yeah:  ideas!  I think a happy medium between "game I can start out building" and "game I will have fun playing" is a card-based game.  Obviously, I'll have to learn how to code a complete game of Solitaire before I can make my own crazy variation on it, but Solitaire (from what I've read) is a good one to cut your teeth on.  We'll worry about the specifics of what would make this more fun to play than any other free version of Solitaire later - y'know, after I've actually made Solitaire and can get a feel for exactly how out-of-control my feature bloat has become.  But I spent lots of time between my readings drinking green tea and thinking very explicitly about how to get from A to B one step/feature at a time, and I'm excited to see how it takes shape!

OK, I seriously have to get to bed now.  I've got a busy weekend ahead of me, what with the layout stuff I want to do and getting a head start on content for next week.  Y'all have a great one!

Day 14: Eureka!

I took my homework with me this morning when I went to look for work.  This was a good decision, because I only had like ten pages left to read in Phantoms in the Brain, and I needed something else to do besides all the paying work the temp agency didn't give me.  I had ten more chips to build:  DMux, Not16, And16, Or16, Mux16, Or8way, Mux4way16, Mux8way16, DMux4way, and Dmux8way.  I built the first six, and half-decided/half-succumbed to saving the last four for when I was able to make sure that the first six actually worked, despite the roll I was on.

Last night, I built a multiplexor by a rather circuitous and wasteful, albeit functionally intact, method.  But a two-way multiplexor, using one selector input to choose between two other inputs, only has an eight-value truth table when expressed propositionally.  Mux4way, on the other hand, has two selector inputs and four primary inputs (a-d), resulting in a 64-value truth table that still comes out only 1 or 0.  Don't even get me started on Mux8way!  I realized that yesterday's approach simply wasn't practical, but was stumped as for how to proceed.

Necessity is the mother of invention, and I invented an epiphany.  I honestly don't know how I missed this - it must have been decision fatigue - but I realized at some point when trying to draw up the 64 truth values for Mux4way that since it only comes out 1 or 0, I could just express the 1 values as ganged-up And functions, then disjoin them together into a giant Or function!  Now I am slightly embarrassed over yesterday's fiddle-fartin'; but that's what I get for doing my homework in public.  More importantly, I learned a valuable lesson, and I'm proud for having solved the problem in a more elegant fashion anyway, so it's all good.  Behold:  Mux2.0!

Meaner.  Leaner.  Also greener!

And here's the new and improved NAnd-Only HDL:

IN a, b, sel;

OUT out;

PARTS:

Nand (a=sel, b=sel, out=NotS);

Nand (a=a, b=NotS, out=r1);

Nand (a=sel, b=b, out=r2);

Nand (a=r1, b=r2, out=out);

Wham!  Bam!  Flim and flam!  That's over 75% fewer lines of functional code, for those of you playing along at home.  My inner quality consultant is serenely satisfied.  OK, moving on!

DMux, the demultiplexor which takes a single input and uses a switch between two outputs, gave me a little bit of trouble.  But that was only because I was thinking I still had one output, when actually I've got two output pins coming out of my own little black box space.  That realization cleared it up right quick!  The diagram seems almost absurdly simple in hindsight - even the NAnd-Only diagram!

Gallons easier once you paradigm shift out of truth-functional

propositions per se and just start black-boxing everything.

I'm not even going to bother with the code, here.  If you've been following, it's simple enough to work it out for yourself, and I'm starting to feel pangs of "give a man a fish" guilt about doing this all in public.  At this point, though, I think the only "damage" I've done is to help along somebody just getting started, like I am.  That said, my code works beautifully!  (Also, I found via typo that this HDL is case sensitive - good to know!)

Next up, Not16:  the first 16-bit gate.  This is the reason I wanted to try out a proof-of-concept at home before actually diagramming and coding Mux4way16 and the rest.  Turns out, I can't just put in the variable "i" for inputs 0-15, I have to code them line-by-line.  Or I could type it once in Word, and use Replace!  Not a big deal for Not16, but definitely going to appreciate it for Mux8way16!  I have never been so grateful for Ctrl+H in my life (true story!).  I can imagine a program that takes code with [i] as a variable, expands it n times, and replaces [i] in each iteration of the code with [n-1] (because you start with zero, duh)... but this would save me a fairly minor amount of time (even though it feels like a lot of tedium), and anyway if I knew how to do that, I wouldn't be doing this in the first place.  Heh.  Whatever, Ctrl+V x 16 and highlighting a few lines then pressing Ctrl+H, Tab, n-1, Alt-A, N, Esc over and over isn't exactly hard.  So that's And16, Or16, and Mux16 out of the way.

Or8way throws a bit of a curve, since it's not mapping multiple inputs to multiple outputs like the last three chips.  Instead, we're taking in eight inputs to the same giant Or function which maps to a single output.  What we're coding here is not to do one thing with many inputs and outputs, but rather to check for any of eight things (rather than Or's mere two).  Here I think it pays to point out that how we code this may have an appreciable effect on performance:  I could code 4+2+1 (or 8-1, ganging them serially rather than pairing them) Or gates, making the machine instantiate the Or chip (and its 3 component NAnd gates) seven times "inside" this chip; or I could directly code all 7*3 NAnd gates and have it be its own thing rather than making the machine look elsewhere first.  While the difference between configurations is infinitesimal for just this one Or8 gate, it adds up cumulatively in the processor load when turn on the "computer" and run the "chips."  Not of particular importance to the lesson at hand, but of tangential relevance and so I thought I'd point it out.

Also, I found out by experience that pins cannot be named beginning with numbers - who knew?  I named the outputs from some of my NAnd gates as "out=xvy" for clarity (where x and y were integer values corresponding to input pins), rather than the relatively nondescript r1/r2, etc.  I kept getting the error, "A pin name is expected," and jiggered around with it for over half an hour, giving myself a headache in the process.  I have a feeling I should be expecting a lot of these in the weeks and months to come...

Taking stock:  I seriously refined my multiplexor, which is a big deal to me, and wrote up the first six of my final ten gates.  Good progress for one day, I think; and my brain is feeling full now, to boot!  I also watched a great introductory video over at the Khan Academy, during which an idea for a text adventure began crystallizing. I'm not sure quite how to do the "window" stuff yet, but I've got a good handle on how to declare values like player health, experience, and level, and how to nest conditional dependencies inside them to link derived stats to their primaries (now I just need, oh, the rest of a game to house them!).  I've also got some good ideas for a weekend mini-project to overhaul the site with a custom image header and a few layout features, so there's quite a bit going on under the hood today, as well.  Plus Zach gave me another tip for making forward progress on Fetris, so I'll be looking into that right now.  Y'all have a great one!

Final Thought:  I just realized while proofreading that the program I pined after above - the one that would do my homework for me - would actually be pretty easy to code using the principles taught in Python by that video at the Khan Academy.  The only real "invention" would be to code the recursive function that iterates the steps n times.  Great, now I'm going to be thinking about that all night.  Anyway, I'm not writing the code here, since that would be providing a tool that actually does actual homework in an actual class, but the principle will be super-useful when generating content procedurally in future games.