1. It’s funny, actually.

    January 28, 2010 by Stone

    I have a number of subscribers, and I delete a few spam comments, but it is funny to me how many of you remain anonymous. A few of you probably really do read these, and I would love to get your opinions and comments.

    Please, reply, let other people know that of the 19 users who don’t appear to be spambots, you are real, and you have an opinion.

    And an update: Java is going well, but it has been a rough couple of weeks and I’m a few chapters behind. I just got to the one about making the application run in it’s own window (awesome!), so I will be putting up some samples and some code in the next few weeks.


  2. Java: What is OOP?

    December 28, 2009 by Stone

    For the people who are not nerds that are reading this (all 1 of you), you may be wondering what Object Oriented Programming (or OOP) is, and why you should care. Really, you probably don’t need to care about it, but for someone like me, it represents an efficient and scalable way of writing code. The idea is that anything you might interact with in a program is actually just an existence of that type of object. To put it another way, you might have a dog. I also have a dog. If this were a program, both of our dogs would be part of the Dog class. This handles things that all members of the class Dog should be able to do, such as eat, bark, and poop. These are things our dogs have in common. If caring for your dog were a computer program, you wouldn’t be caring for just any dog, but your specific dog. My dog is named Chester. Chester is a different dog than Fluffy. They are completely separate, and have no relationship beyond both being dogs. They can have different names, different species, different eating habits, whatever, and what happens to one doesn’t affect the other. My dog is a Cocker Spaniel. His breed has no effect at all on Fluffy. In a programming sense, this makes sense. Suppose I write a game in which you catch a ball. Any time you play the game, the ball is the same, right? Now suppose I make another game in which you have a ball and you bounce it on the ground (these are boring games, but good examples).

    Which sounds better to you:
    a)Taking the same ball you just caught, and bouncing it on the ground.
    b)Taking the ball you just caught, putting it away, getting a new one (making a new one in this case), that is nearly identical to the first one, and bouncing that.

    I hope you said A. This is the big benefit to object oriented programming. I can re-use the ball anywhere I need a ball. If in a new game, I want the ball to be deflatable, I can add the property to the ball in that game without changing the rest of them (by extending it for those who know the terminology). If I decide that I got the concept of a ball wrong, and it should be square instead of round, I can change the ball class to match this, and it will become square in all the places that it is used. But still, only the one set up to be able to deflate will be able to.

    I hope that made sense. In terms of the Roguelike I hope to write, this should mean that things in the game can be simplified heavily. A dragon is the same thing as a cockroach: both are part of a group called “monsters” (or maybe “enemies”). What makes the dragon big, scary, green, fire-breathing, or two-headed is all set after the program already understands that it is a monster, and has the properties of a monster (HP, experience point value, etc.). I could set up any number of monsters in this way no matter how different:
    name:”giant ant”
    description: “a giant ant. Quick, get a can of bugspray!”
    HP: 1
    exp value: 1
    damage: 1
    message to the player: “I’m a giant red ant. just step on me.”
    and
    name:”big ogre”
    description:”A big mean looking giant with one eye. It is staring directly at you, as though it can see your soul.”
    HP: 150
    exp value: 200
    damage: 100
    message to the player: “ROAR! BIG OGRE CRUSH YOU, PUNY HUMAN!”

    and the game can handle both of those. In this way, you can encounter a wider variety of enemies, and I didn’t have to script each one on it’s own, just fill in a few blank spots.


  3. More on the roguelike project.

    December 24, 2009 by Stone

    I’m excited. I haven’t really had much ambition lately for new stuff, but the idea of getting this roguelike moving is fun. As a (self-identified) super nerd, I had a few ideas. I actually considered a Pokemon Roguelike. It won’t happen though, at least not for a while, since there is a LOT of continuity and a lot of data out there for Pokemon already.

    I considered recreating Mystic Towers in Rogulike format too. This is tempting, since the levels are already designed, and the game was fun enough to warrant playing through it again even though it’s like 20 years old. Mystic Towers was the first game I bought on my own (saved allowance for weeks), and the first game coming close to 3d that I had played. It was fun, some parts of it were scary (I was like 8 the first time I encountered a dark room with a loud monster chomping on me), and it was innovative for it’s time. Yeah, a lot of people will look at it now and think that it’s boring, or unoriginal (hint: it’s not), but it had everything a gamer wanted back in 1994: puzzles, half-assed physics (pull something off a shelf, it falls. flat things like money could be underneath movable things, you could escape a monster by being above it, and firing downward), monsters, a sense of urgency (you had to find a bomb and blow up the monster generator before it repopulated the tower. In the hard towers, you wouldn’t have enough spell ammo to take the monsters out again if you weren’t careful), and a cohesive story.

    So I might make that for my first stab at a roguelike, though I actually have a bigger ambition in mind that I’m going to discuss at a later date.


  4. I am writing a Roguelike.

    December 23, 2009 by Stone

    It’s been a while since I posted. Sorry.

    A roguelike is a computer game based on Rogue, which was one of the first computer games written. These games usually have simple graphics of ASCII characters, an ‘@’ for the player (represents a hero viewed from the top down), and letters representing enemies (such as a ‘D’ for a dragon). These range in complexity up to the likes of ADOM (which is hugely complex, with lots of things to do an explore, lots of skills the player can learn, and several paths through the game). These can also have quite a few themes, rather than just the mythical dungeons and dragons type theme. Notable games in this regard include Gearhead Arena (a roguelike centered around anime-style giant fighting robots, with you the player as an aspiring pilot. Actually, the whole game is even bigger than that, and totally awesome), and DoomRL (Based on Doom. If you’ve never played Doom, you’ve missed out on true gaming legacy. DoomRL is in itself a vast amount of fun).

    Roguelikes, if you can get over the lack of graphics, are really a lot of fun. They can vary in difficulty and complexity, so people of any gaming skill-level can jump into one. Because of some features they share with bigger games (skill points, leveling up, inventory, ect.), creating one is a good way to learn a new language, or test a programmer’s skills. I will be writing this in Java, which I am actually just starting to learn. I understand the concept of Object Oriented Programming, but it is time to see if I can do it (well, that and I have an idea that hasn’t been explored in a roguelike yet).

    More details to come. This isn’t started yet, so don’t expect a mini-site or progress for a while.