Well, here's the game engine as of the end of last quarter. No code included, but a good amount of documentation. Especially see the "ReadMe.txt" and of course the executable.

Well, there is quite a bit of room for expansion on that 2D isometric RPG, but it's going to have to be put aside for now. Because the Games Programming 3D has begun!

My RPG Rules: Lots of stuff is still getting in as we wrap up the final submission! I'm mostly focusing on the RPG Rules (not requirements, but I want to have a good portion of it implemented, and a decent amount that actually gets seen by a submission #4 "user" to show for all that time I spent planning out RPG Rules stuff. This is my focus since Mike and Joe consider the RPG Rules unnecessary extra effort for me to do and not them. I'm considering the possibility of using my RPG Rules classes for Games Programming 3D. However, I don't know the specifics of this right now, and I might end up working on a totally type of game them. At the very least, I'll spend lots of this coming break adding extra features to the game.

I have it calculate attacks (different types of misses/blocks and damage amounts) based on monster and character stats. These calculations (the specifics of which are pretty complicated) are based on my RPG Rules design. The results of an attack is displayed in the font engine scrolling display (one of the recent things I added is scrolling to the bitmap font engine text display, and equal sized lines of messages). A lot more of my RPG Rules is implemented, such as equipment, the ability to change equipment, and Feats, but these probably won't be used in the final submission.

I've also been doing a lot of general reorganization-type changes to most of the code files. Thus, I communicated with Mike and Joe to work on specific parts that can be added to my overall update.

Joe Path-Finding: Joe's been doing probably the biggest thing he's ever done on this project - path-finding. I've chatted with him a bit about what he's doing, etc, and it seems he has it working. And is improving it. The general algorithm is not tile-based. It involves the use of our "CanMove" function, which checks if a player can legally move on a particular spot. Joe says of the algorithm, "quasi-A*. I came up with the algorithm myself after reading about A* and a few other examples online".

Mike Adds Some Stuff: Mike meanwhile added some minor changes... Mostly changes to the maps, a new monster, and the ability to reset the level by pressing "r".

Here's what I think is the most important of what we have left. Communicate what you are going to work on. And do try to work on lots of stuff soon - today is Monday, and this is due Wednesday. Let me know if you think I'm missing something major in this list.

Path-finding - This was still pretty buggy at submission 3. Our attempt to deviate from the norm and make up a 2D ray-casting style algorithm instead of using A-Star is significantly more difficult.

Other Bugs - We still have some other noticeable bugs. Mainly the character screen is broken, the mouse clicking is broken, the full screen is broken, and at least one monster animation still has missing frames.

Graphics (SC animated .gif bitstrip!) more Sounds, more Levels (at the least, change the player sprite to something melee like a zealot or dark templar. And put in a final boss - probably something cool like an Ultralisk or a Tank

Monster Water Blocking - CanMove seems to be broken. I think it would not be unreasonable to get that working, and then make one of our monsters fly over water. But mainly get that working... monsters shouldn't walk through water.

2/22/2003
Delete Tile Sprites!: To load a new map, we need to delete the old tile sprites. This bug was giving us quite a bit of trouble. Earlier tonight I aimed Mike how stuff was doing, and he basically said "I was going to write the code to load new maps, but the tile sprites don't release!". So we had a lovely team debug-over-aim session in which one of us would delete something in our "TileMap" "MoveMap" method, share if it had any affect, and briefly discuss any useful results. After a good 1/2 hour to hour of this, Mike realized the tile sprites needed to be copied when moved around.

Meanwhile, the following quote unfortunate and offending results of Joe's recent progress: Me: "hey Joe... any progress? Tried out that bitstrip program I got at least?". Joe: "no". Well we all have finals next week, but I hope all three of us are still able to do a lot in the next few days.

RPG Rules Makes Some Progress: The RPG rules I designed look like they will probably be mostly implemented for the 6 melee classes. I spent pretty much my entire Winter break on creating and then balancing the rpg rules. I expect that when the player attacks the monster, my calculations based on his stats and the monsters stats will happen to determine hit chances and damage will be implemented. As will the rules behind things like equipment changing and leveling. However, I don't expect it to be that visible by Wednesday, because necessary game things to use the rules extensively are not implemented (for examples: displaying stats, graphically changing items, gaining experience and selecting class levels in which to advance).

One other very noticeable inconsistency between my medieval-style class system and the final submission is that since we couldn't find the necessary hundreds of frames of character/monster animations (and because we don't have an art department), all our 32 direction animations are Star Craft characters. But I think this is better than the alternative, which would be to find some mediocre sprite animations with only like 8 directions of animation.

2/19/2003 (Major News Update Between 2/8 and 2/19) Project:
Project Updates: The player can attack the nearest monster by pressing "a" (if in attack range). This has animations which we are working on. The monsters also attack the player when they get within a certain attack range. The player and monsters can die. When the player dies or kills all the monsters, an end game picture is shown and the game restarts.

We've still got quite a bit to go, but we're progressing. Obviously the game won't be a 100% finished product by Wednesday, but it will at least meet the final requirements plus some pretty cool features. Major things I want to add are:
-Some sort of basic at least preliminary combat system (at least loosely based on my RPG rules design melee classes).
-Add lots of monster graphics, and more types of animation for the player
-Add more sound effects
-Multiple maps, and a way to progress to the next map (probably kill all the monsters, or step on on a certain tile)
-Better path-finding! This means probably either getting our cool ray stuff to work a lot better, or reverting to tile-based A-Star.

We won't necessarily have time to get all of these things fully working fully. And this is not a complete list, but it is the major things on which I'd like to focus. Anyways, I have a pretty difficult final lab/project due Friday for another course (which was just assigned on Friday). So I'm going to be finishing that up for the next couple days. Then, except for a few finals Monday and Tuesday, I can focus on adding functionality to our final submission.

RPG Rules Saved: I had a crazy linker error on my RPG "rules" code that was putting it behind. Dave figured out the error on Monday. Once I can, I plan to get hardcore and get these rules working enough that I can attach them to our Monster and Player animation classes (this will probably include few breaks and little sleep). Hopefully I will be able to get a clean enough interface to encapsulate the RPG Rules behavior, except for methods like "Attack", "Equip", etc.

Although I do wish I could start working on deeply on this now (and other features, like making an actual character screen), I have other stuff to do in the next few days.

Copy Paste, Copy Paste, Copy Paste . . . ^n+1: Today (2/19) I found out why Joe complained about the time he spent making our player art. The only pre-made sprites with (32 animated directions of movement and attacking) we were able to find came from Star Craft. And the file format these were in is animated .gif's. As far as I could tell, DirectX doesn't read animated .gif files frame by frame. Neither does OpenGL. In fact, I don't know of an API that does. So Joe's been manually copy pasting (in a very tedious and unintelligent manner) each .gif frame one at a time into our .bmp file.

Next, I will describe his exact process:
-Open animated .gif file
-find correct walking frame
-copy walking frame (such as frame #87)
-paste frame in .psd document B
-resize document B from 128x128 to 64x64
-copy image from document B into document A
-move image in document A to appropriate position
-REPEAT (for the marine: 136 times for the walking, and 136 times for the attacking, and a few more for the death animation... and 136 more to add a different running animation)

BitStrip!: When I found this out, I was quite surprised. I mean... wow - what a tedious waste of time. I tried the first hand for 1/2 an hour (and got about 8/64 zerglings), when I realized how ridiculously boring and unnecessary this was. So I searched around on the internet for a tool that would automate this process (convert animated .gif's to some static format). My plan was that if I couldn't find something written, I would search for an API that capable of reading animated .gif's frame by frame. I would then write my own automated version of what poor Joe was doing.

After I was about to think that the only animated .gif converters in existence were .gif to .avi, I found a lovely little shareware program called "bitstrip". This is a pretty simple program that outputs the animated .gif frames to a .bmp in horizontal or vertical form. This totally negates the amount of monkey work Joe was having to do (although he already did it for 64 marine walk and 64 marine attack frames). A few simple modifications to these animation strips and/or graphic reading code, and I we'll now be able to put in a lot more graphics (various StarCraft monster graphics, and player deaths).

2/19/2003 (Major News Update Between 2/8 and 2/19) Side Stories:
Lots of Work: The quarter's been wrapping up, and my other 15 credits of classes (in addition to this course) have been giving me good amounts of final projects and such. Fortunately, 2 (sort of a 3rd one) of my 5 courses haven't been much work in general. I'm going to be smart enough not to take either Animation Algorithms or Image Synthesis at the same time as Games Programming 3D next quarter.

SE to CS: I have four quarters of classes until I meet graduation requirements for the Software Engineering BS. And four quarters for CS. That's how similar the two programs are at this point (SE grew out of CS). This overlap is also largely because many SE required courses can count as CS electives or count as credit towards a very similar CS course (including Liberal Arts, Science requirements, hardware courses, App. Domains, and upper level SE courses can count as CS electives). However, next quarter is pretty much the point of no return (or at least the point at which each quarter towards SE doesn't count towards CS).

Anyways, SE is much more focused than CS. In SE, about the only electives (other than Liberal Arts) outside of SE courses are the app. domains. As an SE I would take either Games Programming (CG-1, Games1, Games2) or Graphics Programming (CG-1, CG-Image-Synthesis, CG-Animation-Algorithms) as my app. domain. As a CS, I can do both Games Prog. as my non-CS and Graphics Prog. as CS electives. Additionally, I want to look into AI a bit (at the least I will take Intro. to AI and AI for Games; if I like them enough, then I will take more).

2/8/2003:
Finally Path Blocking: I spent pretty much all of Friday (2/7) working on stuff for other courses, and occasionally talking about the project with Mike and Joe (and trying to encourage them to do certain things). My entire Saturday (2/8) I spent on the project, specifically on trying to get tile path blocking. I tried 3 different general ways to do the path blocking, and eventually settled on doing the third one.

The first was to use a 16 color texture of size 3 tiles by 3 tiles. It would be translated along with the map, and color tested at certain pixels to find out onto which tile the player was trying to move. Also, with this first way, I wanted to do crazy things like have totally pixel-based movement. The blocked pixels for a tile would be graphically set using a 2 color copy of the tile (black being block and white being passable).

The second thing I tried was to use the four lines surrounding the center tile to determine where the character is. This included calculations like UpperRightLine = Height/Width*X + Height/2.

Finally, the third way that I stuck with was rectangle-based collision detection. The basic idea is that if the player's sprite's rectangle intersects with a blocked tile, then the move is illegal. After having this very close to done, I spent about over 3 hours on one bug. When the collision was detected, the player got stuck! But after messing around with it, I finally fixed it! The final problem was basically that I was checking for collisions in the opposite direction. This is because to check for collisions, you move the Player in the opposite direction that you move the map if it is a successful move! Anyways, I like this third way better than the other two because it can be reused for non-tile-based blocking (such as with tree layers or even moving monsters).

Mike Did Stuff: Meanwhile, Mike did two significant things Friday in addition to a little code clean up. He added the code to fill empty tiles (on the edges of the world) with water. He also started on the Monster class, mostly based on my Player class. Monsters are loaded in the tile map. And they have an aggro radius! Right now that means that when the player comes close enough, they warp to one spot on the screen and stay there. Mike was on his CG-2 project Saturday (2/8) (with an hour of trying to help me debug before he went to bed). But tomorrow he plans to get up early and try to get us some decent path-finding before submission #3.

Joe Did Stuff: Joe fixed the font engine. (Yeah Joe! (finally)). And meanwhile he's been talking about putting in layers (like trees). And he keeps mentioning this "Z-buffering system" he has planned. I keep telling him he's crazy and that I think just need to have organized objects with the layers in them, and display them in the right order. (Tiles, then player & monsters, then layers). Though it seems that is basically what he means. Anyways, Joe's been assigned to make some sort of text output window (using the bitmap Font Engine). Joe says he should be able to upload something for me to look at before I get some sleep. I'm a bit excited to finally see it.

Graphics?: So I'm so super-cool for having 32 directional movement, except that we can't really find any graphics for it. Except Joe wants to throw in some Star Craft and/or Diablo2 graphics, since these have 32 directions. I spent a good bit of time looking for unique 32 directional stuff on the web, and found pretty much nothing. So it seems we may just have to use some of those as placeholders, since we're not sprite artists!

2/6/2003:
Awesome Mouse Movement: Using mostly vector math, I wrote the code to move the tilemap (looks like Player is moving) at equal speed towards any direction specified by mouse clicks. Double precision is used, and the only rounding is done in when truncating the display of pixels. (For example, one could move 10.7 pixels and the display would look like 10 pixels. Then move 2.5 more pixels, and the display would like truncate(10.7 + 2.5) = 13 pixels). I was quite excited when I finally got this working!

But alas, there was much more! Since sprites are being used (and not rotate-able 3d character models) I wanted to display animation in a certain number of directions. The direction displayed is based on the angle of the current movement. I decided to display 32 directions based on 17 directions . Well, I was only able to get numbers from arctan in range of -90 to 90 both above and below the x axis. (And I didn't realize it was doing this at first!).

Hours later, I finally got all the specifics of this working! The result is movement (though there's nothing to path-find around yet) that seems to act just like Diablo2 movement (movement in any direction with directional animations for 32 directions). Though Diablo2's actual graphics are a lot better and more complicated - right now my graphics consist of fairly ugly picks of numbers that flicker (instead of walk). Oh yea - and I put in keyboard movement that moves at the same speed :-), though of course in only 8 directions. Then again, I might do something weird like use the numpad for 8 directions that can be averaged, thus allowing 16 directions of keyboard movement. And I've already thought of how to do that :-)

Coolness of Game Artist Co-Project: On a relevant note, I could definitely see coolness in a class project in which each game programming team had a game artist team from a different class (I believe Phelps mentioned the idea at some point). Something like this was done in Software Verification and Validation. Basically, one class (Info. Sys. Design) had a major team project of creating some specific database system, and the other course (Software Verification and Validation) had the major team project of testing it and reporting to the development team. Wouldn't it be cool to have a programming team making a game, and a team of game artists making the art?

Yes - it very much would be. If it were this project, the programming team (possibly with advice from the artists) would devise/design what type of art is necessary (in steps) and ask the artists to produce it. The programmers could work with fake art (like I'm using now), and ask artists for certain types of graphics. For example: players, monsters, tiles, world layers, items, character screen graphics, loading screen... and if there's time in a quarter, maybe even extra fun stuff character concept art that could be included in some sort of instruction manual.

Of course this would really require some grand form of coordination between Phelps (or if Phelps gets a co-game dude faculty member...) and some art department (Graphic Design?). And if it does, hopefully it won't be too late for me to take advantage of it :-( . . . My current plan is to get from RIT a CS BS (Spring 2005) with a Computer Games non-CS and a CS MS (Spring 2006) focusing in computer graphics. After that, I'm pretty unsure about what to do (though I do I have more immediate problems like keeping a decent GPA and finding my co-ops). I'd like to find some sort of good games (or at least graphics programming) program to continue in before going straight into industry.

Teammates: Mike says he added auto-filling water around the of our world (which will at some point be impassable). Mike is also supposed to be finally implementing the impassable. And Joe says he's working on "proper font engine" and "creating quasi z-buffer set of objects ability and have them created". I also posted something on First Class for them to read (last night), which included two things. One, mention that they've both been slacking and that it's not like they have a right to (I did a little more than Mike and a lot more than Joe pre-midterm). Two was basically a list of things that need to be done by Monday, and who is supposed to be working on what now. I plan to chat with them about the specifics tonight.

2/4/2003:
Bresenham: I spent a couple hours trying to convert my CG-1 Bresenham midpoint line-drawing program into something that would get the player to walk straight pixel-wise in oddly-curved diagonals. This turned out to be far less trivial than I expected. The way I currently move with the mouse includes continuous polling of the mouse. So it doesn't really go from start to end; it just keeps doing start to start+1 repeatedly.

Good Old Diablo2: So I decided to take a break from that, and try something else! But first I reinstalled Diablo2, made a Barbarian, and and walked around for about 10 minutes. I was hoping i would see something bootlegged like actual movement in only 16 directions. After a good bit of testing, I am now sure that Diablo2 continual mouse movement is done in at least 32 directions (though the character only faces 16), if it more! (Though it's hard to tell if there are more than 32 directions, which could mean something like Bresenham's used correctly, or just 64 directions).

2am Insanity: So I wrote a little program to calculate low error integer values (pixels as integers) that could be used as x and y vectors for 32 directions of motion (sin and cos of 45, 22.5, and 11.25) x and y vectors would give low error and output it. Unfortunately, this took me a couple hours too (I had to look stuff up for using C "printf" and "math.h"). By the end of it, I realized I'd gone insane, and that moving 867 pixels is no a good whether it's done once per 1/60 seconds or once per 2 seconds. So I tried made it 16 degrees of motion. The only decent result was:

37 = x, 26.162951 = x*cos(45), 26.162951 = x*sin(45), 34.183543 = x*cos(22.5), 14.159287 = x*sin(22.5)

At 37, error less than 0.19
Thus:

37 for ortho
26 for 45 degrees yields a % error of 0.6283
34 and 14 for 22.5 degrees yields a % error of 0.6283

What was I doing this for again? Oh yea.. something about spending hours to implement unnecessarily complicated basic mouse movement, before any path-finding. Hmmm... now that I think about it... 37 pixels could be done at like would be like way too fast. And if I make the movement update less than once per 1/REFRESH_RATE, then it's probably going to get choppy. But man, 7*cos(22.5) is like 6.46, which means almost 1/2 a pixel of error per 6 or 7 pixel moves - D'oh!

I suddenly realize that the hard part of what I'm trying to do is the continual motion using small integer values. And that an easier and better solution would probably be to not use integers to store the overall change in pixels. Instead, I can use doubles and allow the player to move fractions of a pixel! (And round or truncate the current display by one pixel).

2/3/2003:
Improved Character Movement: I redid and improved the basics of the player movement. The player now moves now move the same speed with mouse or keyboard input (mouse input simply overrides any keyboard input). They also move the same speed diagonally and horizontally. (Technically this depends on the specified and is currently set to about 5 vs. 4.95 (from integer vector 7,7) diagonal. And I noticed that even closer values could be 12 and 12.0208 (from integer vector 17,17) - these may be used for running). I am still a good bit away from having decent path-finding though. And I also have to get Mike and Joe to do some work soon (wish they'd find more things to do themselves without me having to persuade them (and generally decide/assign them things to do).

2/1/2003:
Simple Mouse-based Character Movement: I've implemented pixel-based mouse movement. Part of doing this was to derived a simple geometry-based formula to set the distance between the center of screen (where character stands) and the mouse click. A distance is set when the mouse is clicked. Then, each frame update, the character moves a pixel in the direction, while pretending to walk. Currently, the character moves horizontal 1st, then vertical (instead of diagonal).

I also worked on some other less significant things, such as adding the code to show a custom mouse (I put the mouse surface in our Direct Input Keyboard&Mouse Object). Another nifty cool thing I did with the mouse movement was encapsulate it in a "Visitor" type object. I did this based on the "Visitor" design pattern found in "Design Patterns: Elements of Reusable Object-Oriented Software" (by Gamma, Helm, Johnson, Vlissides). (This was my course book for Engineering of Software Subsystems).

Mike & Joe: Joe updated his sound class (though not by a lot). It loads sounds into a map (with string keys), and can play a sound given it's string key once or in a loop. Thus, the program now plays music in a loop and can also play a sound (when you press "s"). Mike's been obsessing with his CG-2 ray tracer - <sigh>.

CG-1 Proj-3: On a related note, my other big project right now is my Computer Graphics 1 project-3 (simple animations in 3D). I have this dude that walks around and pretends to pour cups of tea. Meanwhile, the user can translate and rotate the camera. Currently, sidestepping and forward/backward camera movement are cool. But turning is much less cool! Skimming our primary text ("Zen of Direct3D Game Programming" by Walsh), I realized that the camera should translate in a vector relative to the direction being faced! (duh - simple yet ingenious) Bet I'll see this sort of thing again in Games Programming 3D :-)

1/26/2003:
Post-Midterm: I've done a good amount of the RPG_Rules engine code. This includes adding things like Item, EquipableItem, Character. This included some nifty operator overloading (such as making a "operator-=" on a data class apply to all it's data). However, I ran into a very annoying problem with mutual dependencies (class A has #include B has #include C has #include A type of thing). I messed around with this particular problem for a while, but haven't fixed it quite yet (Ahh - very annoying!).

Anyways, I did a good deal more than my share of the graphics engine code for the midterm, so it's more than fair for me to work on RPG_Rules (instead of the graphics engine and path-finding) these past few days. Meanwhile, Mike and Joe should have done something related to the path-finding or at least mouse movement. (Though I doubt they have... Mike has been obsessed with some ray tracing "Computer Graphics 2" stuff; he's probably getting all weird and fidgity/twitchy/[mumbling-incoherently-to-himself] about it now as he seems to do at times... and I haven't heard from Joe in a few days). Well I'll see them at our meeting time tomorrow. I expect we may at least have time to fix our bitmap font engine.

1/20/2003:
Midterm Submission: Midterm submission today! We have definitely met and gone beyond the requirements:-).

1/18/2003:
Player Loading Graphics File Parts: From a 1stlcass post to my 2 partners:

At first, I thought making a Player class to load portions of a single graphics file into various
textures and sprites for the character animation would build on our existing stuff
in a pretty straight-forward manner. 6 hours later... (really... it took me like all day
to push through some of the crazy freaking quirks!)...

I have added a Player folder with Player.h, Player.cpp, and Images of the player.
It loads the images and sets their translation to the center of the screen - Wohoo!
But no animations just yet (though as I have it set up, that will not be difficult to add).

Yea... Project is due Monday, and we have had the minimum attained like a week ago. (Thanks mostly to me... and Mike did some good fixing of my bugs). I've been adding
extras; Joe added the sound and improved some of our uglier graphics; Mike's been improving the tile map more (it now allows random textures at load-up within a specific texture type
for the water)). So now I've been extra features (and preparing the submission with better directions/documentation). Much coolness.

1/17/2003:
Progress! (tile map, sound, graphics, and character screen): Well, there's been some good progress in the last couple days. Mike did good stuff in taking overtilemap - he fixed the errors and got the tilemap working very nicely - it let's you startup in a specified area (currently specified in the constructor) and loads tiles from the map in all 4 directions! And Joe wrote Direct Sound wrapper to play a sound when you press 's'; Joe also improved our graphics some.

Meanwhile (after mostly handing over a near functional tile map to Mike), I've added a character screen (in it's very early stages at this point). Press 'c' and the map starts drawing, and a character screen background is loaded (and game input is turned off). Press 'g' and you return to the game (and game input is turned back on)- what fun! Eventually this character screen will use knew bitmap fonts to output RPG information (stats, HP, exp, resistances, character name, etc).

1/15/2003:
Mike takes over my Tile Map; I find other things to do: Today was the last class before the project 1/2-way point. After writing and rewriting the texture map file, I had the texture map almost done (scrolling in the view window and copying and displacing the isometric tiles correctly in the array and in pixels). There were a couple small quirks, and the left/right tile scrolling algorithms had to be changed a little for the up/down scrolling. Mike, however, was rather enthused about the whole tilemap thing, and had been talking to me a lot about it the night before.

On the previous night, he agreed to do other things (code clean-up and improving the Direct Input wrapper classes) and let me continue working on it. However, today's class was focused on the tile maps, and Mike & I spoke about tile algorithms. So at this point, I was almost done with it, but getting some headaches, and Mike was aching to do tile stuff. So I let him take over fixing and implementing what's left of it. I have other game things I plan to work on (probably character animations, RPG game rules, windows start-up options, or an RPG stats/equipment display screen... I expect to have at least one of these reasonably implemented by Monday's due date).

Joe Commits to Some Stuff: Also in our meeting after class, I told Joe, "Joe, you need to code something". And Joe happily agreed! Then he decided by the end of the period that he would like to work on Sound/Music (programming and searching) and a text output window (at the bottom of the screen - for RPG messages). We discussed text output window, how it will use the bitmap font engine, and how we could reasonably implement scrolling (with an array or linked list of strings).

I've made a list of some good things I'd like eventually done with the game (maybe not all of them by quarter's end... all of these bonus features done just decently would be totally awesome super cool though). I posted this on 1stclass for Mike and Joe: todo.txt

1/13/2003:
Map Changes: I've made some more changes to the map. Firstly, the 5 test textures are no longer loaded for every sprite, but only once per texture! This combined with some other stuff took a surprisingly long amount of time! Another major change I made was the addition of the tile view port. Basically, an array of characters are loaded to represent the world of tiles. A tile view port of this (about the size of the screen - right now a little smaller for testing; later a little bigger) is set, and the textures and translations are copied into sprites.

I still have to write the function to move the tile view window (and fill the sides when it moves far enough). I have a "battle plan"/"psuedo-code" for this. But right now it's very late, and I'd like to take a nap before my first morning class :-)

RPG Design?: On a quick side note... this map stuff has been keeping me too busy to do anything with the game (RPG-style) rules in a while! I hope I will have time to do a good amount of that stuff, and still have time to add a good amount of stuff to the DirectX-based parts of the game (plus other stuff: textures, sound, program design/documentation, etc).

1/12/2003:
Map Fixes: After I wrote map thingy, Mike added a set view window method, put the keyboard input in to test scrolling, and attempted some debugging. I then finished this debugging and fixed the view window method. I also made some fixes to the earlier map loading function (the fixes were mostly to address the following problems: some incorrect map loading, some hard to read code, and a crash during program termination). Joe is still hanging out somewhere... hopefully he can get busy on something good for our project very soon!

1/10/2003:
Map Loader: I have added to the project both a Sprite wrapper class (from the Zen book), and a map loader. The DX Sprite class (despite all it's glory) annoyed me b/c it scaled my 32x32 sprites before it rotated them - this is the opposite of what I wanted! So I manually turned the tile images all into 64x32 images with transparent backgrounds . I may leave it this way, since despite the extra memory cost it's probably faster to load a larger image than to rotate and scale a smaller one. (Plus it's easier to tell what an image is going to look like when loaded).

1/09/2003:
Working on the Map Loader: Yesterday we had class and agreed that our first goal should be to get a map that will load a text file and display simple tile sprites based on it. I've been working on that for many hours since then. I talked a little with Mike, and he decided he should do some game studying (playing warcraft3). I don't think Joe's up to anything either (sleeping probably). But I guess looking at the current output of what I've been working on, it would seem I've done negative work (somehow I broke the bitmap font engine). I'm at least meanwhile cleaning up some of code, and I do expect to have made visually detectible progress by the end of the day (more realistically - I hope to have within the next day or two)!

1/08/2003:
Font Clean-up: Also cleaned up some code, including removing the remnants of the GDI fonts (which has been replaced by bitmap fonts). This included the following old GDI font code: old unused functions, state, and stuff that was commented out.

RPG Design Update: Minor balancing updates, mainly to Melee Class Level/Feat Chart and Descriptions. This includes some rebalancing of the classes, adding riposte, switching and tweaking the roles the Monk (more towards doing damaging) and Ninja (more towards being quick), and the melee class skill/stat bonuses.

1/04/2003:
RPG Design Update: I wrote the rules for melee attacks (hitting chances and damage based on stats) in Combat Equations. This psuedo-code is very close to what the actual code will be. The general rules are based on intuition and traditional RPG rules (including influences such as Wizardry, D&D, Final Fantasy, and Diablo2). The specifics are based on balancing numbers (skills, stats, resistances, etc), charts (such as in - Melee Class Level/Feat Chart and Descriptions), equations, etc for the specific multi-classing skill system that I have created.

Creating and balancing the melee class chart focus of the game balancing. This involved inventing skills and giving the different classes equally useful but appropriately different abilities at points in the level progression that allow for good various class combinations. The (then not yet written) equations were considered during this process. Combat equations were mostly thought of during this period of balancing the melee class feats chart. These preliminary equations were modified and caused rebalancing due to many considerations. For example: making strength and dexterity do similarly useful but different things.

Balancing Example: For a slightly more complex balancing example, consider my equation for the probability of Evading an attack: ( ((Melee + (Weapon or Unarmed))*dexterity*0.02 ) - (Defense*agility*0.02). This equation will typically give a number around the range of 0 to 100. This is in part done by keeping the max range of melee, weapon/unarmed, and defense (with Defense typically significantly less than Melee + (Weapon or Unarmed) ). Another part would be having the values of dexterity and agility with a minimum value of 20 (-60% in this equation) and allowing them to be raised only so high (a soft max around 75 or +50% in this equation). Another part is adding a hard cap on evasion that does not allow the probability of evasion to exceed 80%. (This is to prevent melee immune or too close to immune situations that could arise (such as a player who goes all out in base Agility, Defense and gets equipment to further raise Agility and Defense)). 80% evade may not sound that high, but it is:

Consider that there are 4 other chances for a character to completely avoid an attack - Dodge, Block, Defend, and Penetrate. If a character has maxed out defend, evade, and penetrate, then the odds of evading a melee attack would be:
20% ^ 3 = (1/5 * 1/5 * 1/5) = 1/125
Raising it further with Block or Dodge could lead to near immunity to melee attacks! From that point of view, 80% probably sounds too high! But high level monsters won't allow the character (who btw will have various forms of level capping) to reach such extreme odds due to high melee and dexterity. Plus, damage spells face different and easier avoidance checks (and debuff spells stick even more often). Finally, successful hits, even if they are rare, can be pretty painful in this game.

And that equation isn't even final - it doesn't have attacker Luck modification added and target Luck modification subtracted! Luck will probably modify pretty much any equation by about 10% or 15% of what the other stats do when they are used as modifiers. But that's another balancing topic! Wow, balancing stuff is such a great way for me to spend hours working on this game without affecting the graphics! But it's Fun Stuff!

Font Engine Working: Also of significant note, Mike successfully debugged the bitmap font engine, so our current version displays frame rates with bitmap characters instead of the slow GDI stuff.

1/02/2003:
RPG Design Update: I have made some updates the Game Design Documents. This includes a new document that specifies many of the specifics of the melee classes. The melee classes are being designed before the caster classes (and their spells), but with some general plans for the casters (such as resistances and INT/WIS stat bonuses) in mind. Depending on time constraints and other priorities, it is possible that the game will be made (as of the end of this quarter) soley with the six melee classes. (The six caster classes may or may not be fully designed and implemented into the game.) But at least some form of the six melee classes (see the link below) almost certainly will:
Melee Class Level/Feat Chart and Descriptions.

12/29/2002:
Winter Break: Well I've tried to do quite a few things this break, but haven't got much working. Firstly I've done some general thinking (and being confused) about how some of the specifics of things are going to work. Also, I've done a good amount of reading. The extra books I bought are good resources in addition to the Zen book (esp. the RPG one so far), including some good material and sample code. However, too much of the sample code in these books is hard to follow, not well-commented, not well documented (even though most of this stuff is given as examples/applications of material discussed in a book!), and organized into gigantic files. And things found on-line are typically worse. I've looked at a good amount of directX / rpg code, and have becoming rather annoyed in general at the lack of decent organization and documentation with such things...

I attempted to integrate the bit-map font engine in the Zen into our current project, but the program crashes. One of the books I have comes with what looks like a great core for the different DirectX components, but I've had trouble even getting it to work by itself right. I've also got a nice character/spell editor from "Programming Roleplaying Games with DirectX" by Jim Adams. This will probably be modified to become usable with characters/monsters and items in our game (At this point having the time to actually implement a decent spell system seems like a pipe dream).

My teammates seem to have decided that our holiday/new year's break is a break. I've tried not to bother/hastle them too much, but tomorrow I plan to try to get them both to at least look at my firstclass posts, including the following message I just posted (with some attachments):

Anyways guys. We haven't taken advantage of this break at all. I was hoping we could get a bit ahead during this break, but it doesn't seem to be happening. I've tried to do some stuff but haven't got much done (been in need of a partner or 2 mb... it seems that my time is generally better spent on my CG-1 proj since it's at least simple/clear what to do...); and you two are like "on break" or something! Well hopefully you can get inspired to fix one of my failed attempts at getting ahead (or at least help me somehow), or do something else! I fear we're missing the chance to take a bite out of the massive amount of work we're likely to end up with in the second 1/2 of the quarter...

12/19/2002:
Well, I had quite a busy past few days. Tests and labs these past few days due (for other courses). Especially Wednesday was quite hectic, since I had three tests, and some minor finishing touches on two programming labs.

And of course our project Assignment #1 was due. There were some minor changes made in the morning (Joe and Mike had added some stuff, and somehow the mouse input I wrote was missing from the latest submission). So I had to fix that problem and organize the stuff to be submitted. Alas, I haven't had a journal entry in a few days (not b/c of doing nothing - rather b/c of being busy).

Over the break I'll be in Cincinnati, OH at my parents house. I won't have my computer, but my parents have a couple P2 computers with pre-Geforce cards. So I plan to do some stuff then (especially some reading).

12/15/2002:
I implemented accessors and delta/change mutators for bunch of data classes. I did this mostly out of habit, but realized that this only achieved the following (over making the data public): made the classes more convoluted, restricted access unnecessarily, and decreased performance (vs. direct access). So, I deleted a couple hours of "monkey work" (copy/pasting and editing for about 45 variables accessors and mutators) and made the variables public. Btw, it was pretty late last night - somewhere around 1am to 4am when I did all that. But at least I have most of the stats memorized after all that, and can better think about balancing them, etc :-).

12/14/2002:
I've implemented a lot of the simple but important foundational classes of the RPG class system. This mostly includes a bunch of data classes with mutators and accessors. However, the work I've done (and am doing) in this area is mostly done on designing and planning what was necessary to be stored for the multi-classing/skill system that will be created. I'm making a big effort for the class system I create to include multiple and different good class combinations. (But also allow very bad class combinations). The player will thus have to make informed decisions on class combinations (which he/she will be able to become educated enough to do in a few minutes of reading certain parts of the instruction manual).

What I've written so far strongly follows Classes2.doc and Char_Mons_Dice.doc. For the first assignment, I plan to have the minimum plus a lot of the (not graphics-oriented but essential to the game) RPG class/skill code written. I plan to write most of the simpler data classes of stats/etc (that I already planned out in Classes2.doc and Char_Mons_Dice.doc) before designing and writing the spell classes.

12/13/2002:
Design Update: Game Design Documents have been updated. Specifically, Char_Mons_Dice.doc (UML diagrams centered around Character, Monster, and DiceRoll classes) and Classes2.doc (a game design document from which the Char_Mons_Dice design was based) have been added.

12/12/2002:
3 Visual Effects I find Impressive in Games:
-Lighting: Good lighting effects in a 3D world can be quite impressive
-Fabric Animations: Having a piece of cloth sway realistically in the wind goes a lot further than only moving pieces of polygons in simpler ways.
-Realistic Creatures: Person/Creature Models that look and to create "real" illusion are another of my favorite things to see in games. This area is still has quite a ways to go in the area of real-time 3D rendering, but is improving.

On Genres: Yesterday Phelps said he's noticed that people are extremely "loyal" to their favorite game genre. I have to admit largely following this prediction. But for me, it's not necessarily directly the genre. It's more about the depth that typically comes in particular genres. RPG and RTS games are typically much more "deep". On the opposite spectrum, "blow stuff up" games such as FPSs do have some potential. (Hexen2 was a great game and so was Unreal single player. Though Unreal's appeal was largely aesthetic). But such games are typically made for apes, little kids, and punks with low IQs who never grew up past high school! (Ok - that was a bit crazy... but I at least entertained myself).

Anyways... I prefer games that make you think, or at least give you something to think about (ie - not necessarily puzzle games)! This can include directly game-play and non-game-play aspects, such as: stories, sweet videos, or various combinations of units (RTS) or classes and skills (RPG). (Btw, I feel quite similarly about movies, books, music, etc).

Depth in our RPG:
This is an area which is turning out to be very controversial between my 2 partners and I. Obviously, we need to be careful about "biting off more than we can chew" in a 10 week period (2 weeks of which have already passed). We plan to keep much of the game pretty simple for an RPG (1 character moving in the center of the screen - Diablo style). But I still want to at least create and add a complex skill/class system for this one character (more complex than that in Diablo). This is going to be a multi-classing system including 6 melee classes, and 6 types of casters. The learning of their skills will overlap in various ways that encourage multi-classing compatible classes, but there will be many viable class combinations. This is one of those games for which reading the manual will be good idea.

Such a game is certainly meant geared towards a particular audience, similar to the audience of games like the Wizardry series or D&D world games. It also adds quite a bit of non-graphics related work. But I hope to convince my two teammates to approve of this if I do the vast majority of the work on the class system design and code.

12/11/2002:
Brief book side note: The first of my books came a couple days ago: "Tricks of the Windows Game Programming Gurus" (by Andrew LaMothe). I've read the first 70 pages straight and I like it so far. It's given me a good general understanding of game structures and the basics of windows programming necessary to make DirectX games. The book is over 1000 pages though. And how much I skim / read by the end of this quarter will be largely dependant on how important it seems to be compared to the other books I have arriving soon.

12/9/2002:
Brief book side note: my books aren't here, but they are at least supposed to be shipping soon. But this isn't including our main book ("Zen") yet. I'm a bit worried about this, but canceling the order and ordering it from somewhere else probably wouldn't be any faster at this point.

Anyways, I've formed my team of 3 today with Mike Lamenzo and Joe Merritt (a CS and an SE). We are planning on making some sort of action RPG (which will probably be similar to Blizzard's "Diablo"). I'm starting to think about the game. The following folder links to documents about the game ideas: SEE MOST RECENT RELEASE!

12/4/2002:
I ordered 6 books last night - the 2 required, and 4 others. In this new section, I list the books I ordered and briefly describe how I spent a couple hours or so picking these 6 books. If anyone's thinking about getting an extra book or two on DirectX games programming, this might be decent advice. The Six Books I Ordered

12/3/2002:
Next I have added a bit about my interest in games. I specify two games to which I was "addicted", discuss what types of game I generally like, and digress on some interesting game-related topics. See for yourself - Intro to my Games Interest