Update coming soon!

Now that I’ve graduated from school, I’ll have a little more time and energy to put into my blog! I plan to do an update; add some content, change some of the looks, etc., so come back soon.

In the meantime, I’ve been regularly Tweeting, so be sure to follow me there.

To-Do

I’ve got to get this thing up and running once again.  Here’s a checklist of what I’d like to do to the site before I begin to add new content:

1. Change the title and description.
2. Re-do my Categories and Tags to more accurately reflect the content of the post.
3. Re-organize and update my links. (Decided wasn’t necessary)
4. Re-do my Books page to include photographs of the books.

These should take me no longer than a few hours.

I also would like to add more visuals and enhance the look.  Since the last time I was posted pictures WordPress has added the ability to upload photos from my computer.  This will make it much easier to add photos as before I would have to log in to my Photobucket account, upload my photos, get the URL to the image and paste the URL in my blog post.  So, hopefully I’ll let my creative juices flow a bit more and we’ll see some more visuals up here.

It’s been awhile

Quite a lot has happened since my last post. I’m planning to update this soon. The major news will cover:

• My summer internship with Thetus.
• Switching to Linux(!).

Posts Imported

I’ve imported all the posts made in my other blog, JavaSaurus.

update(Observable o, Object arg)

Usually I have some individual programming to report on, but fortunately this term my CIS course revolves around individual students creating their own game or simulation. To go along with our game, we are to keep a blog to track our development and design decisions. Because of this, I haven’t been doing much with this blog, but I encourage you to check out my CIS blog JavaSaurus.

On another note, I’ve removed myself from the ETG – Spacecraft project due to time and motivation; neither of which I found myself to have much of, unfortunately.

Next term I was able to get into an upper-level Game Development course using C++ and Ogre. I’m very much looking forward to that, as we get in pairs and make a game proposal in the beginning of the term, and at the end of the term we’re graded on how we met our proposal, as well as the overall quality of our game. It will be my first time using 3D, and I do want to post screen-shots of assignments and development to get something exciting on this site.

Intended Updates

Sorry for the lack of updates, I’ve been overwhelmed with work to do, but I have plenty to update. I’ve started graphical programming, so I’ll soon add this new project along with screenshots, simply titled Blox for a lack of a better name, and I’ll add programming competition problems to solve. These problems are from my university’s annual programming competition, and completion of any will earn any student extra credit in my current CIS course, so of course I have every intention of solving a few. I also will add my solutions to the weekly CIS assignments and add the new assignments, as well as reformat the CIS page into a drop-down menu on the sidebar to choose which assignment to view. Check back soon for these updates!

MUDd UPDATE

Well, I would like to continue development with this game and implement the previously mentioned features. But, first, I’m going to have to re-acquaint myself with C++ and my game. Luckily, I heavily commented all of my code (no really, I didn’t realize how much commenting everything really helps you understand later). Unfortunately, I have plenty of other things to focus on, like my most challenging course load yet and learning Java. Hopefully I can find some time to work on this project between other priorities.

The Return

Well, despite my high hopes for progress during this past summer, programming ended up taking a backseat to . . . summer. Now that school has started, I’m back into my CIS courses, and this time it’s all about Java . . . for the whole year.

Because I am also taking physics the whole year, my eyes are currently set on Robocode for my extra-curricular learning. Aside from the fact that programming a killing machine is fun, Robocode will allow me to simultaneously use my Java and physics; something I have never tried before.

Currently I intend to document and post my work from my Java courses on this site, with two reasons for this in mind. Not only will it help to keep my CIS in the foreground of my learning, but it will act as a collection of my work for anyone to view as well as teach me a few skills in creating and managing a portfolio.

From Day 1 to Now…

Well, I suppose I will start by explaining how I started my current game, what I wanted to do with it, and then work my way up to it’s current state.

After spending a lot of time reading my C++ and game programming books, browsing online tutorials and forums, and checking out source code for various games, I had plenty of ideas of what I wanted in my game. That wasn’t the problem, I’ve played my fair share of adventure games and RPG’s, I knew what I liked and what I didn’t like. The problem was finding the C++ code to do it, and making it all work together. So my first attempt, before I knew any OOP (Object Oriented Programming), was to just have a bunch of global variables for all the characters in the game, and have the player run through a bunch of if-else statements.

There was no combat, no numbers, just one-swing combat. The computer would calculate some random values for the two characters attack, compare them, and whichever was higher, there would be an output along the lines of “The troll slashed you across the face! You die!,” then the program would exit. So, that was stupid, and I knew it, but it suppressed my cravings for a real game for the time being, so I abandoned that “game” and went back to the books.

Once I got into OOP, I tried again. Starting from scratch, I made up some quick menu’s to allow the user to enter how many randomly generated enemies they would like to create. This ended up taking a while, and several visits to instructor and teaching-assistant for my C++ course. So once I worked out all the bugs, I effectively used a vector to dynamically store all the enemies. Now I wanted to fight them. So I added a character creation process, which was composed of generating a random enemy, showing the stats to the user, and asking if they liked them or not. If they did, they would get to name their new character, and then it would be stored in the same vector with the enemies. If they didn’t like it, it would be deleted, and a new random enemy would be generated and displayed to the user. This process would repeat until the user had found something they liked.

Now, I was able to use what I had previously worked on in my first game, but instead of using random numbers for the if-else statements to decide who would win, I used the 2 characters stats. Keep in mind, there was no “multiple rounds,” where one character would strike the other, and their health would decrease, then it was the other character’s turn. No, it was still just comparing the 2 characters’ Attack, and whichever was higher, they would win. That was it. The cool thing though, was that I was able to run through the vector of enemies and have the player fight each one. Well, that was enough to suppress my cravings for a real, playable game, so I abandoned it and went back to the books.

Since I had combat and character creation covered, I wanted a way for the user to be able to move about. All the user could do in my previous game was generate their character and some enemies to fight, and then select the menu option to “FIGHT!” The first idea that came to my head, was to create a class called Room, and each Room would have a description, then I would make a whole bunch of these Rooms, store them in a vector (I was into vector’s at the moment), and start the user off in the first Room of the vector. They wouldn’t really be in any Room, rather, the first Room’s description was read, and then the user would have to enter in something, and their input would go through an if-else sequence to determine whether or not they’re allowed to go to the next Room. If they entered in the password, then the iterator, that was initially set to point to the first Room in the vector, would be incremented, then pointing to the second Room. Then, as with the first Room, the description would be read (through the iterator), and the process would start over.

This was only an idea though, I had never put it in code. I didn’t really like the idea…well, I knew I could do better. So, I continued to read my books and browse the internet, and I happened to find several fairly well written articles on Linked-Lists. I remembered that I had previously seen these articles, but at the time I wasn’t ready to try and understand what was going on. Well, I was ready now, so I carefully read through them, understood them for the most part, enough to start using them. I know had my method for walking through Rooms, I liked it, and it was going to be a challenge.

Starting from scratch once again, I came up with some Linked-List implementations, particularly Double Linked-Lists, to represented the Rooms that the player could walk through. Although this method was going to work, I knew that I wasn’t going to be utilizing the real features of Linked-Lists that they are intended for, which is random insertion and deletion. I wasn’t going to be having Rooms randomly created and inserted and deleted in my chain of Rooms, I was just going to explicitly create each and every room, and chain them together as a double linked-list.

So I came up with my Room class that I would comprise my double linked-list of. All these Rooms had a description(a string), an exit(a string), and a pointer named Next to another Room, and a pointer named Previous to another Room. This is how a double linked-list works: each object, in my case Rooms, had a pointer to another object of the same type, in my case Rooms. This way, each Room knew what the next and previous Rooms were, since it had a pointer to them. For my game, this would allow the user to start in the first Room, the head, and then when they entered in the exit for the room, the Room that their current Room’s Next pointer pointed to would be set to the user’s position. Once this happened, the description of their new Room would be read, and the user could now enter in something to allow them to go to the Next Room, or go to the Previous Room (hence the need for double linked-list. A single linked-list only allows to move forward, or next). This process would be repeated until the user got to the end of the chain of Rooms, or the tail, where the loop that was processing all the Rooms would end and the user would go back to the menus.

Now that I had my movement covered, I wanted to incorporate combat. I knew how to do it, and it was fairly simple to add, with no problems. I would create a Monster class, and add to my Room class another pointer, this time pointing to a Monster. Now, when the user was in a Room, they could fight a Monster, since they had access to it via the pointer-to-a-Monster that every Room had. So, when the Rooms were created and chained together in the double linked-list, I just added the creation of a Monster, and set the appropriate pointer to point to this new Monster. Now, each Room had a description, an exit, a pointer to the Next Room, a pointer to the Previous Room, and a pointer to a Monster.

Now that I had correctly set up the necessary ends to meet that would allow for combat to take place, I needed to come up with a much better combat process then what I had used previously. Although I came up with something new, it was still nothing amazing. Each character in the game had the basic attributes, Health, Speed, Attack, and Defense. The process of combat was actually a member function within the character class that made up all the character’s in the game, and it went like this:

1. Generate a random number and modify it by each of the characters Speed attribute, then compare the two numbers.
2. Whichever character had a higher random number(modified by their Speed) was marked as the Attacker, and the other was the Defender.
3. Then, the Attacker would strike the Defender, and the Defender’s Health would be decremented by an amount equal to the Attacker’s Attack attribute.
4. Check to see if the Defender is still alive, if they are, then the Defender will strike the Attacker, and the Attacker’s Health would be decremented by an amount equal to the Defender’s Attack attribute.
5. If the check failed, and the Defender was not alive, then the Attacker would be returned from the function.
6. Check to see if the Attacker is still alive, if they are, go back to step 1.
7. If the check failed, and the Attacker was not alive, then the Defender would be returned from the function.

So whoever won the fight would be returned from the function, where their name would then be announced as the winner.

To sum everything up, at it’s current state, the user would be allowed to create their character, then they would start their journey. The first rooms description would be read (there were no monsters at the head of the linked-list), and the Rooms exit would be read, they would be prompted for input, if their input matched the Rooms exit(just a string), then they would be moved to the Next Room. Once they entered the next Room, since there would be a monster in it(the Monster pointer in that Room was pointing to a Monster), they would enter combat with that Monster. Entering combat doesn’t really mean anything cool, just that the loop that I described above would be run until one of the characters had no Health left, and the winner’s name would be announced. Because the combat loop is so simple, it executed in milliseconds, so as soon as the player entered combat, it was over, and the winner was announced on the screen… not very exciting, but it was a start. Regardless of whether the player won or not, they were still able to continue playing.

Once combat was over, the Room’s description would be read, as well as the Room’s exit, and since they came from a Room, the previous Room’s exit was read as well. This meant that the user was given 2 exits, one that led to the Next Room, and one that led to the Previous Room, so they were able to go back if they wanted. This process would continue until the user got to the end of the linked-lists, where they would go back to the menu, or if they entered in “quit” when they were prompted for input.

Well, that’s it, everything up to now. From now on, my posts will describe the features that I’ve added.