Inheritance

Okay, it seems that I have successfully split up my sprites into their respective individual classes (34 of them at the moment*). It looks like the kinks have, so far, been minimal, so I'm going to work pretty hardcore on adding new sprites for the next couple of weeks. I had been seriously procrastinating on doing this (plus playing Fallout 3--it's very, very good) which is why it's taken so long. The content pipeline stuff was very easy--almost TOO easy, if you ask me--to switch over, and I'm hoping the lack of errors as of yet isn't some sort of elaborate plan on Microsoft's behalf to get my hopes up only to, at some point in the future, bring them down. As I've said, though, and this was the whole point of this exercise, this will make it incredibly easy to add new sprites without hassles. I just have to crank out some seriously amazing programmer art and I'll be good to go. I also need to port the project to XNA 3.0, see how that works out on the XBox, and look at what new stuff 3.0 offers.

My next major undertaking is going to have to be a fancy-schmancy Winforms level editor where you can do really crazy things like, you know, undo. This is some serious technology we're talking about here. I'm not going to start on that for at least a month or two, though, because it wouldn't make much sense to start that before the sprites are all at least somewhat finished. My master plan, at this point, is looking something like this:

1. Make a bunch of sprites.

2. Fancy level editor.

3. Engine enhancements (particles, better collisions, more sounds, et cetera).

Hopefully I'll make the time to work on it.


* The projectiles and powerups still use a shared class (Projectile.cs). This is because I need to convert objects between the different types fairly regularly in the course of a level. So, really, counting the five sprite types (so far) in the Projectile class, it's really 38 types. THE MORE YOU KNOW!

Rainbow power!!

Just wanted to make a quick post--I have been working on Extinctathon, albeit intermittantly. I've just implemented a new power up, the rainbow (invincibility), and I'm working on the animation for the next power up, high fructose corn syrup. Yum!

I've also started the artwork for some underwater and desert levels. I've got the basic plans for adding some particle effects as well, so I'll be working on that this week and next. My main thing for the moment, though, is content creation.

I've got a super short video of the rainbow powers uploaded, so here it is:
Extinctathon - Rainbow Powers!! (720p, 8.4mb download)

DBP is over!

I've stayed away from Extinctathon for the past week or so, taking a break after finishing my Dream-Build-Play submission. I'm getting back to it this week. I'll post a little more later, but for now here's the XBox 360 ccgame (if you can play this, you know what it is). I'll be making a distributable Windows version of the game some time in the future, most likely when it's at least somewhere close to complete (running XNA games on computers without the XNA dev tools installed is kind of tricky--I don't want to go to the hassle at this point).

I've posted a video of a run of the full game, as it stands at this point. It's about three minutes long and shows off the first four levels including a suuuuper scaaary dungeon level with a suuuper sccaaaaararararyyy boss at the end. Check it out! Feedback would be GREATLY appreciated.

Downloads
Extinctathon! DBP build - XBox 360 ccgame
Extinctathon! DBP submission video runthrough (720p 53.3mb download)

Finishing touches (omg j/k lulz)

Okay, so I've spent VERY little time on Extinctathon of late. This, with two weeks left (from today) before the deadline. Ugh.

Here's what I'm going to do before then:

• Eliminate garbage created by ToString() (called several times per call to draw) by storing strings and updating only when necessary.
• Save the background color (or image, maybe) to be used in the binary level files (because one can only take so much Cornflower Blue). Update: DONE!
  
• I really need to finish three more levels. This has been such a difficulty simply because of the lack of building blocks I have at this time. I've made some additions, but it's not nearly enough to make a fully fleshed out game (I'd ideally like to have 80-100 more blocks, 6-8 more powerups, and maybe 10 more enemies before calling it "done"). A large problem with this is very deeply embedded in the stupid way I designed the Sprite class (yes, that's ONE sprite class, used for 30+ types of sprites) that needs a complete overhaul that will absolutely not be done in any small amount of time. I'm just gonna work through with what I've got for now, and restructuring the sprite types to inherit from a base Sprite class (rather than all being instances of the same class differentiated by a SpriteType enum) will have to come further down the line.
• I need to create the boss character for level 1-D. I already know what it is, and aside from creating the artwork it shouldn't be a problem.
• I need to reload and restart the current level upon death. This will be a trivial change. Update: DONE!
  
• I need to make a Game Over screen for when the player's lives are less than zero. Shouldn't be a big problem. Update: DONE!
  
• I need to make a non-debug mode (all I have are DEBUG and EDIT) for DBP. Don't want to see all the diagnostics 'n' shit on the actual submission. Update: causes a weird bug that makes everything but the player invisible. WTF? I tried to fix it for a good 30 minutes last night but have yet to find the problem. Double update: DONE!
  
• Along those lines, I need to disable entering the level editor for the same reason. Update: works, but of course it's dependent on fixing the above mentioned bug. Double secret update: DONE!
  
• I need to move inactive (i.e. dead) sprites out of the current level's sprite list if performance on the XBOX 360 necessitates it.
• I need to fix, once and for all, the intermittent bugs caused by the sound loading and reloading. Update: DONE!
  
• I need to fix the jumping bug that allows the player to jump after falling off of a ledge. Update: DONE!
  
• I need to make the loading screen show the name of the level (and maybe an image preview?) being loaded. Update: Level name is shown, will add picture preview later.
  

And that's all I've got. These things WILL be done by September 21st. I'll be prepping the rest of the submission package on the 22nd, and turning it in no later than 5:00 P.M. on the 23rd. I'd better get my ass in gear.

New music!

There's not much new to this Extinctathon video, really, except the awesome new music done by Asheville, NC's Eugene Ward just for this game. The video's kinda long, but I wanted to get a good couple of minutes of the song in before it ended. Check it out!

You can download the song from his myspace page, by the way, but he changes things pretty regularly so you might want to hurry (if you like it).

Video:
Extinctathon - Music! (720p 34.8mb download)

Extinctathon: Polish?

I spent some time this morning fixing or improving tiny bugs, and trying to get the background music to play throughout the game (rather than being started and restarted at the beginning of every level). That caused some problems, so I'll need to come back to it later. I'm gonna have a lot of time to work on Extinctathon starting tomorrow (several hours per day), so I'd like to get the following things done this week:

• Get the music to play in the way that I want.
• Create at least five new background sprites to make the levels more visually appealing.
• Create at least five new block and enemy types which are necessary to make this more than a one level game.
  
• Make three more levels which will create one more or less cohesive World 1.
• Try adding some particle effects (pixel-y particle effects, of course) to make things more interesting.

The next month is all about content development, as I want to have something that isn't RIDICULOUSLY simple to have to turn in for Dream-Build-Play. Yeah, I know I'm not winning any prizes--that's a given--but it's really important to me to have something half decent to submit.

No video today, but I'll have something to post on Wednesday night (hopefully).

Level transitioning: GREAT SUCCESS!

Hurray! After putting in a fair amount of work yesterday and today, I've gotten the level transitioning to work. Now--shock and awe--when you get to the end of one level, you can move on to the next! WTF!! The future is here!!! (The next level here is exactly the same except with gray bricks instead of red ones, but it is an actual separate file.)

The only thing I really need to do is make the transition prettier (since now all it does is just stop and immediately load the next level). I'll need to flesh this out a little more over the next couple of days, but I'm pretty happy with what I've got going on right now.

I'm gonna spend the bulk of my time in the following week designing some new levels and some new blocks and enemies. I'd like to get a solid four levels together just to mess around with and show off to people. That'd be nice.

On an unrelated note, I finished Braid today and it was absolutely perfect. If you haven't bought it yet, buy it NOW. It'll be the best gaming purchase you could possibly make.

Video:
ExtinctaLevels (720p, 14.4mb download)

Incremental updates ahoy!

Adblock

Okay, so I've been really really busy in the real world in the past several weeks. Unfortunately, I've had little time to work on Extinctathon. I have done some stuff in the past week, though, so here's what I'm working on:

• The levels now have barriers that keep the walking enemies (i.e. everything but the bees at this point in time) bound to a particular region, primarily keeping them from walking off the edges and commiting enemy suicide. These are inserted manually in the level editor, an idea that seemed retarded (in that there must be a smarter way of doing it) until I saw a similar mechanism in a commercial 2D level editor.
• The barriers, along with the previously mentioned checkpoints (see previous post) now turn invisible outside of the level editor. I'm listing this as an additional feature to make it look like I did more work this week so I can feel better about myself.
  
• The major bounding box issues have been fixed, but a smaller problem still remains. Projectiles, as you may recall, are reformed from existing projectile objects which avoids using new (since the XBox 360 is racist against news). The problem was that the bounding box was being semi-manually set after the creation of the object in a spectacularly stupid way, so when the bounding box for the object changed (like when a fireball turns into a bible, which is bigger), it wasn't getting updated in the code. At first I tried to work around this by referencing the data from the sprite sheet, which does have the bounding box information for every sprite in the game, but that was REALLY slow. At the moment, it's copying the box from the sprite sheet at object creation/reformation time, which is doable (since the sprite sheet should never be changed, this should be okay).
• And, finally, aside from the necessary addition of an end, which I'll get back to in the next section of this post, I'm done with the basic construction of the first level of the game. I'm happy with it, and I'm sure I'll tweak it, but I want to have something roughly set in stone so I can look beyond it on to other things.

What's next? A lot.

• The biggest thing--and I mentioned this in my last post as well--is level transitioning. When the player crosses the final checkpoint of the level, a little animation needs to happen, perhaps a summary or a ghetto cutscene, and then we need to move on to the next level. This is going to be tricky, and I am going to have it done by this time next week. It will be done. Seriously. I have to do it. So that's what I'll do.
• I need a couple of tweaks to the powerup system, including the ability to set what type of powerups come out of the box inside the level editor. At the moment I'm just procedurally saying "the box has been hit, pop out a fireball!". Along these lines I need to make the brick blocks breakable and give them similar behaviors to the questionmark blocks.
• A whole bunch more, which I'll maybe get in to in a bit.

As always (at least usually), here's the video:
Extinctathon: Barriers, checkpoints, and bug fixes (720p 10.1mb download, recommended)
The same video (YouTube)

Checkpoints, boxes, and bug fixes

I haven't had any time to work on Extinctathon during the week, but I've had a good two hours to work on it this morning. Things I've taken care of today:

• Began implementing a basic checkpoint system. When the player crosses the checkpoint, he gets 1000 points and will respawn at the checkpoint if he later dies. This can easily be extended to level endpoints as well, which are a part of the next big goal which is transitioning from level to level.
• Began work on boxes that pop out powerups. Right now the question mark boxes are popping out fireball powerups, and there's a few issues regarding the bounding boxes that need to be taken care of. I need to make it so that different types of items can come out of the question mark boxes and I need to be able to set this in both the design stage and in game (depending on the circumstances).
• Fixed one of the audio bugs that was causing crashes when exiting and restarting a level. I wasn't disposing of the background music cue, so in certain circumstances this would cause a memory management issue which would crash the program.
• And, finally, a couple of smaller bug fixes. Scores no longer pop up over enemies who suicided (i.e. fell off the screen) and the snakeocat no longer rapidly flips back and forth when the player is directly above him.

What's next:

• I need to work some more on the way that blocks can pop out powerups, how this behaves, and how it is handled.
• I need to fix an issue with the bounding boxes of the sprites. When the sprites are reformed (this happens to all projectiles), there is an issue that is causing the old bounding box to be retained. This causes a couple of collision problems which need to be fixed.
• I need to make at least four solid levels. Once I have that, I think, I'll have a good five minutes of gameplay that I can use over and over to work on fixing bugs and polishing the game.

I don't have any vids at the moment, but I might post some later tonight after I've had more time to work.

Game State Management: Progress!

Due to some stuff in the real world, I haven't had a lot of time to work on Extinctathon in the past week. Still, I had a chunk of time this morning, and I started making headway with implementing the Game State Management Sample without (completely) breaking the game. What actually happened was I started doing that, got fed up, tried to roll my own solution, realized I needed everything the GSM Sample did, but my version would be kind of crappy, so I started over using the sample.

So, yeah. Lots of back and forth. I got Extinctathon to work with the menus, pausing, stuff like that, with a few BIG issues.

1. The collision detection is broken. It was dependent, before, on the input handling, collision, and updating to be done in a specific order. This had to be moved around to accomodate the new changes, and it no longer works in certain situations. This should show you how shitty my collision stuff is. It need to be completely reworked.
2. Some minor stuff with the music. This should be easily fixed.
3. There's a weird bug when you exit out of the game to the main menu and then start a new game. The program crashes and throws an error I haven't seen in C# before. I'll mess with it later.

Video later on.

UPDATE:
The collision detection has been mostly fixed. It's better, with a couple of exceptions, than it was before the game state management was implemented. The main bug that's left is that, when pressing up against a stack of blocks and falling, the player can get snagged on the corners of the blocks which prevents him from falling. I'll take a look at this over the coming days. I'm kind of tired of working on this at the moment, so I'll take care of that later.

The audio bugs remain, but I know what's causing them and they should be trivial to fix. Hopefully.

Video:
Extinctathon: Game state management and one more collision bug (720p, 9.8mb download)
Youtube

Pills, balls, and bibles

I've added a couple of power ups to Extinctathon, cancerballs and bibles. The cancerballs (I should probably come up with a different name for that) shoot out in a straight line, although I might make them bounce like fireballs in Super Mario Bros. The bibles go up in an arc and cut a swath of heavenly destruction through thine enemies (unlike the balls, which are destroyed when they hit an enemy). There's a fair amount of tweaking to be done, but I'm happy with how the power ups have gone so far.

Since the XBox 360 hates in-game object creation, the player's sprite has a pool of five projectile sprites (five being arbitrarily chosen, adding or subtracting from this is as simple as changing a number one time in the code--it feels like a good number, though) from the time of its creation. The sprites are all "dead", so to speak (i.e. this.state == SpriteState.Dead), so they aren't updated or drawn. When the player hits the B button, it cycles through, finds the first dead sprite, and reforms it into the appropriate projectile. If all the projectiles are active, as in there are five bibles being thrown around, no new projectiles will be created. When the projectiles have died (after a couple seconds), new ones can be created. Simply, the player can shoot out up to five of a projectile at any given time.

I also added some pills, which are basically like coins, rings, or any of the other pointless(ly fun) collectible items from every platformer ever. Each pills gets 100 points, and 100 pills get you a brand new life.

The main thing now is to get the blocks to pop out the power ups (I'm manually spawning them with the level creator at the moment, as you can see in the video). I'd also like to make the brick blocks breakable, and make some brick blocks that pop out power ups, pills, 1-ups, stuff like that.

From here on out, I have a couple of big changes remaining:

• GAME STATE MANAGEMENT! I keep putting this off
• serious improvements to the collision detection
• an improved level editor
• hardcore optimization for the XBox 360

Everything else that's left to do is basically going to be content creation and a whole lot of polish. I need to add a lot of power ups, a bunch more enemies, more block times, more sound effects, more levels. After all that's underway I'd like to start implementing some visual effects, and even possibly some as-yet not fully fleshed out new game mechanics that will appear in the course of the game. The idea here is that you start out playing something very familiar (the first level being almost identical to the opening of Super Mario Bros.) and by the end it's almost unrecognizable. I realize this is a lofty goal, one that I can't guarantee I'll achieve. Nevertheless, I'm feeling really good about where I'm at with this game so far, and I'm feeling VERY good with the level of extensibility I have set up within the game's code to add on ideas in the future. It's certainly not bad for a first time XNA project. I'll post more as the week progresses.

Video:
Extinctathon: Pills, balls, and bibles (720p 19.1mb download)

Audio, some refinements, and this week's to-do list

I've spent the past week messing around with the sort and sweep algorithm some more. The main problem, in my case, is that I need to do a good bit of reading on the IComparer class, because I really don't understand it. As it is, if there are multiple objects with the same X coordinates, it isn't necessarily including them all in the appropriate lists of interfering objects. Take, for example, the picture at the top. If we're checking interference with the rabbey (the little brown rabbit monkey thing standing on the question mark block), we look at everything in between his leftmost and rightmost points. In this case, two grass blocks, a mountain, and a question mark box. That'll work, and that's all fine.

If, however, the rabbey is on a stack of ten boxes, all of which have the same position along the X axis, and the rabbey happens to be at exactly the left- or right-most point of said stack of boxes, some funky things start to happen. This is because when we're sorting the list, we SHOULD be putting the rabbey's left coordinates at the beginning of any string of identical coordinates, and the right ones should go at the end of any string of coordinates identical to those. In other words, the rabbey (in this case) should be the very beginning and the very end of any items who might interfere with it.

In my implementation, however, this isn't the case. the list is sorted, but no particular creedence is given to the order of multiple cases of identical coordinates. My short term fix is to test three or four extra objects to the left and right of the object in question, but this is a stop-gap solution and is probably the worst way to handle it. I'll be researching IComparers in order to find a better way. I shouldn't have to sort the list multiple times per update (as that would be prohibitively expensive, CPU-wise), and I think I can just search for certain values in the list. That should hopefully be kind of easy.

The main additions I've made in the past couple of days have been audio (all music and effects copyright My Awesome Talentedness, 2008). A friend of mine is going to do some music for me, and I'm really looking forward to that. I'll mess around with the sounds a bit as well, but it's not a high priority for me at the moment. At this point the voice acting is no worse than Symphony of the Night, and that was one of the best games ever made.

I've also done some minor tweaks here and there, mainly standardizing the blocks' sizes (so they'll all match up, duh), and tweaking a few things in the update cycle (the most noticeable of which being that the enemies don't move unless they're pretty close to being onscreen).

In addition to the aforementioned sort and sweep fixes, I'd like to add some enemies, some block types, and blocks that pop out powerups in the coming week. I also need to add a way to finish a level, load into the next one, stuff like that. Finally, I think it's really time that I implement a game state management system, even if it's hard as hell to do it. I need to be able to pause, have some menus, get a game over, and stuff like that. It won't be fun. But it has to be done. We'll see how it goes.

Videos:
Youtube
High-res download (720p) (recommended)

Sort+sweep detection: FINALLY

Okay, so I'm super happy that I've gotten the sort/sweep implementation more or less working for my collision detection. It took me a good long while, but it's working now, and the performance increase is noticeable.

My previous collision detection did the following:
Make a list of everything.
Go through each item on the list.
Test it for collisions with everything.

It's very easy to do and very inefficient. The new algorithm does the following:
Make a list of everything.
Make a new list of the beginning and ending positions on the X axis of each item and sort this list by these X positions.
Go through each item on the list.
Test it for collisions with any objects whose X position is between the start and end positions of this object in the second list.

That's a poor way of putting it. Here's a much better explanation. It even has pictures.

So anyway, it turns a really simple but time consuming problem into a somewhat complicated but much faster problem. I still haven't addressed the major issue for XBox, the mid-game creation of objects, and that will be one of my next major goals. Nevertheless, on my laptop it can go up to 1024 sprites (the most I'm supported at the current time) with virtually no hits to the performance. The video posted is a good deal slower due to the screenshot software.

Also, I don't think I've posted a video since I've made a few changes to the interface. I changed the screen size to 720p, so it's a big taller and a lot longer. I've moved things around a little to account for overscan on my HDTV. Finally, I've made the lives and the score displays a good deal bigger. I think it looks pretty.

Video: Extincathon sort sweep collision detection

Extinctathon: the long road ahead

I've spent the last week preparing my code for broadphase collision detection using a sweep and prune algorithm. I'm working on the actual sweep and prune process now, but getting it to work at a reasonable speed on the XBox seems like it's going to be an uphill battle. I'll be working on it for at least another week, and hopefully by that point I won't have decided to give up and focus solely on the PC.

I read an excellent article by John Wells on the topic of broadphase collision detection particularly geared towards optimizations for the XBox 360 (bit of a refresher: my game currently uses the most naive collision detection algorithm in the universe, checking every object with every other object, i.e. a O(n²) algorithm which absolutely breaks down on the 360 after five or six enemies are present). The two main goals are elimination of cases, i.e. testing the fewest possible number of collisions by implementing some rather simple logic, and the avoidance of garbage. The XBox 360 hates garbage. When you create heap-based objects, it spits in your face. It slows to a crawl. It writes goth poetry. It doesn't like new objects.

The first issue, the elimination of unneccessary cases, is easy enough to do. I'm still working on it, but I can finish it in a day or two. The second part, however, is far more complicated (to me) because it involves lots of C# functions (and even syntax) that I've never before seen. I need to learn how to do it, but it's rather complicated. I'll have to work on it later.

I'll post some more of the details a bit later when I have more time.

Extinctathon: enemy types and collision bugs

Now that the level loading is about halfway where I want it to be (it's independently loading lists of Blocks and Species), I need to do some serious work on the collision detection algorithms. I'll go into more detail in future posts, but here are the basic problems.

• I need to implement per-pixel collision detection. This is most noticeablely an issue with the Snakeocat at the end, which, by virtue of the size of its bounding box, floats in the air a good deal more than the other enemies
  
• I need to do a much better job of processing collisions with enemies once they occur. The player dies in a handful of situations where he shouldn't. Right now, the player dies if he collides with the bottom 3/4 of the enemy. If the player is falling too fast, or the enemy is rising too fast, even when the player hits the enemy from above he dies. What needs to be done is to extract the player from the enemy and then determine if the player was on top, to the side, or underneath.
• Similar fixes need to be done with regards to collisions with blocks. There is a rare bug when the player is between two blocks spaced exactly the width of the player apart that can cause some unusual behavior.
  
• I need to optimize the hell out of it. I deployed to my XBox for the first time this weekend, and anything more than 6 enemies on screen KILLS the performance. We're talking 1 or 2 frames per second. My basic algorithm is as naive as it gets (literally everything is tested with everything, an O(n^2) algorithm), and I need to fix it as soon as possible. It does fine with a couple hundred enemies on my computer, but, of course, that's a lot faster (with certain kinds of operations).
• In addition to optimizing the broad phase of the collision detection, i.e. deciding what should be tested against what, I need to do some serious optimizations on the collision detection itself. I have not yet decided how best to handle this.
• And, finally, I need to make it so that when enemies die by falling off the screen they don't give you points.

That's it for now. I was kind of lazy today and ended up just making a new enemy (the af0rementioned Snakeocat). I'll get to work on the serious stuff tomorrow.

Extinctathon: tiny updatelet

The whole Species content pipeline thing is done (enemy loading and saving, in lay speak), and now I'm going to be updating the Block class to make it more extensible and more geared towards classification via a BlockType enumeration, a method which I've found incredibly helpful with the Species class. I'd like to have more done at this point, but I just picked up Ninja Gaiden II -and- Lost Odyssey, AND I'm at work two days more than what's normal this week. Hopefully I'll catch up on Sunday.

In other, non-Extinctathon news, a friend has passed along some very sciencey Fortran code that models the flight of a frisbee given some initial conditions. Somewhere along the line I'll be turning this into an XNA frisbee simulator, but I really want to keep working at Extinctathon for the time being.

Extinctathon! Current short-term goals

I've got some time today and hopefully more during the week, so I've got a couple of big goals to work towards. The main one is to get the level loading and saving working (level meaning the list of blocks, list of enemies, start point, end point, and a few other bits of info). I was having some trouble, conceptually, with this, but Shawn Hargreaves came to my rescue and explained what all I needed to do. Before I do this, however, I need to make a big change.

Yes, you guessed it....SPRITE SHEETS.

Right now I'm loading 20 different textures and switching between them multiple times per call to Draw(). This is very GPU intensive, so I've heard, and it's much better to load them all into a single image and then draw specific portions of that image onto the screen. The reason I have to do this BEFORE I do the level saving and loading mechanism is that it will replace the lists of sprites that make up the animations of the various characters with lists of rectangles describing where these sprites can be found on the master sheet. This will be a pretty big overhaul, and I forsee spending my whole day (well, up until noon) working on it. Fun.

UPDATE:
I have the sprite sheets working, using the incredibly helpful projects here. I spent most of the morning just adjusting all the draw and bounds-checking calls to work with the new system. I'd say I'm about 20% done with the Level content pipeline system. It's going to take a good deal of work, but I think I can do it. Once that is done, I can work on making a few more enemies, Block types, and a system for implementing power-ups. Once that is done, I can get to work on some serious level editing--after a few much-needed improvements to the level editor, that is. And I still need to get the menus working, either by adapting the examples found here or by rolling my own in some fashion that won't make the code completely unreadable. Either way that seems like a big ordeal.

Extinctathon: new enemies, code maintenance

Not much to say, but I have added a new enemy (bees!) to the game. It's pretty easy to add them, really the only hard part is deciding what they look like and how they behave.

My project for the day is to replace all my C++ and Java-esque accessor methods with the more idiomatically correct C# style get/set methods.

Once again, boring stuff, but stuff that needs to be done. Another thing that needs to be done, seriously, is using sprite sheets instead of using a separate texture for every single frame of every sprite's animation. Switching textures, apparently, is incredibly GPU intensive, so it's better to put groups of sprites into single textures and then drawing portions of the larger textures onto the screen.

UPDATE:
I've finished updating the code using the get/set property style. I moved stuff around to match with the style I've seen in most of Microsoft's projects. I even took a look at the menu and game screen system examples on the XNA site, but it's too much for me to deal with right now.

Source:
Extinctathon (entire project, zipped)

Extinctathon: Enemies and Dying

I've been working pretty hard on Exctinctathon, and I've started adding an enemy and dying. Right now, there's just one enemy (the purple blob), and he just walks back and forth in a sinusoidal path. If you hit him from the top, you kill him; otherwise, he kills you. Fun!!

I started out with an Enemy class that inherited Species, and while that was fun (if only because I got to type "public Enemy" a lot), I'm having better luck with making the on-screen enemies Species objects just like the player is. I might go back and change this again later, but I really need to read up on things like inheritance in C#. I think it's pretty obvious if you look at the code that I'm working with some sort of fundamental misunderstanding when it comes to that.

I still need to add other types of enemies, each with their own set of behaviors, and the ability to save the list of enemies with the list of blocks in the level editing system (right now the enemies are just hard-coded into the level). I need to see how to save multiple object types in an XML file. Shouldn't be TOO difficult.

Current short-term goals for this project:
1. Include enemies in the level saving and loading procedures (this is by far the most important).
2. Add a menu system and pausing.
3. Add some sounds and music to spice things up.
4. Add new enemy types as well as new blocks.
5. Clean up and document the code.

I think that's reasonable for now. I'll post again in a couple of days and we'll see how far I've gotten.

Project Files:
Extinctathon Project Snapshot, 05/30/2008

Video:
"Extinctathon: death and enemies"

EDIT:
I've added the ability to add enemies in the level editor. The list of blocks that was being used to add to the level has now been made into a generic list of objects which contains both Block and Species objects. WARNING! Very exciting video ahead. Here it is.

I need to come up with some better ideas for enemies.

Extinctathon: level editor saving and loading complete

Just a post to let anybody who's reading this that I've finished the level saving and loading features and they work quite nicely. The in-game level editor (still a work in progress--it's not very fancy at all) can save all the blocks in the current level as an XML file. I can then add that file to the project, where my Content Pipeline library converts it into a binary XMB file at compile time. My XMB reader then converts said XMB file into objects in memory.

Basically, List<Block> -> XML -> XMB -> List<Block>. Apparently doing it in this way is much faster than the easier way of simply writing to and reading from plain text XML files. When you're saving thousands of blocks, you end up with a good 2 or 3 megs of XML which takes far too long to parse.

I'll post details, code, video, et cetera a little later on.

Also, I should say that writing this took a good deal of work on my part, and once again the XNA tutorials were a HUGE help. However, while in the middle of this, the XNA site was down for about a day preceeding their big relaunch, and this was the first time I just NEEDED other people's help. I ended up getting it on the forums after the relaunch, and it helped me to understand some of the things that weren't clear to me before. In other words, "Thanks, internerds!" Where would we be without you?

Source:
Program.cs, Extinct.cs, Species,cs, Block.cs, BlockReader.cs (rar)
BlockPipelineContent.cs, BlockSettingsWriter.cs (rar)

Extinctathon: Level Editor

I've been working on Extinctathon pretty regularly lately, at least 2-3 hours per day, and I've updated quite a bit. I've got multiple types of background tiles (Block objects), I've updated the collision detection (it works about 95% as well as I want it to), and the beginnings of a level editor (as seen in the video). It's all in one program; you hit up on the d-pad to toggle between editing and debug modes (as seen in the upper right hand corner). In edit mode the shoulder buttons cycle forward and back through the types of tiles (grass, mountain, cloud, block), and the cursor is moved with the left hand joystick. Tiles are placed by pressing A.

I still have quite a bit to work on, including adding blocks that can be broken, blocks that can pop out power-ups, enemies, and all sorts of other stuff. The code needs cleaning up, too, and there's a good amount of commenting that I need to do before I move forward. The next step I'll be taking, however, is adding a level loading and saving system. I'd like to then make one semi-complete level so that I can test it out and then add enemies. I'll hopefully do that this week.

Source:
Extinct.cs
Species.cs
Block.cs

Project 5: Extinctathon!

Extinctathon is my newest project, and boy, is it a doozie (I just wanted to say that). Imagine Bioshock and Super Mario Brothers and Margaret Atwood all rolled up into one--that's Extinctathon.

So far it's a 2D side scroller with a rabbit-monkey hybrid that can walk and jump. It sort of has collision detection in that if you fall on top of something you stay on top of it and if you walk into something you magically appear on top of it because it's not really done yet. It takes input from the XBox 360 controller (just got two this morning) and moves the little guy around onscreen.

It's already big enough to occupy three (3!) source files, and it's only getting bigger. I've only spent 2 or 3 hours on it so far, so it's pretty limited, but I'm looking forward to working on it in the coming weeks.

I'll post more when I have the time.

Project 4: Solvle

Okay, so I'm pretty proud of myself for this one. Using the methods from my previous project, I added the ability to, given a particular arrangement of letters from a game of Boggle, find all the words possible according to the rules of the game.

This is accomplished by the same basic method that a human would use while playing the same game: starting with a letter, move on to the adjacent or diagonal tiles to find any English words. I used the ENABLE word list which is a free text-based Scrabble dictionary in exactly the format I needed.

The first working version of the search took a good 90 seconds on my computer, which seemed way too long for practical use. It was searching literally EVERYTHING, though, even after it would be impossible to find additional words. In other words, if searching on a path yielded "ASDF", which isn't a substring of anything, it would keep on searching all possible subpaths which would all yield nothing. One line of code later, and the search results are visible by the time the mouse button has been lifted up.

It works great, as verified by a few games of Noggin (I'm not a habitual cheater, I just wanted to test it out). The only words I didn't get were verified as not being in my dictionary file. Aside from those, Solvle found every single word on the list in a fraction of a second. Fun.

One thing I did differently this time is I tried to fully document the code as I was doing it. It's a good habit to encourage, so I'll make myself do it even though for most of this stuff I'll be the only person to see it. Still, the code could certainly use some tidying up, and some optimizations here and there. I'll take a look at it later.

With regards to what's coming next, I've been talking with somebody about moving on to Scrabble. That would be WAY more complicated, however, and I might want to do something a little lighter for the moment. My wired Xbox controller should be here soon, so I'll get to work a little more with XNA. I'm looking forward to that.

Source:
Solvl.cs
Solvl.Designer.cs
Solvl.resx

Project Update: Dictofunk

I've updated Dictofunk to add searching to the tree. It's fast enough that it updates in the time between keystrokes while typing a word. I'll post screen shots, details, and the updated source code when I get home.

Second update:
I've gone ahead and made the Boggle Solver program in the past couple of days based on the tree stuff done already. I'll pretty it up a big (both visually and in code) and post it later today.

Project 3: Dictofunk

My newest project had the objective of loading a word list from a text file and converting the words into a tree.

In other words:

act
arc
art

would become

a->c->t
.->r->c
....->t

This is one of those sort of important, school-y types of things that people should learn, and I wanted to do it for the Boggle Solver program (given a Boggle board and a list of valid words, find all possible words within the rules of Boggle) I had talked with somebody about a couple of months ago.

The basic process involved is this:
1. Read a word from a file.
2. Starting out with an empty tree, search the top level of the tree for the first letter in the word.
3a. If you find it, make that spot the top of the new tree.
3b. If you don't, add the letter to the tree, make that letter the top of the new tree.
4. Chop off the first letter of the word and start over at 2 with your new subtree.

Finally, when the word is done, it sticks a "." at the end so it knows it's a complete word (so that you know, for instance, while "act" and "actual" are words, "actu" and "actua" aren't--they won't have a "." in their subtrees).

Here's the same algorithm in C# form:

public void insertWord(TreeNode thisNode, Char[] chars)
{
bool found = false;
String charString = new String(chars);

if (charString.Length > 0)
{
charString = charString.Substring(1);

foreach (TreeNode branch in thisNode.Nodes)
{
if (branch.Text == chars[0].ToString())
{
found = true;
insertWord(branch, charString.ToCharArray());
}
}
if (!found)
{
insertWord(thisNode.Nodes.Add(chars[0].ToString()), charString.ToCharArray());
}
}
}


And that's pretty much that. The actual algorithm is fast (as seen in the screen shot, with the test dictionary of over 70,000 words it was going through about 13,000 words per second). Loading the tree into the Windows Form, however, takes a good 60-90 seconds. That's not a major concern, however, since the graphical display (yet another great thing that C# does that makes life so easy) is essentially pointless except for visually verifying that the algorithm works. I was kind of shocked that this was even included as a basic display type. Oh, the future.

Oh, also, C# in general was a huge help in doing this in that it I didn't have to worry about constructing a tree class of my own. I was able to spend my time actually figuring out the algorithm I needed, which, while I've certainly read about tree insertions before, I did last night and this morning on my own. Once again, this is totally freshman programming class stuff, but it feels good to know I did it more or less on my own.

Source
Dictofunk.cs

Update: Time Sheet Calculator v. 0.2

I recently updated the Time Sheet Calculator program to incorporate a few additions I wanted to have after using it to do the payroll this past week. For the record, it saved me at least 90 minutes of work this week alone, and it will save me about that much time once every two weeks in the future.

I needed to add a button to reset all the fields to 0, and I labeled it "TARE" because I felt like labeling it "TARE". I also fixed the formatting of the total time display so that it displayed it in HH:MM rather than the default format of d.hh:mm. Finally, I changed the format of the individual DateTimePickers to be hh:mm am/pm, because the seconds were unused and leading to too many mistyped numbers. If I think of anything else to add, I'll post it. Right now I'm satisfied.

Source:
TSCv0_2.cs
TSCv0_2.Designer.cs
TSCv0_2.resx

Project 2: Swarm and Gravitate

In this program, I started learning the basic flow of the Windows Forms program. I did some event handling and some graphics, learned some more stuff that C# makes retarded easy (the List container, primarily), and did some really simple math (that took a little too long to figure out--it's been too long since I've taken math. Or physics.)

Swarm() calculates the center position of the collection of bodies and everybody accelerates towards that position. Gravitate() attracts the bodies to one another by (something resembling) gravity. This is all, of course, 2D.

Things I'd like to add:

• Hitting tab to center on a body doesn't properly work. I need to fix that.
• Once that works, I'd like to be able to double click on a position to center on that point.
  
• There is no consequence of collisons--gravity simply turns off when the bodies are about to touch (to keep them both from rocketing off into space).
• It'd be nice to put in a menu to add / delete planetary bodies.
• It'd be nice to put in controls to drive around one of the planets.

If I can think of anything else to add, I'll add it. I'm planning on moving on to a simple game next. Don't think I'm going to mess with DirectX yet, think I'll do something hands-on and 2D before I start messing around with the XNA toolkit.

Here's the source file.

Project 1: Time Sheet Calculator

Okay, so this whole thing started the other day when I got sick of doing payroll. At my workplace, the staff members clock in and clock out with and old-fashioned time card system, once which prints the time on a piece of card stock. Every other Thursday, I have to go through every single card, calculate the shift times in my head, and then add them all up on my own. It's a tedious and pointless process. I could spend a couple hundred bucks to buy an electronic system that would make it automatic. That, OR--!!!

I downloaded Visual C# Express, since I heard every retard on the planet is using C# these days. I learned what I needed to know from the in-program documentation, and start to finish spent about 30 or 40 minutes. Here's what I ended up with:


It's ugly, right? But it gets the job done. I spend about 2 hours per payroll adding all that up--with this, I'll probably spend 15 minutes.

Here's the code:
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

namespace PayrollMcGee
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}

private void TotalLabel_Update()
{
TotalLabel.Text = ((dateTimePicker2.Value - dateTimePicker1.Value) +
(dateTimePicker4.Value - dateTimePicker3.Value) +
(dateTimePicker6.Value - dateTimePicker5.Value) +
(dateTimePicker8.Value - dateTimePicker7.Value) +
(dateTimePicker10.Value - dateTimePicker9.Value) +
(dateTimePicker12.Value - dateTimePicker11.Value) +
(dateTimePicker14.Value - dateTimePicker13.Value) +
(dateTimePicker16.Value - dateTimePicker15.Value) +
(dateTimePicker18.Value - dateTimePicker17.Value) +
(dateTimePicker20.Value - dateTimePicker19.Value) +
(dateTimePicker22.Value - dateTimePicker21.Value) +
(dateTimePicker24.Value - dateTimePicker23.Value) +
(dateTimePicker26.Value - dateTimePicker25.Value) +
(dateTimePicker28.Value - dateTimePicker27.Value)).ToString();
}

private void dateTimePicker1_ValueChanged(object sender, EventArgs e)
{
TotalLabel_Update();
}

private void dateTimePicker2_ValueChanged(object sender, EventArgs e)
{
TotalLabel_Update();
}

...

private void dateTimePicker28_ValueChanged(object sender, EventArgs e)
{
TotalLabel_Update();
}
}
}

Tedious, right? Just like always. It's super ghett0, completely taped together, and probably looks like something somebody would do if they'd just discovered visual programming interfaces.

So, um, yeah. That's me.

Chapter 1: Starts and beginnings

The goal of this blog is to document my work while I'm learning to code again, and to show to other people so that they might be able to a) learn from it, or, more likely, b) yell at me because I've been slacking.

Let me begin by saying that I started programming when I was about 14 in C and C++ for my Macintosh running System 7. I think I was using Metrowerks Codewarrior, a trial copy that came with a book I bought from the closeout bin at Books-A-Million. Either because of my lack of experience, my lack of years, or the fact that, if I recall correctly, writing for Macs back then was impossible, I had a hard time of it. It went okay, though, and over the years I wrote a couple of little games that never really worked quite right from beginning to end. But whatever, I was learning.

I worked a lot in Java as well, still mainly in high school, and again wrote some games, wrote some simple programs to do this and that, and learned a bit along the way.

Fast forward five or ten years, and here I am. I've forgotten most of what I knew, and that might be a good thing. I'm going to try really hard over the next couple of months to see what I can do, and I'll try to document it here.


The primary point of this post, though, is to list my goals, which are--at this time--the following:

1. To work in Visual C# Express to learn the basics of contemporary Windows programming. A big sub-goal in this heading is to better understand the program flow inside the Windows Forms framework--something which is kind of weird to me right now. A major reason for working within this framework is that it makes the UI end of things so easy that it will free my mind to focus on the actual code, the actual algorithms rather than making sure the event handler or menu system is working.

1(a). To work with the XNA toolkit, once task 1 is well underway, to write a non-trivial game that doesn't look awful, will take a fair amount of time and effort on my part such that it will feel like an accomplishment, and hopefully something that is actually fun (or at least interesting) to play. More on this later.

2. To learn (or relearn) the fundamentals, be it basic searching and sorting, data handling, or really whatever. I have not decided the best source of information to go about learning this, although I do have several related textbooks, two Knuth books, and the whole wide interwebs to assist me in this matter. This is going to be the least fun and most important item to work on, so I really need to do it.

3. To learn (for the heck of it) to work with Lisp, possibly working from Structure and Interpretation of Computer Programs. This task is inspired by another blog, and I do not in any way expect to complete this task in nearly the extensive fashion that the linked person has done. This task, as you may notice, seems fairly unrelated to the other two. It may be, it may not. I think it will stretch my mind in a thoroughly different direction, and while this task will receive the least immediate attention of the three, I'd feel very accomplished to get somewhere with it.

That's enough for now. I'll be posting what I have of the programs I've written so far in the coming days.

OH MY GOD DOG, IT'S A PROG BLOG

Okay, I've decided to (re)learn how to program. This will document my journey. HERE WE GO.