Two New Projects

June 3rd, 2010

I’ve been busy of late, working on a number of things. First, I have my work and family that take up most of my time. Next, I’m in graduate school. Finally, I have a house with a yard that desperately needs care, which results in too many mandatory projects.

But, in the evening, when the kids are in bed, the homework is done (or being procrastinated), and the sun is setting, I have a couple hours to do – whatever. Okay, there’s dishes, cleaning and other stuff indoors, but that usually doesn’t happen while the kids sleep since they’re pretty light sleepers at indeterminate points in their cycle.

So with those couple of hours per day, I have two projects I’m working on. Neither one is really new, but I’m taking a fresh start on both of them.

The first project is a novel I’m calling “Bloodseal” for now. It’s about a high school kid named Braeden, who discovers he’s the living vessel for an old and powerful demon. He then must decide whom he can trust, pick sides in a war, and find the secret to controlling his newfound power before he loses himself to the demon.

The second project is for all those times when I sit down at the computer to write, but for one reason or another just can’t do it. It is a software development project. The software I hope to create is writing software. There are so many features I see writing software out there having, and many of them are good features, but what I haven’t seen (at least not inexpensively or without other complications), is a specific list of features I’ll be putting in my software. I’ll be writing it in Java, so hopefully I can find many plugins to do the hard work.

Some things I’d like this software to do:

  • Run on Windows, Linux, or Mac (I use Linux primarily at home)
  • Basic text editing and formatting (like Wordpad)
  • Tree oriented document structure
  • Full screen editing (bye bye distractions)
  • Skin-able backgrounds to get you in the mood to write (ie. not the same blue and gray windows you look at while doing technical work)
  • Version control (this includes tagging versions of documents as part of drafts)
  • Form inputs: ability to define forms, ability to easily use them to manage story data
  • Hot web interfaces to dictionaries, thesauruses, encyclopedias, search engines, etc.
  • Storyboard/Timelines
  • Other features as time and energy permit

So, that’s what I’m up to. I’ll likely be posting more about these projects in the future.

Comments Off

Game Developers long suffered the stigma of the lone, smelly, poorly groomed and overweight, pizza eating bachelor that spends countless late night hours in his (yes, his, not his/her) basement cranking out the next big thing in games. While this stigma may have been well earned in the 1980’s and even a little in the 1990’s, the industry has since pulled away from that stigma.

Still, game developers, like most software engineers, tend to be male, most are required to work many hours under tight schedules with little if any additional compensation. As a result, many tend then to have little or no family life (though that is far from “all” of them). Some who don’t sacrifice personal or family lives for whatever project they’re on at the time find themselves first in line for layoffs when the inevitable budget crunch comes around.

But game developers have something that many software engineers lack – passion. It is their passion that calls them into game development and it is their passion that sees them through the hard times and long work hours. But most of all, their passion helps them learn much more about software engineering for a single project than many software engineers learn in a career.

Why? Because games are among the hardest software problems in existence. They must make use of the latest hardware for graphics, sound, user input, squeeze every drop of performance out of memory, CPU, file system, network, and other resources. They deal with concurrency, complex algorithms, artificial intelligence, and security. They are often distributed, run intricate simulations, and predict user actions and involve dozens of developers working cooperatively.

But on top of being extremely hard to create (relative to many types of software), games are fun, exciting, and sometimes even educational. Think of the last game you played. Do you remember how fun it was to play? Now imagine creating that game. I find my enjoyment of writing a game is at least ten fold greater than my enjoyment of playing one.

That is why I would recommend to everyone out there who is attempting to teach or learn computer science, software engineering or and form of computer programming: create games. Students will learn more, they’ll enjoy it more, and they’ll be more driven to keep learning if they are making games. The best part is games can be simple – or complex. Basic games can involve only a little knowledge, take less than a day to write and be tons of fun both to write and to play. The more complex games will obviously take more time to create but will also teach the student more software principles. The learning here won’t just be an act of regurgitation as so many homeworks and exams are, they’re true learning experiences.

So, go play a game and appreciate the hard work of those that made it. Software people, go write a game. You’ll learn more than you think, even if you’ve been in the industry your whole career.

Comments Off

I regularly find myself facing peers (ever since my college days) who are decidedly misguided if not moronic about the practical application of object oriented programming. For those of you lay folks out there who don’t know what that means, it basically means: programming, where you model objects. Instead of data and functionality being separate in the code, you can simplify many things by putting it together. It sounds simple on the surface (trust me it is simple), but some people get it so terribly wrong it makes me sad.

The premise, while an easy one for me, seems to elude many. You see, there are several implications and powerful tools this coupling of data can give us programmer types. For one, it allows us to hide the actual data and algorithms we’re using so we can change things in one piece of code without hurting other parts of the software. That alone is HUGE. We can also reuse capabilities of existing objects (we’ll call the “classes” from here on) by something known as inheritance. Inheritance is a mechanism through which a class can get the capabilities and data of another class completely for free! Then it can specialize something in order to do a specific job better. There are lots of reasons for wanting to do this.

Let’s look at the example that makes me sad. It makes me sad because it comes sooooo close to describing how to use inheritance and why you’d want it, but instead of driving the point home, it kind of drives it to the neighbors house, where they have loud parties and sleep till noon

The example is of cars, or automobiles. We’ll often start with “suppose we have a class called ‘Automobile’ that describes all the generic capabilities of an automobile.” With me so far? “Then suppose we want to describe a “Car” as inheriting from “Automobile” all those attributes plus the idea that it’s small, has four wheels and ” So far, so good. “Then we want a class for ‘Truck’…” Here’s where I start twitching. If you follow this example to the logical fruit, you basically end up having a class for every type of thing out there.

So, what’s wrong with that? Well, for one thing code tends to be easy for students to develop so they’ll take this line of thought off the bridge past the signs that say “warning” without realizing they’re doing it wrong. They don’t realize that once that code is deployed you can’t so easily go in and change it. Instead, for this car example, we should pretty much just parameterize the class “Automobile” and leave it there without any inheritance at all. That way, when Ford invents a new model of car, we don’t have to redeploy our software. If instead of “Automobile” we had “Vehicle” we could do something else. For example, we could have a class “Boat” which would describe any kind of sea faring vehicle in terms of sea faring things, “Car” that did the same for land bound vehicles, “Plane” for air born ones and so on. It’s still not a clean cut example however since we may have vehicles that are capable of land and water use or water and air, or all three. See? Examples are not so easy.

This is where the student of Object Oriented Programming needs to make that intuitive leap from swallowing and regurgitating facts and ideas, to actually understanding the intent behind them. The intent of these examples isn’t to show you where to use inheritance, it’s how. And unless you can learn the how, you’ll never understand the where. Unfortunately, so many I have come in contact with are stuck in regurgitate mode and have yet to make that leap.

Comments Off