Thursday, July 31, 2008

Ur Doin It Wrng

I'll be forthright: I only skimmed a bit of The 'Anti-Java' Professor and the Jobless Programmers the first time. After going back and giving it the attention it deserves, I agree with the message it's trying to send, though I must admit it's really an echo of similar arguments I see in other respected programming blogs (see: Joel on Software's The Perils of JavaSchools).

So, really, I'm not trying to say or point out anything particularly new. No, the parts of The 'Anti-Java' Professor I wanted to point out were the following quotes:

Dewar stresses that he’s not against Java itself. But the fact that Java is taught as the core language in so many colleges is resulting in a weak field of computer science grads, he says.

The reason: students’ reliance on Java’s libraries of pre-written code means they aren’t developing the deep programming skills necessary to make them invaluable. Colleges, alarmed by falling CS enrollment, have dumbed down the course requirements. Consequently, CS majors sail through a curriculum of Math Lite, earning a smiley-face on their papers for “developing” projects using pre-built libraries.

Followed by:

But wait a second, Professor Dewar...I wanted to ask him, since this list of popular programming languges puts Java at No. 1 – ahead of biggies like C, C++ and Visual Basic – doesn’t that negate his theory?

I mean, if Java is this popular, maybe universities should teach it first. It called “being in touch with the real world,” isn’t it?

Before continuing any further I'd like to point out I don't specifically have anything against Java. I feel like it is a perfectly adequate language that the right people can do great things with, like all languages. This is not about Java (it could just as easily have been about Python, and so many other languages). It's about the ATTITUDE that is being flaunted; Java just happens to draw this kind of attitude. Take or leave that as you wish.

When I first read this, taking it seriously, it infuriated me, mostly because this is the attitude I see at my own school. So many times I have see my fellow students (in my eyes) just give up because a language "is so much easier" than C, C++, Lisp...whatever. When I mention that I am leaning towards doing a video game project in Lisp for my masters work I always get the exact same question: "Why are you using Lisp?", usually followed by, "Why not just use Java?"

It boggles my mind. It's like asking me "Why are you doing computer science?". I'm doing it because I love computer science and want to learn as much as possible, not just sit around and churn out easy code. If I wanted to do THAT I would just do HTML all day and try to convince people I was a programmer. I mean, it's easy, right? Why spend time learning something more complex like Java?

Why is it so weird when you're devoting at least four solid years and thousands of dollars to something that you would want to learn as much as humanly possible? Is this not the point of college? While I do agree there is a place and time for very good tools (such as the ones Java provides), there is also a place and time to learn how exactly these tools work by building them yourself.

Just as a random anecdote, a friend of mine decided to rewrite a built-in Java search and came up with his own search (in Java as well) that was magnitudes faster. He learned something important from that experience, as we all should.

Wednesday, July 9, 2008

Linux Wants to be Your Friend (Part II)

Wow. Linux Mint...I was really, really impressed. Of all the "user-friendly" Linux systems I've messed with, this one is hands down one of the most solid and truly user-friendly.

Installation was, as expected, a breeze. It took maybe 10 minutes total, and like most modern, desktop-based Linux distros allowed you to explore the LiveCD at your leisure while the partitioning and file-copying and whatnot was being done.

The full installation naturally has the essentials: the excellent Synaptic package management system, Firefox, Pidgin, and a nifty little update program that allows you to update the entire system with a few mouse clicks. The aspect I enjoy most about the update program is it resides in the toolbar along the bottom, very unobtrusively indicating, with nothing more than a slight change in the button, that there are new updates available.

The best part: all internet plug-ins are installed right away, as promised. I was still having issues with applets (they weren't aknowledging keyboard input, very odd...), but there was no need for me to do any manual installs of...well...anything. Probably the easiest Linux install I've ever had to be quite honest.

The only minor issue I had with this distro is it doesn't do root like I normally expect it to do root. You have the *option* of setting a root password, although it's recommended you don't. The first time I did set the root password, just out of habit, and after multiple failed attempts to start up a device manager, I realized that the desktop was, like Mac OS X, asking only for the user's password. sudo asks for the user's password, and, to my horror, the user can even modify important root-level files (for example, the grub boot menu file) just by sudo-ing. Depending on the environment in which this distro is installed, this could be unforgiveable or just cringe-worth.

Outside of this I would highly recommend this system to any Linux n00b who just wants a working system set up quickly and painlessly. This distro will be remaining on this desktop until the techs find out and become engraged at the lack of Vista.

Tuesday, July 8, 2008

Linux Wants to be Your Friend (Part I)

What do you do when the Vista computer at work, which already runs painfully slow due to the underpowered computer it was forced on, becomes so choked with viruses it is virtually unusable? Well, you install Linux on it, of course. The problem? You (in this case me, but meh, pronouns...) are pretty good with Linux, and the people sharing this computer haven't even heard of Linux. What distro do you use?

The fun thing about this is it gives me a chance to field test a few Linux distros for usability, and see how each one stacks up again the other. My first choice was <a href="">Debian</a>, which, in hindsight, was an awful idea.

Pros of Debian as a "common user" system:

1) It is incredibly easy to set up. The net install takes maybe a half hour, just due to all the file downloads. If you have a fast connection it takes even less time.

2) Just installing the "core" components gives you a fantastic Gnome desktop right away (this may seem like an obvious point, but I've installed more than one distro that requires you to install xorg on your own, or do xorg configuration, and so on).

3) It has a shnazzy update system, as well as the always-excellent package management system.


1) Debian's staunch adherence to F/OSS, while admirable, is the main source of many headaches. Flash was easy enough to get working, but I never got the JRE to work right (many applets just displayed a frustratingly cryptic "Error Loading" message), and I don't think there's any chance I'll ever get Firefox 3 installed on there. Yes, Iceweasel is technically Firefox, but it is still the old version and this is still unendingly frustrating.

2) Their dedication to having a solid platform is fantastic for servers, but especially when it comes to web browsers, being even a few months behind is too much. New Flash plugins are released all the time, and sometimes software, such as Firefox 3 as I mentioned above, is important enough that I want it installed and running right away. However, an outdated system makes everything that much harder to get running (GTK libraries aren't up to date, and didn't want to get up to date, so I was left Firefox-less), and leads to a lot of extra work I don't feel like I should have to do, especially when it's a computer I hardly use more than a few hours out of an entire month.

The next distro on my list to try will be <a href="">Linux Mint</a>. I'm burning the boot disk tonight; the excitement is palpable. Linux Mint is based on Ubuntu, but it's supposed to have all media plugins installed already...I'm anxious to give it a try and see how easily it is to install and use. Stay tuned for Part II tomorrow!

Monday, July 7, 2008

Problem in Interpretation

Just as a programming exercise, I've been trying to write an interpreter for the esoteric Brainfuck language in C++, and it is hands down my most unsuccessful and frustrating project ever. Taking my first far less competent attempt into consideration, I've probably been working on this for a half a year (though I should mention that the "work" was extremely sparse at best).

My first attempt, before I understood the goodness that is the STL string class, was to utilize arrays. To be fair this was (pre-Theory of Computation) how my mind felt the interpreter was MEANT to be implemented. I mean, it uses > and < to increment and decrement the pointer. And really, stripping it down to its core, all the language does is move a pointer up and down an "array" and increments and decrements the contents until it gets a command to "print". At that point it is assumed you're outputting an ASCII character; all that work just to create a string of ASCII characters from their number codes.

My next crack at it (meaning my current attempt) is involving an array, but only an int array in the main increment and decrement function. The actual input, as well as the final output, are both strings (so, if you want to get really technical, they're char arrays, but we're not going to worry about that because you don't have to treat them as such when you're actually using the string class. Because the string class is so wonderful).

The issue I'm running into again is the same issue I ran into with my last attempt: the while loop encased within the "[" and "]". The problem here is twofold: 1) figuring out how to recursively call the increment/decrement function so that I won't be re-writing the main chunk of code in my program and 2) dealing with the situation where the current index (ie the index the pointer is on at the point of the "[") will either be the number to be incremented/decremented, or the counter.

So during the while loop there are four essential pieces of information: the index to be incremented/decremented, the counter index, and the actual value at both these indexes. I have to keep track of this, while being able to throw everything back to the "main" program in which everything is just a straight line of incrementing/decrementing.

My friend suggested using a stack at this point, and my initial sketches involved pushing and popping the "+" with each run of the loop; after considering, I don't think this is at all effective. The first move will be to push each + found in the first run through (for the sake of simplicity I'm assuming the modified index will only be incremented); after the first run it will be obvious what the counter is and what the index being modified is. Keep pushing + until the counter runs down, then pop each + until there aren't anymore. Voila!

Hopefully I'll have a working interpreter by the end of the week; I'll post code once it's completed.

Thursday, June 26, 2008

Back to Arch, and Lisp

The past couple of days I've been slowly migrating back to my Arch Linux box, especially after I realized most of my lack-of-hdd-space problems were stemming from the fact that I hadn't emptied my trash in a while. Nice one. Anyway, I'm moving back to that box as my primary dev environment just due to the fact I love more hands-on Linux distros like that, and feel like they're much easier to code on because it's expected you know your system inside and out...that leaves no place for libraries to hide, and removes the voodoo that seems to normally go along with prepping a dev environment from within a more hands-off system (I'm looking at you OS X).

I still haven't decided whether or not I'm going to nuke my OpenSolaris partition; I really enjoy having a full Linux distro running within my Mac, especially when I need to go home and there's no way in hell I'm lugging back two desktop computers. This just will not happen. I'm certainly leaning towards keeping it after being reminded how easy the install and initial set-up was. No fuss, no muss.

I'm finally starting to get back into Lisp as well. Recently I've come down with "do the same thing every day" syndrome, or in a rut as it were. So to rectify this I'm taking a break officially from TF2 (shock!) in order to start working on some projects, including a Lisp syntax checker and the multiple games that have been piling up. (Maybe I'll make some time for musical endevours as well? My saxophone is so painfully neglected...) So much for getting lots of work done over the summer.

So I currently have two primary goals: learn Lisp and complete at least one simple video game project. Hopefully the next time I post I'll have some progress to report!

Sunday, June 22, 2008

Java Just Is Not My Bag...

I've been slowly trying to work out a Java game based on this design since the end of last semester, and progress has been slow to nil. Java is not my main language, and despite the fact I learned quite a bit in my GUI class (where Java was a requirement), I'm still struggling with the very basics. Whereas C++ just *feels* right, when I'm attempting to do any programming in Java I feel like a awkward teenager trying to unsuccessfully grope a transvestite hooker, desperately hoping something good will come out of it if I just keep feeling around long enough and ignore that everything seems wrong about it...

There's not a particular reason for me to feel this way, I've just never been convinced that Java is near as elegant or worthwhile as C++. And I just never really got the hang of it. The main issue is the enormous API; everything in Java is about memorizing syntax. Yes, there is a lot of this in C++ (there's more to the string class than I want to imagine), but somehow it's just not the same. I'm sure this is due to my lack of knowledge, but I don't feel as if I have any control over the built-in functions and objects. As I described to a fellow programmer friend, it feels like trying to use Legos to build an engine.

Anyway, back to my game...I got a fairly good start, with graphics and all that, though I got "stuck" (read: stopped working) when I realized I would have to think about how to deal with the click-place mechanic with the blocks. Yes, this isn't hard, but my mind was whining loudly, "Whyyyyyyyyyyyy do I have to help you figure out how to keep track of all those x and y positions? Can't we just start playing [TF2/ Resident Evil/Metal Gear Solid/Final Fantasy] again??", and I would always give in. Finally, I came back to it after months, and in between that time had started up my zombie RTS project (in C++), and I realized I had no clue what my code was doing, so I overracted and deleted all versions I had made up to that time and fired up Netbeans with a fresh new blank project. And realized it had been so long since I had programmed in Java that I couldn't even remember where to start...

Ironically the main reason I chose this language in the first place is its expansive built-in support for basic graphics stuff. I COULD use a Java game library (like lwjgl) but that would mean reams and reams more of API to trudge through. So once again, I have restarted the same game project, and am faced with my failing as a Java programmer. I have tentatively started the classes, named a few variables, outlined what is inhereted from what, all while struggling to remember exactly how all this works. Someday I will beat this language. Someday.

Saturday, June 14, 2008

Terrible Game Analysis

I fired up Resident Evil: Code Veronica X again for the first time in a while in the hopes I would be able to make some progress and got so lost and frustrated I ended up starting the game over again and pulling up a full walkthrough. Honestly, I don't think I got very far overall, and during my second play through attempt once again shut down the game in total frustration.

This game is largely toted as the worst in the popular game franchise, and was the last of the "classic survival horror" style entries (which RE defined) before Capcom went for a more modern, action style with Resident Evil 4. It is not at all unlikely that the complete revamp was due to the failure of this game. I completely forgot about Resident Evil 0, THIS was a terrible game that marked the end of the traditional survival horror gameplay for the series.Without falling into the pit of ranting too much, I wanted to pinpoint what exactly it was about this game that made it so unbearably frustrating.

This really isn't obvious at first glance; CV sticks very closely to the traditional gameplay style pioneered by the older entries, including the tank controls, fetch quests, and file reading. The level design is dominated by large mansions, labs, and a few outdoor areas, once again in keeping with earlier titles, though it was far more expansive than the previous three. Here's an initial issue: the level design is almost too expansive for it's own good. Like the original RE, you get an overhead floor plan of the areas you're in, but unlike the original RE, you're not limited to an extremely compact area, and quite frankly, none of the rooms are shaped oddly enough to provide landmarks of sorts. Every room is a different sized square. This does not translate into a useful map.

Along these same lines, each one of the rooms was just non-descript enough that I could never seem to remember what was in each one or where it led. To make matters worse, the sheer amount of them made them just blend together; there was never a point where I felt like I had a real idea of where I was going. The original RE technically "looked" all the same, but once again the fact that the area was so severely limited allowed the player to absorb where all the doors led. RE4 deals with its impressively expansive areas by making each one look different and providing an extremely helpful map (besides being exceedingly linear).

Naturally fetch quests were a cornerstone of the series, but CV took this to such a ridiculous extreme that the entire game felt like nothing but one gigantic fetch quest party with a few zombies tossed in to provide some kind of challenge (as if the level design didn't make it hard enough). The fetch quests and puzzles in the original RE were silly, yes, but they at the very least made a small amount of sense within the context; you had to find a book to place with other books to open stairs up, or use the clues on the wall to mix the exact right chemicals to kill the evil plant zombie. You were never at any point needlessly loaded down with too many fetch quests at once either. Code Veronica has you picking up emblems, plates, useless guns, insects made out of jewels, and various other pieces of junk at every turn. At the point I quit the game the first time I had a painting, two "proofs", a plate, and various other pieces of ridiculous brika-brack in my magic chest. To be honest, this was, in fact, the main reason I quit; I was faced with a pile of various junk that needed to be placed in their various respective holes in the game, and the thought of not only having to retraverse the areas to get it all there, make return trips because my carrying capacity was so low, all while painfully low on health with very little ammo to keep zombies at bay and no hope of finding any more health items...this was too much for me.

Just to be fair there are a few good elements; the main character is actually pretty cool (I don't care what anyone else says I like Claire), the combat knife is the most useful anyone ever gets in the entire franchise, and that chick can take an ungodly amount of damage. I mean, she's a fucking TANK. The plot, although it was pretty weak even for a Resident Evil game, still provided some extremely amusing elements (cross-dressing insane main villain) and some important plot points for later games (Wesker being all un-dead and self-elected main villain for the series from this point on). So I suppose in some ways it's not a total loss. It's just unfortunate that, if the level design and fetch quests had been more fine-tuned, the game really wouldn't be half bad.

To sum up, the terrible plot elements, characters, and voice-acting can all easily be forgiven if only the game itself is FUN. Code Veronica manages to make you feel like you're working, not playing an enjoyable video game. And this is its ultimate downfall. When your players quit the game in frustration then you've failed them in a huge way. Fortunately, after RE0 ended up being even worse than CV, Capcom got the message and now RE is (argueably) getting better with each new installment.

The Return of Wheel Bird and Dog (?)

Even though I know it's a HORRIBLE idea to start thinking about new game concepts while working on another game (only because I have the worst track record of finishing projects and I really want to finish BioWar), I realized as I was trying to figure out the assets problem that I had a large library of potential assets for another game...The Official Wheel Bird and Dog game.

People who were not friends with me my first years of college will not be aware of this odd artistic expression that was a fairly substantial part of my life for a few years. It consisted of a crudely drawn dog and purple ibis bird (who did, indeed, ride a wheel contraption around) who were always on the hunt for barley to make mead (despite the fact I discovered later that mead was not made out of barley). Other reoccurring characters included The Mighty Ferret of Girth (an ultra-sized ferret that only made "dook dook" noises), and various other random creatures that did various other things (other favorites of mine were Crack Horse and Bong Monkey, a large tegu whose name I can't remember, and an anoexic cat).

The "comic" ran long enough that I (reportedly) released two trade paperbacks including 10 (or 20?) comics apiece. I wish I could be more accurate with all this but I'm far too lazy to dig it all up. All the comics were scanned onto my computer and posted to a hand-coded website on my Ball State webserver for all my friends viewing pleasure when I was just starting to really get into the internets.

Anyway, enough remenicing. Summery of this story is I still have all this on that server, and I could very easily cut out the characters and produce .pngs and what have you for the sprites. I'd need to think of an original concept for the game, since I wouldn't want it to just be a cookie-cutter platformer, but I'm thinking this would be an excellent basis for a casual game like I was talking about in my earlier post (Ruminations on Casual Games). This is going into the idea bin, there could be more later.

**EDIT: I just remembered the tegu's name was Pom-Pom. He was Dog's pet and liked to eat dirty goth kids at Nine Inch Nails concerts.

Thursday, June 12, 2008

Here's a crazy change of pace....

The first (and only) project for my CS 570 class (Theory of Computation) was to write a parser for a context-free LL(1) language made up by our instructor. I won't get into the specifics, but this was the basic structure of my entry: use a function for each non-terminal, and only check for the first of the "right hand side" of each grammar rule. I made the very easy and glaringly bad decision to declare a global token variable, which was modified directly by every function. So, essentially, there was just the one variable and each function got to check it out when it was its turn. This was especially cringe-worthy in the do-while loops; if the token was equal to a specific character at a specific point in time, it would jump into the "do" part. The functions in the "do" would modify the token, and then it would be checked at the end in the "while" section. Then it would act accordingly. This makes me cringe...

Because I'm a ridiculous nerd, I rewrote the program to utilize local char variables passed between the functions (easy as cake). This was certainly something I should have done in the first place, but I'm not too overly concerned about it, since I still managed to get an A on the project.

Here are the original project and the updated version.

I started working on a third version that optionally takes a file name as an argument when you invoke the program, reads the file, and then parses the sentences accordingly, but this modification will require more insight.

What's the moral of the story? The first project took me about 2 hours to do, I half assed it, and even though it worked, I still feel like I could have done better if I had taken the time to work on it a little longer and put a little more work into it. I also like consistently trying to improve on my older work even when the projects are, at best, trivial (or, in this came, seemingly trivial with applications to far less trivial projects, ie compilers). Practicing the basics never ever hurts, as long as you are able to move on and work on something more substantial and don't spin your wheels over return types, etc.

Lengthy To-Do List

Due to my horrible work schedule and the general feeling of exhaustion resulting from it, I haven't had the time or even really the desire to work on BioWar lately (that's the really lame working title) so in an attempt to motivate myself, here is a list of basic gameplay elements I need to implement:

1) Resources: I currently have get and set functions for this, but I need to design the system in which these are obtained.

2) Unit stats: I haven't yet set some basic specs for the units; after doing that I'll need to do some basic play-testing to ensure there will be some sort of balance. The main reason I haven't even started doing this yet is I still have to define what certain stats mean, ie what exactly does speed mean in terms of game-play?

3) GUI: I still haven't decided how the game will even look (which can most certainly come later). I don't currently have any assets I could use to create a GUI, so I may have to rope in someone else to do basic graphics for me. It's either that or ASCII art.

4) Battle: The battle system must be designed and implemented; this will come in parallel to the stats tweaking, even though essentially the two will be independent.

Getting through this one chunk at a time won't be too much of a challenge, though getting motivated to actually DO it will be. Too much Team Fortress 2 doesn't make for a very productive code monkey.

Sunday, June 8, 2008

Ruminations on Casual Games

There has been quite a bit of talk the past couple of years about the growing casual games industry. Although previously most casual games were purely free Flash or Java based internet games, Nintendo has started an annoying trend of trying to cater directly to this so-called "casual" crowd with their newest consoles (most specifically the Nintendo DS and the Wii). To the absolute chegrin of "real" gamers (ie people who actually CARE about video games), both consoles, especially the Wii, are drowning in what is commonly referred to as shovelware: pet and baby care sims (insulting games for the little girl tween market that requires its own angry post), movie tie-in games, and so on, each one with a lower production value than the last.

So here's the biggest question for any developers: what, exactly, constitues "casual" gaming, and what can we do to accomidate this elusive market with extremely fun, high quality games? And are people ignoring the fact that many so-called "hardcore" games could, in theory, be fantastic casual games?

Well okay...a casual gamer...a few things come to mind:
1) not interested in getting into a game too deeply (ie want to play quickly and be done with it)
2) not interested in spending lots of money on equipment or games
3) not interested in getting involved with the culture around a game (outside of maybe a casual MMO such as RuneScape); if there IS a culture it needs to be completely casual as well
4) zero learning curve, but there is room to allow for increased difficulty or it could get boring, even in a short amount of time

There are a few examples of more "hardcore" games that could easily be considered more casual, or have elements of casual games, except for a few key issues. Team Fortress 2 has excellent class balance, and is extremely condusive to pick-up-and-play. Play the Pyro and you're guaranteed to at least enjoy yourself, even if you're terrible at the game. The problem? Same as all online multiplayer FPSes...the culture that has built up around it can be extremely harsh and unforgiving, which is not something casual gamers are prepared to deal with, nor should they have to. Portal is another excellent example; they story and atmosphere are very fun, and the puzzles are challenging. The fact that it is very rare for the character to die is also very appealing. The problem with this game is that, although you learn new skills in each level, it's very hands-off in term of instructions, and even after blowing through the main game I had huge problems getting through the very intense and challenging boss battle. Katamari Damacy, Ratchet and Clank....the list goes on.

So say we have a game similar to TF2 or online mutiplayer game with a strong focus on fun, maybe some puzzles, doesn't have to be a first person shooter. The first move would be to make the controls absolutely transparent, possibly with a pull down menu in the corner and can easily be dismissed and turned off (this is another issue with TF2, the keyboard commands can get confusing for any but the most hardcore FPS player). Since it's an online multiplayer game, the environment should be more condusive to teamwork (a la TF2) with less emphasis on destroying the other person (even to the point where the "adversary" is a computer like in Portal). Along these same lines set up very strict etiquitte rules for servers, or make it very easy for someone to turn off communication and to play on a private server or alone, and allow players to easily message admins about players breaking these rules.

Anyway, this post is quickly turning rambling; I may run with this and try to post a real design later. The casual gamer market is quickly becoming very important, mostly due to the fact that it is obviously becoming very profitable. With more care and planning, all casual games could easily be elevated to the level of "gateway drug" as high-quality, but low-cost as Katamari Damacy that make people realize how fun video games really can be (as an interesting side-note I think Katamari would have sold much better if it had been marketed more as a casual game, but unfortunately it was released on PS2, and before the Wii or DS). Check back for a possible design later!

Sunday, May 25, 2008

Design Challenge: MMORPG for Children

An adult, 18 years or older, must be the one to set up the account. This registrant would be in charge of all account administration, including assigning "levels of trust" to other players. This would probably be most easily accomplished by setting up a control panel within an internet homepage for the game.

The "levels of trust" would break down as follows:
Level 1 is a stranger, the child and the other player would have no way whatsoever to communicate.

Level 2 are players the child is in a group with. Their communication is extremely limited; the child will have access to an easy to navigate, very limited menu of pre-determined
sentences, expressions, and emoticons. Any communication within the group will be displayed to all group members. Groups must be set up by an adult, and a child cannot join the group unless the player who started it is at least a Level 3. Blocking will not carry over; the adult should be warned if the group contains blocked players.

Level 3 is a friend the adult added. The child can choose to communicate directly to them by clicking on them, but only through menus. The menus will include a larger variety of more detailed sentences and emoticons for the child to choose from than the group menus.

Level 4 is a completely trusted friend. The child can initiate individual messaging (IM will have an extremely powerful language filter) with this player.

All these levels can be granted and removed at will by the adult controlling the account. The adult can also choose to block certain characters and/or all Level 1 players. A blocked character will not even be visible to the child, and the child will not be visible to the other player. Being in a group together instantly raises up a Level 1 player to Level 2. If there is an issue with other group members an adult can choose to petition the group leader to remove a player, petition the admins to ban the player, and/or simply remove the child from the group. Children should be free to join and leave approved groups at will at any point in the game.

All conversations between the child and other players (including groups) will be logged and sent to the adult's account. The adult does not explicitly have to approve all conversations, but if they find something offensive, there should be a "report" link included, where an adult can contact an admin and outline their complaint. Any reported players will be blocked for the child, and their comments will be reviewed by admins to see if a banning is warrented.

As a step to prevent adults from simply starting an account for their child and neglecting to monitor their actions, the account will be declared inactive and suspended if the adult does not log into their account's website at least once a week and/or if their unread communication logs reach over a certain point (say 100).

Tuesday, May 20, 2008

Even More Detailed Game Design!

So after a few pretty heavy TF2 sessions last night (that game is a freaking time sink, I'll tell ya...) I started working on my game design again, and finally penned a fairly detailed "round cycle", as well as laying out a few battle details. I'm going to figure out a way to start play testing it here soon so I can work out all the stats (I'm assuming this will take quite a while).

Basic round consists of:
1) Sending out scouts (these will be human employees in all cases unless a faction has a controllable unit and chooses to send that out instead) to explore the area. Towns and other factions territories can be scoped out during this time.
2) Selecting the number of units to dispatch for missions and choosing a target (either a town, another faction's army, or a faction's base)
3) Send out your units to attack the target. Details on both battle with factions and town raids follow.
4) Claim any territory won (ie claim resources, new bases, new troops, etc)
5) Use resources and start again

Battle Details:
1) Controllable units must be explicitly assigned their first target. They will continue to attack this target until either they die or their target dies. They cannot be re-assigned to a new target, only told to retreat if necessary. If they manage to kill their first target, they will simply move onto the next closest target.
2) Swarm units (ie non-controllables) merely attack whatever is closest. They cannot be called to retreat and cannot be given explicit targets, just "dropped" in a specific area to do damage.
3) After a battle all surviving units are "healed" back to full health.
4) After a battle the dead units are all transferred to the winning side as either new units or resources, if the faction requires corpses.

Town Raids:
This will be the primary way most factions get their resources, with the exception of the Juggernaut faction. Humans, food, water, animals, weapons, armor, and money are all obtained in town raids.
1) If the faction does a town raid, they cannot choose to do a battle phase for the rest of the round. The humans of the village can do minor damage, so units need to collect resources, heal, and make use of the resources they obtain. Raids can be just that, raids, or can eventually lead to the destruction of the entire town. At this point, if the town is stripped of all resources (including inhabitants), the faction can choose to build a new base here.
2) The first faction to raid a town effectively "lays claim" to the village. In this case, if an opposing faction chooses to raid the town, they will have to first engage in battle with the claiming faction in order to run them out. At this point they would now have claim to the town. This, again, continues until all the resources in the town are exhausted, leaving the final claiming faction in charge of the land.
3) The claiming faction can choose to engage in battle over the land, or, if they are not strong enough to stand up to the opposing faction, can choose to relinquish the land until they are stronger and can fight off the opposing faction.
4) Naturally raids on other faction's bases are carried out in a similar fashion, except the resources obtained include the other faction's units (however many are at the base), and whatever other resources are being stored there at the time.

That's about all I have laid out for now, I'm still piecing a lot together but it's moving along fairly well so I've been pleased with my progress. More updates as this develops.

Monday, May 19, 2008

Game Update: It's All In The Design

After discussing my ideas with Micheal, I've modified the game design quite drastically. It's still a zombie RTS affair, but he suggested developing factions, and after having a lively discussion about it, I felt this was the best (and most fun) way to go.

So right now I have the following factions: Bio Zombies, Voodoo Zombies, Parasite Zombies, Juggernauts, and Survivors (ie humans). Each faction outside of the Juggernauts, and to a certain extent the Survivors, also can have animal units which have higher speed and strenghts, and whose stats can be transferred to the base units if they infect a human (or attack a base unit). Half the units are controllable and half are not.

Right now I need to really sit down and write out the ruleset, another thing Micheal has been exceedingly helpful with since he's a big RPG/RTS guy. I've been looking to Magic: The Gathering and D&D for help in this area, since my experience with these types of games is horribly limited. I'll probably read over the Starcraft manual too, though I'm unsure if it will have the kind of detail I'm looking for.

Despite the fact the design process is going to take quite a while, I've got a pretty good start on this; the coding gets easier with each new project. I've possibly mentioned this in my previous post, but I'm going to do the game in C++ first then try to port it to Lisp later on.

Hopefully I'll have more updates on a fairly regular basis as the project progresses.

Friday, May 16, 2008

Basic Outline of a New Game Idea

I came up with this while joking with my friend about what kinds of video games I'd like to make (my answer was "one with zombies and kittens. Oh yeah, I'd like to do an RTS and/or RPG as well").

Genre: Combination RTS/RPG. There is leveling involved, as well as organized battles.
*Start with just AI enemies
*Look into adding networking later

Premise: The player is a bioweapons developer for a warlord. There are many warlords with their own bioweapons developers in different parts of the world, which effects the kind of specimens you have to experiment on. For example, although naturally you'll always have humans around, a Russian nation would also have bears, wolves, etc. Humans are "stock" weapons and won't be as powerful as an equivalent animal weapon.

As the developer you are tasked with creating the superior virus for infection. You must collect samples, mix and match, and experiment. Your weapons can be put into battle, where they will either succeed (allowing your weapons to level up and giving you access to your enemies weapons) or fail (resulting in you going back to square one, either because your weapons die or get taken by the opposing force). The developer can take samples from a successful bioweapon to produce new bioweapons, and once again are able to mix and match new viruses with the new samples to produce even better new stock. However, of course, this is limited by both a level cap and the number of times you can actually take a sample from a single weapon. Details on this still need to be worked out.**

**(I'm not claiming this idea is at all original, but I haven't really seen much that follows this idea...though apparently there is a Half Life 2 mod called Zombie Master that has a slightly similar idea. Naturally a lot of credit goes to the Resident Evil franchise as well.)

The programming language will likely be either Lisp (leaning towards this) or C++, maybe both if I'm stupid enough to not want to sleep ever. Unless I can find either an EXCELLENT sprite making program or someone to design sprites for me, this game will likely be text based, as I'm not a graphics person and not at all interested in trying to figure out the graphics end of it. I'm going to try and rope in my sister, but I'm not at all confident she'll be able to help in any capacity outside of drawing me some great pictures, since as far as I know she doesn't know how to do game graphics either. Updates on this as they come, I need to start designing it soon though or I'll lose interest and never get going.

Thursday, May 15, 2008

Gooeys and...Something Clever About Usability

The other day I wandered into my boss's office and she was showing me the new system that showed her how many appointments were scheduled for the testing labs throughout the month. She was complaining that the new system did not have a way for her to view the name of the students who had made the appointments, and overall it looked like the interface was highly confusing and unproductive.

At the risk of not being very descriptive, the screen is basically set up with a toolbar frame to the left hand side where the lab and date could be selected. The rest of the screen was occupied by what resembled a weather radar...a month was shown as a line of days, one on top of the next, and the appointments showed up as colored blocks in each strip. The color indicated the amount of appointments at the moment; ie, white for none, blue for 1 to 3, etc. I was marveling at this, more because it was so overtly unnecessary for the task she needed to do: just see how busy a lab was going to be on a specific day.

Having just finished an excellent GUI class recently (my mind is clear enough to realize how good it actually was), I began thinking quite a bit about, first of all, how would one effectively display information like this in such a way to be easily accessible, understood, and useful to the user and, second of all, what the living hell possessed the programmers to change it the way they did (BSU in-house applications in general is a UI nightmare, but I'll get to that in a moment).

As an exercise, what are the tasks necessary for this kind of application, at its very core? Display data based on reservations made in a lab. How should this be displayed? Would it be easier to do a day by day or have a full month? Or even a year? We would certainly want to accommodate for at least three levels of view: daily, monthly, and weekly. How detailed would the information need to be for each of these views? If you're looking at daily you'll certainly want to see specifics: names, times, etc. This would be easily filtered by lab selection, as well as narrowing down the time span to search. Weekly...less detailed. Just indicate the number of appointments each day, allow for filtering by lab. Monthly...I could see that as just a larger weekly view, but this could arguably be made even less detailed.

In the long run how the month view would completely depend on how the day and week view were formatted. Just having a calender would seem to make sense immediately, but considering it for a second makes the flaws in this obvious; regulating so much information to such a small space would make it quickly unusable. You could also, rather than organizing it by date, organize it by lab. But this again could be difficult because it is less intuitive to navigate by lab than by date. Limiting the view to a specific lab would also be too restrictive in many ways.

Anyway, just food for thought, I'm incapable of designing something like this off the top of my head, but I may sketch up something later just to do it. This all got me thinking about another issue with Computer Science in general's so focused on the theory that, when it comes right down to it, many CS people don't really know how to make USEFUL software for people. I'm sure the codebase is (fairly) solid with these in-house apps, but the fact is usability was obviously not even on their radar. Having to help lab patrons schedule an appointment is a nightmare in more ways than one. I also faced an interesting issue during finals week; when pulling up a patron's list of lab appointments, it went past the end of the tiny window. Not only was there no scroll bar, the window couldn't be resized. Fortunately the Page Down button still worked, but the first time this happened I was completely thrown. What's the point of displaying information like this when you can't easily see ALL the information?

During my GUI class I'll be the first to admit that I was one of those "I just want to code something" people. CS people, and coders in general, are like that a lot of times...they're so busy imagining the back end that the front end is just slapped on at the finish. Even the lab appointment display showed this hastiness and disregard; the coder obviously spent all his time focused on HOW he could make the UI look that way, and didn't stop to consider if it SHOULD look that way.

Monday, May 12, 2008

HackerTeen: O'Reilly Media's New Graphic Novel For Teens Who May Fancy Themselves as Hackers

I recently got the opportunity to get advanced copies of a new graphic novel by O'Reilly Media called HackerTeen (I know you didn't gather this from the title), whose intent is to inform teenagers with an interest in computers/hacking of various computer/hacking topics in the hopes of making them more responsible computer users/hackers.

The plot is actually rather involved for a (seemingly) short graphic novel; after joining the HackerTeens, protagonist Yago has to juggle his responsibilities to his school and his family, and in an effort to help out financially at home, gets dragged into the middle of a sticky legal and social situation. In the meantime his mentor and teacher, HackerIP, is also facing legal repercussions of Yago's actions, as well as fighting various invasive technologies from being adopted by the government. This is, to be frank, an awful summery; the plot, as I mentioned, is very involved and, although everything does fit together and revolves around the protagonists and a few (as yet not officially introduced) shadowy villains, there seems to be multiple layers and threads to the story. I can certainly see the advantage to this, since the quickly shifting plot line makes for a rather exciting read, but at the same time I felt there was almost too much going on at once.

Then again this is literally the single negative comment I could make about this book; there is certainly lots and lots to like. Yago is introduced as a frustrated and bored student with a fascination with the computer, an attitude I could most certainly remember having in high school. His parent's frustration and confusion with his obsession was, once again, strikingly similar to how my own experience. After being encouraged to follow his passion, Yago's attitude makes a quick 360, and the rest of the novel establishes him as an enduring and positive role model.

Just to mention quickly, the art style is an interesting mixture of Nicktoon and Final Fantasy; very bright and animated (to use a cliche, not very descriptive term) with exaggerated hair styles and bizarre (if questionable) fashion choices for the main characters. The panels flow into each other and are not clearly defined, all of which is very appropriate considering the plot and subject matter, but I have to again mention led to some confusion on my part as to what exactly was going on.

Last but not least, of course...since this book was published by O'Reilly Media there is a certain expectation that the material is going to be highly informative and intelligent, and HackerTeen does not disappoint. As a computer nerd who wasn't able to really explore computers until college, I was deeply impressed with how straightforward the references were. Linux, open software, and just general internet terms are thrown about in a completely non-condescending manner; rather than boring readers with a block of text as footnotes, links to the HackerTeen website are liberally sprinkled about to provide a starting point for teens interested in exploring the topics mentioned. When diving into the computer world head first nothing is more helpful to the novice than a reputable starting point in the middle of a metaphorical ocean of information. Unfortunately at the time of this writing the site is not quite finished yet, I'm looking forward to seeing how the referenced webpages will be set up (hopefully there will be very meaty related-links sections). The highly responsible use of the word hacker was especially refreshing, and the comic did an excellent job of still making so-called "white hat" hacking look engaging, as well as showing how "black hat hacking" has negative consequences without getting overly preachy and contrived.

I wish that HackerTeen had been around when I was in middle school; this is exactly the kind of story and subject matter I would have devoured, and probably would have given me a better head start on my own computer career. Opening up the computer culture to 14 year olds is certainly not as easy task, especially since the public in general (ie parents) appear to be woefully ignorant of...well...anything involving computers. For lack of a better way to end this, I'll just say this graphic novel comes highly recommended for teens with an obvious interest in computers.

Friday, May 9, 2008

SDL_image is such a difficult child...

The past two days or so I've finally started doing some real coding with OpenSolaris, more in the hopes that I'd finally actually get some WORK done, but also with the intention of figuring out how well the system would perform with compilation and whatnot. This morning I spent a lot of the day installing a few minor tools as well, and have been making attempts to get everything running together.

The first task was to install GCC (which is an industry standard and, as I mentioned, should be included with a base install, but I'm not going to split hairs) using pkg install gcc-dev. Whoo, now I have gcc/g++.

Second, installing nano. I know plenty of people live or die by vi/emacs/whatever, but I have had nothing but trouble with vi every time I try to use it, so I went with the little baby text editor (had to install from source).

Third...and hardest...getting SDL_image to link with my program. The biggest issue I'm running into using this system is the fact that things are installed in /usr/local/whatever, while everything else is installed in /usr/whatever. Just adding them to the $PATH in .bashrc worked for a few things, and I managed to get everything to compile without a hitch, but running was a whole new bag of fish.

Every time I try to run it, I get "SDL_image library not installed, die immediately" errors. Unfortunately I couldn't seem to figure out where to add the library path...not as simple as adding an include path here and there.

Enter crle. Apparently this little utility is used to modify the library search path. I read over the man page a little bit, then tried to add the search path using the command crle -l /usr/local/lib...Bad. Idea. Read here, this is exactly what happened.

So, long story short, ultimate fail. Fortunately I'm no stranger to re-installation. Hopefully more updates later, once my world is fixed.


I took the opportunity afforded me by a full reinstall to give my system a little more room to breathe, with an upgrade to a full 35 GB HDD space (the main reason I wiped rather than just resetting everything as outlined in the above website). After doing this I read the above linked page (VERY carefully) and managed to set the correct load paths:

#crle -u -l /usr/local/lib

The paths can be verified with the following command:


This is an odd quirk of Solaris, but of course the OS can't be blamed for silly mistakes I made in configuration. For the most part, with enough knowledge and google skills, getting comfortable with a new system's details really isn't too painful, though sometimes huge screw-ups are unavoidable.

Finally, my compilation:

$g++ -o Play `sdl-config --cflags --libs` -lSDL_image -L/usr/local/lib

Followed by:


Unfortunately there are still bugs to be worked out...but for now I'm just happy to have made progress to the point where I can run things :P

Wednesday, May 7, 2008

More Adventures in OpenSolaris

After successfully getting OpenSolaris up and running last night, I decided to test it in the one area I have been unsuccessfully struggling with while using Mac: SDL. This is a pretty essential C++ game programming library in my opinion, so getting it to work in OpenSolaris was something I was anxious to try.

Mac. You are getting one warning, and one warning only. OpenSolaris has SDL installed by default and automagically detects it with Sun Studio Express. You are built on a BSD core, start acting like it, I've REALLY had it with these frameworks. Seriously.

Sun Studio Express was fantastic to use, which I expected since I'm a huge Netbeans fan, and this basically IS Netbeans, just with a C/C++/Fortran focus. I did notice that I couldn't just build and run my app from the IDE right away, but this was rectified in seconds; all I had to do was specify -lSDL in the Additional Options field under the Command Line option in the Linker category of the Project Properties. Whew! (Believe me, it's easier to find that it sounds!)

Although it is a fairly simple matter to get the application to build and run from within the IDE, it was trivial (and probably better in the long run) to build in the command line:

And now running!

All credit for this example goes to lazyfoo's excellent SDL tutorial for the example and the pictures.

Now I will openly admit, for the sake of full disclosure, that this is more of a rant against OS X than anything else. I knew already that Linux is FAR better suited for real dev work, but being bullheaded as I was I wanted to try and get a full C++ environment working seamlessly for me, if for no other reason than to prove I could. I spent literally hours upon hours trying to coax the Mac into working for me, while this example took me less than an hour.

My less selfish and whiny motive was to simply show how easy it is to get up and running with simple game dev using SDL on OpenSolaris. Anyone looking to start out with game dev should be looking at Linux/Unix in general. In particular, if you're looking for a Linux/Unix environment that takes maybe an hour or so to get up and running and has everything you could need to do this dev work available to you with minimal extra installs, OpenSolaris is probably the way to go.

Tuesday, May 6, 2008

OpenSolaris, or How I Learned To Stop Fearing Virtual OSes and Installed Sun's New Solaris System

Tonight I spent a few hours with OpenSolaris, Sun Microsystem's newest Unix offering aimed at developers. Just to be all technical about it, I installed the system on my Intel iMac using VirtualBox (my first, EXTREMELY positive experience with this application, also from Sun); 1 GB of system RAM and 16 GB of HDD space were delegated to it. My previous experience with Linux/Unix/BSD includes Slackware, Red Hat, FreeBSD, Debian, and Arch Linux, so I'm pretty comfortable with getting down-and-dirty when I need to. I took a lot of screenshots, so bear with my over-enthusiasm for pretty pictures.

The first thing I did was boot into the LiveCD just to get a feel for how this system was going to work for me. Although it booted slowly (to be expected with a virtual emulator I suppose), I was eventually greeted with an extremely clean, appealing Gnome desktop. I have never been a huge fan of Gnome (I'm more of a Fluxbox user myself, I love ultra-clean), but I have to admit I was very impressed with the desktop.

Here's a shnazzy shot of it running on my Mac!

I didn't mess much with the LiveCD, more because I was already planning to install the OS on my hard drive, so I didn't get a chance to explore how the LiveCD saves (or doesn't) live sessions. I do, however, want to note that I couldn't get the wireless working even though it obviously recognized my card. Another odd issue was with my sound card...not exactly necessary right now, but since my passion is game dev, this could quickly become an annoying issue.

Anyway, now for the real fun: the installation!

Unlike every other Linux OS I've ever installed this installation was a dream...if I remember correctly I went through maybe 3 screens total, and the next thing I knew the system was happily installing on my computer, as shown in the picture. I'd complain again about the speed, but it's easily the fastest Linux install I've ever had, so forget I even mentioned it.

After rebooting I set to work getting the system ready for my awesome coding skills, which basically includes making sure C++, Java, and a nice IDE are installed. Somehow my internet magically started working as soon as I booted, which was a nice surprise, because I'm very sick of having to configure my internet on Linux systems. Just saying. Unfortunately the sound didn't automagically fix itself, and I'm hoping getting it to work without too much hassle. I also noticed that CDs and DVDs didn't seem to be mounted...though honestly I'm not sure if this is an issue with the OS itself or one with VirtualBox...another thing to explore at a later time.

The one thing that did strike me as very odd was the fact that the GNU C/C++ compilers weren't pre-installed. However, this gave me a chance to explore the Package Manager. Overall package management is set up very similar to Debian, definitely a good thing because I felt that the package management was the main area where Debian shined.

The two applications I immediately downloaded were Netbeans (hands down my favorite IDE), and, more out of curiosity, Sun Studio Express (through the ss-dev package), an IDE I had not heard about until now, but which I quickly realized was just Netbeans with a focus on C/C++/Fortran.

Obligatory command-line shot, with both Netbeans and Sun Studio Express installed!

Overall I was deeply impressed with this system. I'm looking forward to spending more time with it and trying some real development projects. Although initially I was unsure whether I'd even bother keeping it installed on my Mac, since I have it set up for dev work as well as an Arch Linux and a FreeBSD system, the speed with which I managed to set up Solaris with some powerful dev tools has convinced me to work with this system regularly in my coursework.