The Lone Developer

A great Wiki article aimed at the single, one-person game developer-- tips, hints, and suggestions: Lone Developer

Return

I began work once again on the game yesterday. At first I resisted deeply considering what I was doing but I continued on and, after a time, I found that I was making a good deal of progress. I primarily worked on button controls and some logic concerning the computer-player's A.I. I came to a point where I decided to save and exit the compiler, stopping at a reasonable point. I felt it would be better to rest on that night's laurels than press on, become tired (it was late), and end up with a coded train-wreck that I would have to untangle today.

This afternoon I need to look at and fix some of the variables that are throwing obvious errors (returning zero as a value) I believe I may be done with the principle build by the end of the weekend and can then schedule final testing.

Rest_Read_Rest_ [code?]

I have taken a short break from work; I have been resting and reading: Plato\ Socrates, OOP, OpenGL, Basic4GL, The Bible (Psalms). Yes, resting in the form of naps-- I never take naps. For the last few months between work and personal projects I have been keeping odd and almost bizarre hours, or should I say (?) no particular hours. Hmm, my body noticed and for the last almost 2-weeks has been inducing day-naps and end-nights where I am asleep before Midnight. Odd, but I believe it is necessary for health and there is no stopping the body when it needs to reset itself properly.

I plan to finish off the "Sith Realms 21" game this week for the most part minus final testing (unit testing and benchmark testing last week brought me to a nice point allowing me to take this break). I am hoping tomorrow brings the urge and resolution for completion of this project. Hoping.

The Glory of a Proper Algo

I cannot claim to directly know of the absolute algorithm intimately, but I do know it exists. After much work and struggle in programming as of late, I reach what I think to be the peak of a mathematical discovery, learning how it works from within, and how the results spill forth upon me as simply perfect-- then I fall down the slopes into the valley only to be forced to view the peaks once again wondering aloud if I shall ever reach the top.

It requires a forward push. It requires a faith in numbers, a spirit that reminds one of the truths when an algo produces negative results :"It is not I, fool-- my form is gracious. It is you who does not understand the depths of my language nor how to speak of my ways." So true.

But, I try to push forward, day after day, and I see the sun skirt the glacial faces as the winds break free upon the Northern realms above. I must prepare better for my ascent.

The Importance of Unit Testing

The importance of unit testing during a program dev is beginning to ring true! Not that I really ever doubted it, I just never truly considered it. I have always "unit tested" (as we all do while producing code-- compiling, editing source, etc) but I have never until last night made it a priority. I'll admit, it is probably too late to officially begin this method for "Sith Realms 21" as this particular program is almost complete, but this very foray into proper unit testing, that is, writing actual logic tests and documenting their results helped me to solve (it seems at this point at least) some serious logic errors that prevented the clearing of an important milestone towards completion. I have adopted this technique and plan to use it from this point forward.

Testing: by Evelyn Mitchell

The 17th century German philosopher and poet Novalis said, "Most marriages are divorces." Had he been a software developer, he might have said, "Most programming is maintenance." Still, with careful testing from the outset, the maintenance of existing programs can be made much easier, but only if the effort of writing and running tests is justified.

Unit testing is the process of testing code as you write it. You can also use unit testing during regression testing, in which you determine if a program is working the way it did before you modified it. Unit testing is also known as "white box" or "glass box testing," as opposed to "black box testing."

Black box testing is, roughly speaking, testing done by someone who does not have access to the program's code. In black box testing the program is viewed (you might have guessed) as a black box that takes inputs and produces outputs, but doesn't reveal its internal structure. By contrast, unit testing exercises your full knowledge of the code by testing the interfaces to other code components and to user space, as well as the implementation.

Unit testing fully tests every interesting function a program performs. You can test for unusual data, or for combinations of values that should always or must never occur. You can even use it for coverage testing, to make sure that you've exercised every path through a program.

You can write the unit tests once you understand what you want a module to do, even before you've actually written the module. Kent Beck (author of Test Infected: Programmers Love Writing Tests -- see Resources) recommends writing the tests before you write the code because they can help to clarify your understanding of what the module is supposed to do independent of how it will do it, thereby separating design testing from implementation testing. If you can't write a test for a module before you write the module, that may suggest that you do not understand the design, or that the design has an error. If you can catch a design error at this stage, you've just saved yourself some coding time.

A unit testing framework, such as PythonUnit, makes it easy to test your code after every change, no matter how trivial. I work with multiple windows open -- one for the code I'm editing, one for the testing -- and I pop back and forth as I make changes.

This makes finding errors simpler because you know that the change you just made caused your test to fail. Frequent testing can eliminate those multi-hour debugging sessions where your code gets filled with print statements while you try to find that good line gone bad.

Writing all those test cases may seem like a lot of work, but I find it to be a very effective way of learning how a new piece of code functions (or doesn't function the way I thought it did). The time I spend writing tests is time I would have spent guessing about how something works, to no good end.

The simple fact is that the earlier you find a bug and fix it, the cheaper the fix is.

Twisted Variables and Flying Roaches: The Mighty Dogfight

The program I am currently working on, "Sith Realms 21", is nearing completion; at this point I am doing a lot of testing, not the proper testing one reserves for a release but a real-time testing (unit testing) that is forced. "Forced" in this case is not a burden but is not welcomed with heart-warming grace, either. I, the ever-impatient programmer\artist wants it done, complete-- a folder in my virtual portfolio to show a potential, future employee. I must always remind myself of the real purpose of this work: through mistakes and errors you will learn (hopefully), and through having to fix a misconceived design you may be developing a vaccine against future, disastrous designs. Just try to learn calmly as you stare at the compiler, and do not give up the fight of error eradication.

It is not unlike a WWI dogfight sometimes: You know that the enemy stalks the horizon. You hear the hum of his engines and the whirl of propellers. Your instinct tells you that if you come in contact with your opponent it will be a nasty fight, but you fly on. You now see their canvas wings as you draw closer-- they are not quite the enemy you feared. But, they let loose with a barrage of lead volleys that almost gaze your leather helmet and punches holes in your planes skin. You tilt and roll racing towards the Earth not in pursuit of a fiery death but only as a defensive move to regain your arial footing and produce a new, aggressive stance. Your co-pilot screams for you to blaze a trail to the heart of your enemy even if it means both your deaths. Victory is possibly only a moment away. Your tear loose with an attack of machine gun fire that strikes the enemy pilot in his hands and his head. That plane now falls free and bleeding smoke, a torn kite now fuming with sure defeat; the dead, enemy craft thrashes the ground not unlike a shattered spear and explodes in a glorious gulp. Your co-pilot yells "Aces High!" and you prepare to return to base. You have just won this round and you can rest perhaps for a moment. Your team will seek and search to recover the destroyed enemy plane to study the wreckage for secrets and technological advancement-- all you do is fall into your bunk and retire with victory for a few hours in dreams of blasts and breath-stealing bail-outs. You will awake in a sweat for another take.

Such is the days of a programmer at times. Although I am making use of lofty, dated imagery and metaphor to describe my struggles with code at times, it is how I feel it at the moment and I pray for victory and yearn to return to base, perhaps to gun another day for all the twisted variables, redundant code bunkers, and the notorious bugs who fly in bomber-formation in search of birthing a firsescape in our eyes. Aces High!

More On the Star Wars Card Game...

I worked for hours tonight searching for bizarre bug anomalies-- zero appearing as a mathematical result over and over-- this made no sense and I had never before seen this in this program; I took notes on paper of the outcomes and their possible area(s) of origin. I looked for patterns (this is important) and deduced a target to shoot for. I knew it was buried somewhere least suspected as is often the case. After listening to Iron Maiden for hours and immersing my head in code I found the suspect area and it did not turn out to be what I first thought, a mathematical error. It was multiple typos involving lists elements replicated throughout the code due to unfinished, non-updated cut-and-paste. I clone a block to save time and end up spending five hours fixing it. I should have known. Now I do.

Promo: Complete

The Team KAIZEN promo is complete. It came out quite lovely, really. I am not completely satisfied with it as is the case with any of my work-- I know it can always be better.

There were some issues with PyInstaller-- I will have to look into and investigate this further in the future before I need to make another Python executable.

The promo is ready to ship and I will send it to my boss within the week.