Well, another day, more work done, more lessons learned, and some new and exciting discoveries and announcements made as well. First of all, Soma announced on his blog today that F# is becoming an "official" .NET language, joining the ranks of languages like C#, VB, C++/CLI, JScript, IronRuby, IronPython, etc. If you're not familiar, F# is a functional language that started out in Microsoft Research as a project of Don Syme's. I think this is great news. And I'm thinking that perhaps I should give F# a try before I try Haskell or Erlang. The other discovery of the day was the XSI ModTool from SoftImage, a free modeling tool that also has XNA integration. It sounds and looks like a pretty comprehensive tool (especially for "free") and I am excited to give this a try. You can find more information on XSI ModTool here: http://www.softimage.com/products/modtool/. Enjoy! Other than that, just more work. Working on some presentations for the upcoming trip to Tech Ed Developer in Barcelona, Spain, continuing to work on Transactional NTFS, programming other Windows Server 2008 enhancements like Wait Chain Traversal, etc. I'm also back to spending time doing game development with XNA. I spent quite a bit of time with Torque X which I'll talk about here and on Xna3Way in the coming week or so. Fun, fun, fun :). Now back to work (so I can hurry up and get stuff done in order to spend time with the wife and son today (oh, my son, there's another post I have to make, he's SUCH a joy!)).
Okay, I admit it, I'm a WoW junkie. I spend WAY too much time in WoW, and not enough time doing the things that actually matter. Well, until recently (hopefully the trend continues). I started diving back into XNA again. Only this time, I'm diving back into it from a 3d perspective, not the 2d route I have always gone before. But why the sudden change?
Two months ago or so, I sent out an idea to an internal XNA discussion list at Microsoft that a bunch of us "hobbyists" should get together every other week just to geek out and do some game development after work. People loved the idea, so a bunch of us have been getting together after work to write some code and show each other what we are doing. Perhaps the coolest part is that since we are doing it in the same building where the XNA team is based out of, several XNA team members have dropped by just to check out what's going on.
In fact, at the first get together, Mitch Walker and others dropped by. Mitch had an idea about doing a month-long game development contest. So, that game development contest just concluded last Tuesday night. Oh MAN, were there some AWESOME games that people worked on. Me, being a total and utter dork, did not have anything to show. Truth be told, I had been writing next to NO XNA code, so there was literally _nothing_ to show. However, seeing some of these great games that were done, I figured it was about time to get back into it again. With how supportive this "user group" (of sorts) has turned out, I look forward to actually participating for a change.
So I'm back diving into XNA again. Instead of doing the usual 2d programming that I've always done in XNA, I figured it was about time for me to get involved in the 3d world. The game I'm going to do uses all the art assets from Spacewars and is going to be a vertical-scrolling shooter (like Ikaruga). Tonight, I decided it was about time to start prototyping the controls out and to make sure I could figure out how to display a 3d model (and show it from the top down).
Here's what the Shox Tonera prototype looks like after this evening:
I know that's not the best resolution, but you can at least see the ship (sort of). When you go left or right, the ship "rolls" to that side. When you go forward or backward, the ship "pitches" towards the direction. This is actually quite easy because the ship is technically in 3d. While the screenshot looks like a 2d game, it's actual 3d with the camera up in the air pointed straight down.
Also, you can see that the playing field is just the middle. I got bounding working so that the ship cannot leave the playing area. That was actually not too hard to do (easier than I thought it would be). I'm using the View and Project matrices to "project" the ship's position in the World into the actual screen coordinates. Then I can used the projected screen coordinates to ensure that the ship will not leave the area the playing area contains.
For those that are familiar with the Spacewars starter kit, I am just reusing the art assets from that in my own game. I will continue to do this for as long as possible. It definitely saves time.
The next thing I would like to do is to create the firing action of the ship using Point Sprits for the visuals. Hopefully either tomorrow night or this weekend I will get around to that. I would also like to do some refactoring to clean up the code. Tonight, I just threw it all in the game class for now to see if I could get it working (quite the departure from my usual behavior as any of my friends can attest to). I just need to be very careful not to get too wrapped up in refactoring and architecture like I usually do, because then I won't make _any_ progress on the game.
So why "Shox Tonera" for the name? Because I'm an unoriginal bastard, that's why. "Shox Tonera" is simply the letters from "XNA Shooter" scrambled up. I personally felt it sounded kind of cool too, so if you disagree, I don't want to hear about it :P.
I honestly don't know how I missed this piece of news. I didn't even want to share the news as I wanted to keep it all to myself :). Have you been messing around with XNA? If so, do you want to see your game on XBox Live Arcade? I know: who wouldn't. But you never know :P. If you would love to see this, there's an upcoming contest just for you: http://www.dreambuildplay.com/index.html. The prize that is currently hinted at is that the winner's game will be posted to XBox Live Arcade for everyone all XBox users to download and play. Now that's just wicked cool!
I had a fresh reminder of the exact reason why I love XNA so much. I figured that I wanted to brush up on my "1337 5k!llz" and that it was about time to get back into C++ stuff. Well, I love game development, so why not brush up by developing a game, right? Well, that was my thinking behind this whole story. I've been a DirectX kind of guy ever since I started in game development. So, what the heck, I figured I would stir up the pot and try some OpenGL development in C++. Not a problem, there's a metric crap-ton of OpenGL tutorials over on NeHe that I can follow. Here I come "Creating a Window", YEE HAW! Visual C++ Express installed? CHECK. Windows SDK installed? CHECK. Visual C++ Settings pointing to new Windows SDK directories? CHECK. I'm ready to roll, all y'all. Let's get on with it homeboys. So, open up the first tutorial, type in all the code for creating a window and clearing the screen.... .... DAMN, that was a LOT of typing. Holy moley, I could have developed a bad case of arthritis from the tutorial alone. Geez, how many lines of code is this? 400?!?!?!?!?!? 400 lines of code to get a BLANK WINDOW on the screen? WTF?!?!? Okay, forget getting my "1337 5k!llz" back in shape, I'm just going to spend that time continuing to work with XNA. Perhaps to make it more "1337," I'll play around with the Lex/Yacc-type stuff in the Visual Studio SDK to write my own language that I can use as a custom scripting language in a game. Yummy. TIMMMMMEH!!! TIMMMMMEH!!!
I don't know why, but apparently it has taken me until now to finally "get" podcasting. The interesting part though is that the .NET-type podcasts aren't the ones that have really caught my attention. No, it has been the game development and other video game-related podcasts that have caught my eye.
The one that got me started was GDC Radio. It has a bunch of game development-related podcasts that are excellent. I've loaded up on a bunch of them to get ready for my 10 hour flight to Amsterdam on Saturday. One particular one that sounds interesting is an interview they did with Bioware on 'Creating a Monster RPG.'
I dug through the iTunes podcast directory (the more I use iTunes, the more I love it (that, and my iPod)). That led me to a bunch of podcasts on video games and video game reviews. Just what a video game geek like me likes :).
Now, when I'm packed into the sardine can stuffed with high oxygen levels for exorbitant amounts of time this weekend, I can zone out and listen to these podcasts while getting all doped up on apocalyptic amounts of caffeine and pretending that I'm on some far-off safari voyage across the picturesque lands of the Serengeti (although I don't know why I would exactly do that as I'm not much of an outdoor person (I suppose it just sounds better than "playing Final Fantasy 3 on my Nintendo DS Lite")).
Well, it was bound to happen. Now you have some lawyers (or at least, people WELL more versed in the law than puny little me) stepping up to talk about the affect on Intellectual Property with the upcoming release of XNA. Check it out here.
I would comment myself but seeing that A) I'm practically a drooling moron when it comes to law (I probably couldn't even play one on TV (then again, I can't act worth crappola)) and B) It's like 12:30 in the morning and I'm friggen' tired and need some sleep, so technically I haven't "read it" completely yet.
Of course, it's probably a good thing I haven't read it. It would only come out sounding like some kind of dramatic space-opera poised to knock off George Lucas to become the first monstrous Space Guerilla to conquer "He-Who-Created-The-Dreaded-Jar-Jar-And-Should-Be-Killed-For-It" Lucas at King Of Space Mountain (and I'm not talking about that crappy little Disneyland ride Space Mountain either, "for the record" (as they would say in legalese (huh, who'd have figured, perhaps I can play a lawyer on TV after all seeing that I have the legalese down; that was easy)).
Anyway, like if you're into the whole Intellectual Property / Copyrights / Trademarks / Legal Issues that come about in regards to software, like, you should check the article out, and stuff. Peace!
As Benny mentioned on his blog, last night I had pleasure of going out to dinner with ZMan and Benny. We went to Ruby's Diner out at Redmond Town Center.
For those of you "not in the know", Ruby's Diner is a 50's diner among the many other 50's diner clones and knock-offs that tend to invade the rest of the country like a sweeping parasite spreading with reckless abandon, all the while trying to convey a sense of the Good Ol' 50s with a disdain that shows just how warped and twisted our country seems to be now when compared to "simpler times."
Of course, I find all that ironic considering that the waitresses wear extremely short skirts that are borderline-Hooters that you would have scoured the country for in the 50s and not found a shred of evidence of its ultimate existence. The mythical "short-skirt-and-large-mammary-glands waitress" that is not afraid of flaunting it all in the name of Show Business. I guess it shows how it's becoming more difficult to go out for a simple meal without getting some kind of Show in return. Sigh, us Americans and our twisted Capitalist ways: anything in the pursuit of money. It's the one American Universal :).
Enough of this pseudo-intellectual psycho-babble that I have absolutely no knack in the least at pulling off. The conversation was pretty fun. We covered everything from game development and XNA, to health (and me thinking about my apparent lack of it :P), to banks, credit cards, identity theft and the differences of all the above between this funny country, Amerigo Verspucci's namesake, and European countries like Germany and England (or is it Great Britain (or the United Kingdom (eh, what do I care; I'm just a crazy American anyway)).
Two things dawned on me throughout the night. First, Benny is crazy smart and wicked good at game development. One need only look at all that he's done (and see Xna Racer in action) to come to that conclusion. I honestly wish that I could be half as productive as he is. Perhaps that gives me a goal to shoot for :). Second, Andy can Get Things Done. I'm jealous of Andy in this, as I never have seemed to be able to finish any personal project outside of work. Oh, and all that jogging and running have done wonders for Andy's sexual charisma, haha. If I was a Bummer (as some of the Brits like to say), he just might be that fruit of temptation that would get me exiled from my personal Eden. Alas, I'm not, so I'll just admire Andy for his fortitude and sticking with it through the last 18 months and keeping it up.
Thinking about it in hindsight, the night was pretty inspirational. Seeing all the work that Benny has done, and all that Andy has accomplished as well, I'm going to try to take some baby steps to make me more productive in my personal life as well. First of all, I'm going to finish a game for once, dang it! After having messed around with being a hobbyist game "developer" for as long as I have, it's shameful for me to admit that I have never finished a single game. Yup, not one. Not a single game.
I say game "developer" in quotes because looking back at the least three years I might as well have been a game development "philosopher." I argue the fine points of how to design a game and how the code should look, but never get anything done myself. I'm all bark, and no bite. Well, time's are a changing, and I'm going back to the roots. Tic-Tac-Toe baby. Yup, I'm going to finish a game dangit. Tic-Tac-Toe, then Breakout, perhaps Tetris. No more predictable "Jason get's nothing finished" jokes. Well, at least for the next week until I settle back into my ways (I give Andy and any of you out there my full consent to call me out if I settle back into my rut though as I truly do need to change my ways).
Anyway, I send all my gratitude and thanks out to Benny and ZMan for the wonderful and enjoyable evening. May the motivation from it last longer than a couple of days and help me actually get some private projects done for a change.
Well, day four of Stones. I didn't get too much work done last night because I went out and had an excellent dinner with my wife and my father (who was in town on a business trip). Oh, and I also was working out some plans with some friends on an ultra-secret project :). I can't say anything yet, but hopefully once things settled down and we're a way into the project, we'll reveal it publicly. Until then, mum's the word :).
Soooooo, here is Stones on Day 4:
In this image, there are three things to show you. First, the images of all the stones are finished. Yes, they are very "Programmer Art" right now, but they will do until I finish the game.
Secondly, if you are at all familiar with the rules of Bejeweled, you will notice that there aren't any "matches" on the board (three, four, or five stones of the same color in a row). To make this possible, I needed to implement some rudimentary rules for "match detection" to prevent the random board generator from generating a board with matches from the get-go.
Lastly, there is now a cursor on the board. Using the keyboard, navigation is fully enabled. You can swap two pieces just like you can in the full blown game. I still need to enable "rules detection" on the move to detect whether it is a valid move or not.
It's coming right along. Not bad for four to six hours of work having never worked with XNA before. Of course, XNA deserves all the credit there as it is more because of XNA that I'm able to crank along like this. The first thing I need to do next is to do some cleanup and refactoring. There are some new GameComponents that I can extract after tonight's coding session. There are also one or two other "abstractions" that I would like to do to clean up the code a bit.
After the cleaning session, I will move on to verifying the validity of a move before allowing it. Once that's done, I will move onto adding the actual removal of matches, crediting of the scoreboard, shifting of the board down, and generation of new pieces. Yeah, that sounds like a lot, but a good amount of the framework is already there to plug into.
Well, until next time folks :).
Update: Yikes, it appears that my comments are disappearing (I suspect WebHost4Life is doing some backup/restore kind of thing). Well, I got a comment from someone (sorry, I forgot your name) regarding my usage of Vista above (even though Vista is not supported by XNA GSE). I have to admit that I am actually running an early internal build of a future VC# Express (SP1, I believe?) that adds support for Vista (one of the perks of being an MS employee). However, it's not all perks, I still can't really do any XACT audio work. Once I move into my house this weekend, I will be getting my desktop computer out of storage and working on XP just like the rest of you folks are.
Well, today was my second day in XNA land working on Stones (my Bejeweled clone and my first XNA game (and also a subtle play off of Jason Mauer's Bouncing Balls demo)). Once this game is finished, I'll be using it as a vehicle to do a series of game development screencasts on XNA (most likely it will also be in tutorial form that will be included with the video in the download).
I'm still just psyched how good XNA is. Maybe once I come down from "Cloud 9," I'll be able to come up with some constructive criticism. But until then, I'm going to just enjoy the ride. So, here's what Stones looks like today after Day 2:
I have navigation between the Title Screen and the Play Screen working. Of course, that only took all of about two minutes. Above, you can see the play screen. That's a generic background image I'm drawing (I just grabbed it out of my Sample Pictures directory). The playing grid you see is actually a superimposed texture using alpha blending. The playing grid image is actually shades of gray so that I can tint it according to the color pallette of the background image.
Next, I'm going to make some stone images and see what they look like with the board filled up. After that, I will make PlayingField a GameComponent that I can simply add to the GameComponentCollection that I have encapsulated in the TitleScreen. Once the PlayingField is finished, I'll move on to the business rules and scoring. When tackling the scoring system, I'll probably also tackle what the scoreboard looks like there on the left.
The "Play Screen" text you see on the screen is actually being displayed by a VisualDebuggerComponent that I have built. The VisualDebuggerComponent publishes a IVisualDebuggerService that can be pulled and used anywhere in the game using Game.GameServices.GetService(). Eventually, I plan on extending the VisualDebugger to include a debugging console that will drop down from the top that can be used for debug logging as well as actual visual debugging of things like bounding box visualization and stuff like that. It should be pretty cool :).
Of course, all these components and such I'm building into a Harvest Game Library that I'm building. Currently, Harvest Game Library will mostly be for my personal use as I build several games, but I'm hoping to release it in the future so everyone can enjoy it.
Now I can't wait until tomorrow night when I get to work on it again :).
Hey folks. After a good amount of time away, I have decided to come back to game development land. This time, I will continue work on my game Spaceballs (a Geometry Wars clone), only using XNA this time around. I can't believe I'm going to admit this, but to give myself time to do this, I have even canceled my World of Warcraft account (again). I just have way too much stuff on my plate, and if I want to get back into game development, something has to go (thanks go to Chris and George for encouraging me to do so simply by reading their posts). So, I've started "porting" Spaceballs to XNA. Maybe not so much porting, as re-writing (as I want the game architecture to reflect the new XNA environment and framework). My first impressions of XNA? Oh boy, does it kick butt. As a guy into design patterns and such, some of the first things I notice are the architecture of a framework I'm working with. And, truth be told, the XNA framework is one of the first frameworks (not including the .NET Framework) that I have just LOVED the architecture of. The separation of GameComponents from GameServices from the Game itself is fantastic. The way that the GameServices collection in the Game serves as a ServiceLocator of sorts is just fantastic. I'm so used to having the "why did they do this? This is crap! Oooo, that's ugly" kind of thoughts with other frameworks, I'm just so pleasantly surprised to not be having those thoughts with XNA (quite the opposite actually). Now, if you're not too familiar with a Services (ServiceLocator) pattern, then I can see how the distinction between GameComponents and GameServices might be confusing. I hope to shed some light on that in the future as I will be planning to resurrect the tutorials from before (perhaps this time in Screencast form). I have found that when working with the XNA framework, I have noticed a good amount of my old code from Spaceballs simply disappearing because the Framework is handling what I need it to handle. That's a feeling I like to have. Not only that, if used properly, you truly start to build re-usable components that you can use in various games since you're encouraged to think about GameComponents and GameServices. One of the other things I'm looking forward to is that we, as game developers, can finally stop talking about "the perfect game loop" and those sorts of conversations, and start talking about the cool GameComponents we are building and such. I think the XNA framework could be a huge step forward in providing us a way to share patterns and practices with each other. Not only sharing patterns and practices in a "word of mouth" sort of way, but by actually sharing the GameComponents themselves with everyone. Man, there are exciting times ahead of us as hobbyist game developers. At the rate I'm going though, it might not actually take that long for me to get back to where I was when the GWB game development contest finished. Hopefully then I'll crank through the tutorials/Screencasts. I'm currently shooting for sometime around Christmas time, but it might be afterwards. I would like to give one shout out right now. David Weller and team, GREAT JOB. You guys did such a good job developing this product for us. If it was just for PCs, I would still brag about how cool it is. But considering it will be XBox capable as well? You guys truly are amazing. Keep up the great work!
I know Dave, Tom, and Boyd had stated that they were pleasantly surprised that the announcements coming out at GameFest tomorrow hadn't been leaked. Well, close but no cigar (if this is indeed the announcement they were talking about). Of course, considering that it is already "tomorrow" on the east coast (and many of you won't read this post until "tomorrow" anyway), it's probably close enough :).
So, check out that link above :).
As a hobbyist developer myself, I have to admit that I did entertain thoughts in the back of my mind that it perhaps wasn't going to get any easier for us. Well, I'm happy to say that it looks like that thought was totally false. Not only was that thought wrong, it was WAY wrong. Microsoft (according to the Joystiq article) will release a free version of XNA Game Studio inline with their current Express products. So, for those of you enjoying writing games with totally free tools like Visual C# Express, you will be able to apparently continue doing so when XNA is released.
That isn't the most exciting part though. From what it sounds like, Microsoft is indeed going to support hobbyist game development on XBox Live Arcade. Of course, that isn't free. However, it currently appears that it will be fairly cheap, just $99/year. This could be HUGE. I mean HUUUUGGGGEEE. This opens the door for a Community-Powered XBLA, all in Managed Code nonetheless!!! Oh my, I'm getting tingles just talking about it :).
Imagine being able to write a game for your 360 yourself, AND be able to share it with friends. Heck, I can't imagine what the possible ramifications for the game industry are. If done properly, it could be history all over again. It could be "the next" Shareware model that will see a level of innovation not truly seen since the days of Commander Keen, Wolfenstein, and Doom. Will the next iD grow out of this new model. Could this be the next opportunity for hobbyists to be able to make a living of their game programming. Okay, I won't get carried away here, I can't imagine the same boom happening that happened in the 80s/90s. But geez, in some ways it could be even better.
I, for one, will HAVE to check this out when I can get my hands on it. Oh boy, good luck getting me to sleep tonight! Thanks guys!
(Andy, I can't wait to see you start writing about this stuff :P).
Update: I found this Microsoft PressPass Announcement
Holy Moly! Could Microsoft release fewer cool products for a while please? :). There has been so many exciting technologies coming out lately that it seems like there is hardly enough time to investigate them all. The latest edition to this group of great technologies? Microsoft Robotics Studio.
There are a few things that excite me about this specific technology (from what limited investigation I have done on it during my lunch break today):
1) It is enabled for both Visual Studio _and_ the Express products (you can even use it from IronPython).
2) Robotic simulation. If you don't have the hardware to play around with it, Microsoft Robotics Studio includes robot simulation using DirectX that you can use to programatically build a robot and show how your "software" would work with the robot. I'm slightly jealous because this was one of the ideas I had behind my next game (take this Studio and make a "battle game" around it, and that was Tanks).
So, I obviously need to play around with this some more. Perhaps I'll still build Tanks now that a good amount of the "leg work" has been done for me through Microsoft Robotics Studio. I'm wondering since Robotics Studio has its own runtime and such, if I can embed that runtime within a game so that I can build a game around it. Heck, that sounds like a fun project as a matter of fact. Perhaps I've found my next endeavor after Spaceballs is finished.
Enjoy!
I know I was shooting to get the lives system implemented last night, but I wasn't able to do so because I needed to fill out a bunch of paperwork and do some general catch up on some other tasks (non game-development related, that is). So tonight was my first opportunity to work on Spaceballs since Tuesday night.
I'm proud to say that not only did I get done what I was shooting for (multiple lives for the player as well as the "Get Ready, Set, Go!" countdown at the beginning), I also got done a lot more. I love the feeling of being very productive because the architecture and framework just enables you to be productive :). With the way I had implemented my state management (combined with existence of my new Task Manager), I was able to finish the GameOverState as well as add a death animation for when the player dies. I also added a bunch of prompts throughout play and stuff. What a great feeling!
Now with lives, respawning, death, death animation, game over, etc. all implemented, the functionality and flow of the gameplay is _literally_ feature complete now (must haves + nice to haves). Now I can move on to adding the new enemies, power ups, and such (read: all the fun stuff). I find myself getting more and more confident with each coding session (of getting something fun and complete done by the deadline, not of winning (especially with all the other fun games being done)).
I do have some cleanup left to do after tonight's coding session. This just involves creating a quick UI component that can be re-shared between the various GameStates I have for the Scoreboard area (Score + Lives + Prompt/Possible Message To User). That should take almost no time at all. Perhaps after that I will do a release of the binaries and source for all of you to download (maybe tomorrow night?). Regardless, sharing code and binaries is very easy for me since I have a script that automates the cleanup of the source code, generation of release notes, and creation of the zip files for me.
Once I'm able to do that, I'm hoping that starting tomorrow night and ending sometime Saturday, I can create and finish a HomingSpaceball (charges after the ship wherever you go) and a WanderingSpaceball (moves in random directions). If I'm able to get those done, I would like to extend the HomingSpaceball to break up into four smaller spaceballs when it is destroyed. That should add some more fun to the game.
Now, in the miraculous case that I'm able to get all that done this weekend, I will move on to adding a new weapon (which will require me to finally create a new Weapon class and change my firing mechanism around a bit (once again, shouldn't take that long)) that you will automatically upgrade to at 10k points. When that is finished, the next step will be adding bombs to the player's arsenal that will destroy all spaceballs that are in play when it is dropped. Holy cow, if I could get all that done (even by next Tuesday or Wednesday), I would _REALLY_ be cooking along toward my goal. Perhaps then I could start doing some play testing.
Until next time, that's how the cookie crumbles :).
OgreDotNet was recently pointed out to me by a friend and co-worker. I don't know have I missed it in the past, but I see it's there now which is the important part :). With the lack of mature, open-source 3d graphics engines for managed code out there right now*, I'm glad to see this come to fruition.
Since Ogre3d is already object-oriented, you can't tell from the code of OgreDotNet that it is simply a set of bindings down into the C++ libraries of Ogre3d :). Not only that, but it appears the forum is fairly active and alive (and that's the OgreDotNet forum I'm talking about (since the regular ol' Ogre forum is _very_ much alive)).
In the future (aka after I finish Spaceballs and perhaps another game or two), I will probably end up using this for my first 3d game I do (and possibly all the other 3d games I do after that). I really want to just break down and start playing around with it now, but I'm sure my competition in this contest would like for me to do exactly that. SOOOO, perhaps once Spaceballs is finished I can start playing around OgreDotNet.
Until then, make sure you check it out :).
http://www.ogre3d.org/wiki/index.php/OgreDotNet
* Axiom priorly being sucked up into RealmForge (I know the source forge project has started up again, but it _just_ started up again seriously, in my opinion), RealmForge now being "deprecated" of sorts, and the other options like Irrlicht.NET and Haddd not being as mature and supported as Ogre (again, just my opinion)
I didn't quite get around to implementing the lives functionality tonight. However, I did do some general cleanup and "paved the road" for me to easily drop in the code for respawning and multiple lives tomorrow.
One of the refactorings I did was to take what I was calling "States" before and change them to "Screens". Really, they were screens. As I needed to start adding states to the gameplay itself (like PlayingState, LostLifeState, etc.), I didn't want to go down the road of making a hierarchical state manager because I felt it would muddle up what was really being done under the hood. I felt that separating out Screens from States would lead to a much more clean implementation.
Rather than states being things like MenuState, PlayState, RecapState, and HighScoreState, those are now MenuScreen, PlayScreen, RecapScreen, and HighScoreScreen. In my mind, that makes it much more clear what they are actually doing. States are now concepts like ReadyToPlayState, PlayingState, LostLifeState, PowerUpState, GameOverState, etc. Once again, I am happy about this change as I am really liking the separation between "Screens" and "States" rather than hacking both concepts into one. The code is not only cleaner, but it will also be much more clear where the functionality I'm about to implement goes. For instance, the multiple lives functionality will simply be transitions from PlayingState to LostLifeState and back to PlayingState. If I add the "countdown" at the beginning of the game (think "Starting in 3... 2... 1.... GO!"), it will simply be starting with ReadyToPlayState and transitioning to PlayingState when appropriate. This will also help break out the code into more manageable chunks as well (which I always like).
On an aside, I think I use Source Control much more than I originally thought. It's only day 20, and I'm already up to revision 61 in SVN (61 commits). Better safe than sorry, I suppose :).
I still don't have any comments to make on Visual C# Express. I still haven't really noticed the difference all that much for my hobbyist development. Anyone out there that wants to get into C# development should _totally_ download Visual C# Express and use that. Besides, you can't beat the price of FREE :). The one thing that I can say is that, in my opinion, the Express products are better than the other free IDEs that are out there today. Usually, you get what you pay for (meaning free can suck tremendously), but not with the Express editions.
That's it for this update. For tomorrow night, I'm going to shoot for implementing multiple lives (a.k.a. LostLifeState) and hopefully get around to implementing the ReadyToPlayState as well to add the countdown to play time. Those shouldn't take too long (hence the reason I'm hoping I can get both of them done tomorrow night). Until then, I'll see you on the flip side :).
Not much functionality change tonight. Nope, tonight was mostly bug squashing night.
The first bug I squashed was around spawn point generation. Sometimes, a spawn point would be generated that would cause a Spaceball to be spawned within a wall. This was due to the spawn point generation algorithm not taking into account the size of the entity is was generating a spawn point for. That was an easy fix :).
The next bug I squashed was around the ball-reflection logic I had to bounce Spaceballs off of the walls when they hit. Unfortunately, it didn't take into account whether the code had already flipped the velocity vector based on a prior collision with the wall (i.e. a collision from the frame before (meaning, it is _still_ stuck in the same wall since not enough time has passed to clear the wall)). This was causing Spaceballs to become "caught" in a wall or to pass right through it. This was also an easy fix. I basically added logic to not only check for the collision, but to also check whether the Spaceball was still headed in the "wrong" direction before correcting its velocity.
The last thing I implemented was more around missing code. When implementing the game loop originally, I had forgot to add the ability for a game to be "paused". This meant that if the form lost focus (like navigating away to a different window), that the game would still run in the background. Oops :). That was also an easy fix, so it behaves properly.
Fixing the game pausing functionality exposed another bug, though (don't you love when that happens?). My EnemyEmitter class that was spawning new enemies on a frequent basis was checking a DateTime field from the last time it spawned to DateTime.Now to verify whether it needed to spawn a new enemy. This meant that the second a new enemy was spawned, I could make the window lose focus, wait several seconds, give the window focus again and a new enemy was spawned right away. Bad Jason! I should know not to check against *real world* elapsed time. I changed the code to record how much time had elapsed *in game* since the last spawn (by adding up the elapsed time through each "Update" call to the Emitter) and Poof! Bug fixed :). Once again, easy fix.
That's about it for tonight. Hopefully tomorrow night I can implement the lives system (i.e. giving you three lives rather than the game being over the first time you get hit). I was really hoping to do that tonight, but I guess it just wasn't in the cards :). Once I do that (which will include some refactoring to add "spawning" of ships themselves and fixing an annoying spawning issue I currently have), I will truly move on to implementing some of the various other Spaceballs I have in mind. Then the true fun begins (not that it hasn't been fun up to this point :)).
Well, I was able to squeeze in _some_ coding time last night and this morning. The update to Managed DirectX is all finished. It's kind of nice to see FPS should up from 90 fps to around 550 :).
All in all, it took about three hours to upgrade from GDI+ to Managed DirectX. Boy am I glad that I wrote the infrastructure the way I did. After a quick refactoring (making it so the IGraphicsService implementation rendered the Sprite rather than the Sprite itself), all I had to do was implement a new Direct3dGraphicsService and change the ServiceLocator to use an instance of that instead of the GdiGraphicsService it was using before. Viola! I'm now in Managed DirectX land. I love when to make a change like that, all you have to do is add another class rather than comprehensively changing your existing code.
Unfortunately, I'm still at the hotel in Seattle so I can't commit my changes to my Subversion repository yet (boy does that feel weird; I guess I'm used to committing often when I make small functional changes).
Now I believe I'm in a position to sustain for the long haul (as in, the system can grow to handle a particle engine and the like rather than having to find clever ways around the fact that GDI+ is not hardware accelerated).
So, what are the next steps?
1) Resolve a bug around Spaceball creation (sometimes the Spaceballs are created in the walls). This should be easy as it is simply limited the spawn area by the dimensions of the Spaceball being created.
2) Add "lives" to game. You will start out with three lives and the game will be over when you have no lives yet (currently, you only really have one life). I will probably re-implement my TaskMaster here to handle delayed spawning.
3) Create "invisible time" for two seconds when a new Spaceball is spawned. Currently, if a Spaceball just happens to spawn where you are: BLAMO! Game over. Just a little annoying, to say the least. I want to fix this.
Once those are done, I figure I will either "beautify" the Menu screen, or I will start adding in more enemies and gameplay mechanics (like Ship power-ups and such). Currently, I'm leaning towards adding some more gameplay mechanics as I would rather get those down and fleshed out before making the various screens look good (which I can always do at the end). Basically, I want to prevent myself from spending so much time make it look pretty that the gameplay suffers.
DirectX Rant #1 - The errors. They're horrible. If I accidentally try to Draw a Sprite before calling Begin(), please just tell me that "Begin must be called first" or something like that. Whoever thought that "<INSERT MAGIC NUMBER HERE> D3DERR_INVALIDCALL" is a useful error should be SHOT on sight.
Visual C# Express Thoughts - I agree with George, here. In this case, no news is good news. I work with Visual Studio at work and the fact is that I have hardly noticed that I'm _not_ working with it at home. The only difference for me is that I'm missing ReSharper, but that is _only_ because I've been too lazy to install it yet :). You gotta love a quality IDE that doesn't get in your way and has so much functionality to it!
I haven't done any coding recently as I've been getting ready for the gig I just had tonight in Seattle. I'm now checked in to the (crappy) hotel (the room is about as big as my left thigh). Luckily, they have wireless, so I'm able to at least give this update.
I realized yesterday that to take this game where I want to take it, I really need to upgrade to Managed DirectX to leverage the hardware acceleration (especially once I get into implementing my particle engine/system). So, as soon as I get back, I will be upgrading the game from GDI+ to Managed DirectX. Luckily, this conversion shouldn't take too long as I simply need to add a new Direct3dGraphicsService class and change my application to use that.
Actually, that's not entirely true. I also need to change some of my game logic. This is because GDI+ expects the origin to be in the upper left corner, while the way I will be setting up my camera in MDX will expect the origin to be in the _lower_ left corner. That should be pretty easy to fix though.
Perhaps if I really start using MDX, it will allow Andy to start giving some blogging love to it :) (don't forget Andy that George is also using Managed DirectX for the contest).
Anyways, back to reading the AI book I picked up the other day.
You may not get another Spaceballs update until Monday or Tuesday night. Sorry :).
Well, I didn't think I was going to be able to make much progress on the game until next week (since I'm going to be gone all weekend), but I was able to get in some coding time tonight that I wasn't expecting. And you know what? I'm glad I did :).
My tracer bullet is completely finished now (take that George, :P) :).
Tonight I wrapped up the High Score system and made it persistent using simple XML serialization to the game's own folder under the Application Data directory. The High Score screen is displaying the results and the Recap screen will congratulate you if you have achieved a new high score.
So, all the major "required" features are done and checked off the check list. That means that what is left is making it look good, adding more enemies, tuning game play mechanics, etc. This is one feeling that I love about implementing tracer bullets: once you finish the tracer bullet, you realize that a large portion of your system is fully operational and ready to be added onto.
So, now I'm on to simply making it fun. Not bad for Day 14. I still have roughly 28 days to finish the game (giving me some wiggle room, just in case). I'm fairly confident I will have quite a fully-featured game by that time considering that I have twice as long left than I've already spent on it.
Yee haw :).
Perhaps I will take some time next to do some performance profiling and getting my framerate back up since it has dipped to under 100 fps. Although, on second though, I won't worry about that until it dips under 60 fps since it won't be noticeable 'til then anyways.
Soooooo, I guess I'm on to adding some new enemies, weapons, power-ups, and the like. Sweet! Here's where the real fun begins :).
Well, since Sir Georgio decided to give me some crap about losing focus, I figured I would post about what I've been doing.
The MVC work is all finished, cleaned up, refactored, and ready to drop a bunch of new types of enemies into the game. Before I did that though, I decided to clean up the graphics a bit.
One of the first tasks was to implement a "playing field" that play would take place on. Before, play was just the whole screen which wasn't very conducive for HUD-like UI (like Score, Lives, etc.). The playing field is now implemented and operational.
I still think it is important for me to hook up the High Score system before plugging in new enemies. Once the high score system is fully implemented (shouldn't take that long), my tracer bullet will actually be entirely complete and functional. Then I can move on to beautify-ing the application and adding some more gameplay elements.
Here's a new screenshot of how it looks now. Still not stellar, but a definite improvement over my last post (and yes, I made the Sprites myself (although any artists out there can probably tell that fact already)). 
The tracer bullet is basically all finished now. I have enemies being spawned on a regular basis, the scoreboard is operational, the "Recap" screen is working. The only thing that is not implemented yet is the High Score system and screen. Of course, currently there is only one "type" of enemy and the game stays at an even pace and never "accelerates" to make it harder.
Obviously, there is a lot more work to do. I'm just happy to be at a point where the game is basically entirely functional now. That makes me happy :).
Tomorrow night will probably be spent doing some cleanup and refactoring to make up for today's coding session(s). Once I hook up the High Score system, I will need to add some different types of enemies and add some increased pacing to the game. I will probably also have to tweak the game flow a bit (ship speed, bullet speed, enemy speed, etc.).
Now, to show how truly pathetic I am at art, and to show off my extreme programmer art, I present this screenshot. Just remember that to this point, I am _not_ worrying about graphics. I am worrying about gameplay and functionality. Perhaps posting this screenshot will really make Chris and George think that I will definitely lose :). 
I noticed that in Chris's "latest post", he is merely talking about what technologies he will use, what the game will be, etc. Chris, I'm going to give you a little tip. If you want to win the contest, you have to WRITE SOME DAMN CODE! It's ironic that at the start of your project, you were trash talking me about how I wouldn't get anything done. Where are you now? Huh? For goodness sakes, a guy who has never written a game is further along than you :P. I'm just curious, how does that feel?
Although, I must fully admit, I want to see some updates from Chris on writing code as I want to be able to steal any ideas if necessary to guarantee my victory over him :) (I could care less about winning the 360 as long as I beat Chris (and George, for that matter :))). I also like reading about people's progress on their games as I think the "behind the scenes" aspect is one of the best things you get with blogging.
So, get to blogging tattoo boy :P.
On a different note: George and Rick, you are still in the Portland area right? If so, we should geek out on developing our games together some time :).
Okay, just one last update before I head off and hit the sack. I was able to get the Wall game object written. I also just wrapped up my CollisionDetectionService so I have collision detection working in my game now. For now, the collision detection is rather rudimentary. It just uses bounding boxes along with the RectangleF.Intersects() method in the .NET Framework to do bounding volume collision detection. Pretty simple, but pretty effective (I may not even have to change it for the rest of the project).
I'm liking how the collision detection reads. I'll have to show that at a later time though (maybe in my retrospective?). I'm also storing a "cache" of collisions so you don't see "Ball1 collided with Wall1" and "Wall1 collided with Ball1" as two separate collisions. All my game objects derive from a common GameObject base class which has an ID property that is generated by producing a new Guid. So, the "cache key" that I'm using is basically xor'ing the hashcode of both objects' Guids together. Once again, pretty simple.
My one concern with the collision detection algorithm now is that it is brute force (checking every object against every other game object). Since this game is a simple 2D game that may not grow that complex in regards to the number of game objects, I'm hoping this algorithm will continue to work. If not, I'll look at moving the game object repository to storing by quadtree or something like that to better cut down on the number of collision checks that I'm having to do.
With this progress, I'm thinking that I can spend Friday night and Saturday working on plugging in some enemies (e.g. the Spaceballs that will gives the game its name), getting the scoreboard working, and perhaps getting health on the ship working as well. All in all, I'm happy with where I am. I'm well on my way to getting a functional tracer bullet up and running in a week or so. Then I can start working on polishing the game up (aka making the game look pretty and be fun).
Good night, all!
Luckily, I was able hit most of my goals for the day. I still have yet to get to collision detection, but that's not that big of a deal as I can whip that up sometime on Friday night or Saturday. I have my ship automatically firing now according to a firing rate and have all controls working through the messaging system. The architecture is starting to shape up a bit and I can see that it is going well.
Next is to add one enemy and get collision detection working. After that is when the fun really starts. I then get to start hooking up the ship's health, number of lives, the scoreboard, various different enemies, etc. Basically, all the fun stuff :).
Perhaps I will post a picture here soon. Just be aware that it is suffering from programmer art something FIERCE. Of course, for the first half of the project, my focus won't be on looks, it will be on gameplay. I want to get the tracer bullet in place as soon as possible.
Back to coding for now :).
::code, code, code, code::
::some time later::
More updates. I got some boundary checking finished. The code now checks if bullets have left the field of play. If they have, they are immediately removed from the game. I don't like the way it feels though. I'm thinking of implementing a Wall game object. This way, there will be four Walls that comprise the "field of play". If I go this route, than I can use normal collision detection for boundary checking as well. Basically, if a bullet collides with a wall, remove it from play. Also, if a ship collides with a wall, don't let it go any further. I will feel more comfortable when all this code is using the same collision detection algorithm rather than numerous "special cases". This could also open up some interesting game mechanics (like having a non-rectangular field of play or adding obstructions in the middle of the field of play, etc.).
So after that last coding session, I am exactly where I wanted to be by the end of tonight (and I still have another hour of coding left :)). Maybe I will move on now to writing up the Wall object I talked about above. If I can crank that out real quick-like, I will whip up a CollisionDetectionService that will be used to detect collisions. Then the SpaceballsGame class can determine what collision interactions it needs to deal with (like Bullet -> Wall, Ship -> Wall, etc.).
If I can get all that finished tonight, I will be ahead of where I was hoping to be at this point in the project (although perhaps not, since I won't have any coding time on Thursday Night, Sunday, or Monday :(). The good news would be that almost everything would be in place to start dropping in enemies and getting them going :).
Until next time, I'll see you on the flip side :).
A couple minor changes (or not so minor when it comes to control schemes). Tonight I took some time to play Geometry Wars Evolved for a while (the game Spaceballs is based on) and I came to a decision.
One of the difficulties is translating the control scheme to the PC as the console gamepad has the two joysticks that are both used to control the ship in Geometry Wars. As of earlier today, I was using a combination of the mouse and the keyboard (nearly Quake-style controls). You "dragged" the ship around with the mouse and turned where it was facing using the A and D keys. After trying it out for a while (and going back to play Geometry Wars), I realized that it felt unnatural and was not very intuitive. I have changed it to flying the ship forward using the W key, and flying backwards using the S key (full-blow Quake-style control scheme now).
With this change I realized that I needed zero mouse support for my game, so I had the pleasure of ripping all that code out (have I mentioned the sick twisted pleasure I get ripping code out of a code base?). It wasn't much code to rip out, but it still gave me a pleasure :). I saw in an earlier posts of Chris that he was considering support a Gamepad. That is a fabulous idea and I might need to steal the idea (Chris, you want to check out XInput now, I believe, not Direct Input). Heck, I have an extra 360 controller lying around from Microsoft Meltdown so I might just have to put it to use here. I will save that until the end though because I don't want to get hung up on a feature that is only "a nice to have" and not "a must have".
I had talked about it earlier, and after much internal debate, I have decided to re-introduce the messaging and tasking system. However, I am only re-introducing a much simplified model. It won't be nearly as complex or as feature complete as I am only going to add the bare necessities this time around. Once those are finished, I will change my ship to fire continuously like Geometry Wars (rather than based on an input command). Hrmph, even as I'm typing this I'm still having an internal debate about whether to go forward with this. Perhaps that is a sign that I still haven't quite decided yet and the back of my brain wants to work some additional things out. Oh well! I'm not going to let that hold me up from making more progress. Back to coding.....
::code, code, code, code::
::two hours later::
Sidetracked!! I ended up re-working my keyboard handling since I wasn't happy with it (it was quite *hackish*). That is all fixed, and I did some "cleanup on aisle 7"-style refactorings (nothing too big). I went ahead and converted the ship controls to be completely keyboard driven. It feels a lot better, but it's still not as comfortable as I would like it. It will work for now though.
Tomorrow I will probably whip up a quick Vector2D class (if I was using DirectX, I could just use the one that is built in). I will move all location/velocity values over to be Vector2D rather than PointF (I'm really getting tired of this ".X"/".Y" crap everywhere rather than using simple Vector-based math). Once I get that in place, I might go ahead and add a "slowdown" feature of controlling the ship where it will slow down after you let up the key rather than stopping right away.
My hope is that once I get some of these architectural issues settled, hooking up enemies, collision detection, scoring, etc. should be pretty easy. At least the technical aspect should be easy, there would still be the fun part of writing the AI :). So far, I'm making progress though.
My goal for tomorrow is to have the Messaging and Task subsystems hooked in and working by the end of the day. I would also like to get the GameObjectRepository hooked up and doing some rudimentary boundary checking (like destroying game objects (like bullets) when they leave the playing area). Once the GameObjectRepository is working, adding some easy collision detection (I probably won't do per-pixel at this time and will settle simply for bounding volume checking) shouldn't take that long.
Anyways, time for sleep :).
P.S. Minor Annoyance #2 with VCS Express - The limited debugging features. Visual Studio's debugging capabilities in the IDE seem much more robust (like forcing the code execution to a specific line (aka "going back in time")), etc.
Although I didn't give an update yesterday, I did get some work done. Even though I've had the last several days off of work, I'm sure Chris would feel more comfortable knowing that I haven't been spending my entire days working on Spaceballs (I have a feeling that Chris would only feel truly comfortable if I dropped out of the competition since he knows he's fighting a losing battle).
My spaceship is all hooked up and working. It drives off the mouse and can rotate both directions just fine. I just finished hooking up the bullets. Now you can hit the spacebar to fire and the bullet will fly in whatever direction the ship is/was facing.
To limit the sheer number of bullets (and to add another game mechanic), I went ahead and added a firing rate to the ship (or, more specifically, the weapon). If I have the time to implement three different ships like I want to, each one will have a different firing rate to differentiate the behavior and strategies for each different ship type.
Before I move on to hooking up an enemy and getting collision detection working, I need to do some cleanup refactoring. I also need to do some "bulking up" of my infrastructure to make sure that the game continues to be easy to develop.
After I had removed it earlier, I'm thinking of re-introducing the messaging system since I don't like how coupled my various classes are getting. I'm holding off on that now though as I really don't want to push it too far if it isn't necessary. I figure that I'll actually just continue to push forward and if my coupling becomes worse, then I will revisit the topic. There might be other ways though that I can manage the dependencies and coupling without introducing an entire message system. I'll have to do some more thinking on that.
Well, I'm back off to coding. I'll try to get in another update before I go to bed tonight (hence the "Part 1" in the title :)). I'll feel a lot better about the progress in the game once I get an enemy and collision detection hooked up. I know it's only Day 6, but once an enemy and collision detection is hooked up, I'll be a heck of a lot closer to having an entire tracer bullet hooked up.
Yay for GDI+ :). To create a rudimentary Sprite class (and we are talking *rudimentary* here) and hook in Rotation using a Matrix Transformation took less than 45 minutes (and most of that was cleanup refactoring and moving files around in SVN).
Now I'm very glad I dropped SDL.NET like a bad habit and moved over to GDI+. If you are doing 2d game programming in .NET, I do think that you might as well go the GDI+ route and just forget about SDL.NET (at least for the graphics). With all the powerful code and classes in the .NET Framework (and how ironed out that code has become), you will be experience a lot less frustration, *trust me*.
I look at yesterday's update and I kind of have to laugh. No wonder Chris thought I was crazy :). After my change in direction, I myself am starting to realize just how easy this is (granted, it is just GDI+ and is no Gears of War :)).
If I could offer one piece of advice to any budding hobbyist developers out there, it would be to not put the cart in front of the horse. Don't try to do your first game directly against DirectX. While it is certainly possible, I think you would only cause your self grief in the long run. Now that there are great higher-level libraries at our disposal, there is no excuse to use them while you are just getting started in game programming.
I'm only glad that I came to this realization/decision now instead of 30 days from now.
Oh, and if you _are_ a new guy on the scene of game development and are curious about all this GDI+ stuff I am talking about, I _strongly_ encourage you to look at the games you can find on Coding4Fun as part of the UpgradeYourGame Sweepstakes (basically Pong, Space Invaders, and a small RPG). And while you're at it, drop Andy "ZBuffer" Dunn a quick thank you over at The ZBuffer for the work he did putting those together.
Well, SDL.NET is completely ripped out. Spaceballs is running entirely on GDI+. Believe it or not, I ended up ripping out the entire Messaging system as well. I'm not entirely sure that it is really even needed for this game. In fact, I think it probably _is_ quite overkill.
It's funny, I always get a tingle when ripping out a bunch of code and making the code a lot simpler. I'm still happy as the components are pretty isolated and are still enabled to be unit tested fairly easily.
I think that tomorrow I will crank out a quick and dirty Sprite class built directly on a Bitmap and use that for rendering. I only hope that the rotation capabilities of that or significantly better than that of SDL.NET. Once the Sprite class is built, I will hook up the ship into my PlayController. After that, on to one small enemy :).
As for Visual C# Express, I have noticed a couple of things. For one, I wish there were more refactorings than Rename and ExtractMethod. Also, I do wish they would have kept the add-in capabilities enabled. While Jamie Cansdale has done a wonderful job getting TestDriven.NET to work, I have had no end of trouble trying to get "Test With... Debugger" working. Arg!!! It's frustrating enough that I do wish I was in Visual Studio. But that may also be because I like to have my unit tests, darn it :).
At least after all of this I am only a single day behind schedule. Hopefully I don't run into this again. One thing I have noticed after todays efforts? I'm pleasantly surprised to see how easy GDI+ programming is.
As much as I feel ashamed to admit it, I've _never_ written a C# game using GDI+. I've always jumped to Managed DirectX (or some pre-packaged library like Irrlicht) and only gotten a fraction into the game development process. I'm starting to get the impression that now that I've chosen GDI+, this whole process should go a bit smoother. My other hope is that this will ultimately make the code a lot more accessible to others out there as a lot of the necessary support architecture that one has to put in place with Managed DirectX is not there.
I'm glad that at this point I'm still having fun. We'll see if that's still true in a week :).
|