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.