I'm going to warn all of you out there now: I'm about to break down the walls and get honest about some of my feelings. If all you want to hear about are unicorns, pretty pink bunnies, and how cuddly-wuddly the whole world is, I encourage you to leave now. No group hugs here. No kumbaiya here. No other camp songs either, for that matter. With that said, let's now move on to the real "schtuff", shall we?
I would like to talk a little bit about the decision to rename WinFX to .NET Framework 3.0. Do I agree with the re-branding of WinFX to .NET Framework? Absolutely. I believe it does communicate the fact that the various WinFX technologies are a _part_ of the Framework now and it will lead to less confusion in the long run. It is now clear that the various WinFX technologies are part of the core platform and, in my mind, that is "A Good Thing."
So, if I am behind the re-branding, what is my problem? Well, my problem is three simple syllables: "three point oh". I can see more confusion being caused by using the 3.0 label for this "version" of the framework in the long run. What does .NET Framework 3.0 have to do with C# 3.0 or the 3.0 runtime? Nothing. What version of the runtime is packaged with .NET Framework 3.0? 2.0. Are there any breaking changes between .NET Framework 2.0 and 3.0? Nope. Why? Because the .NET Framework 3.0 uses the 2.0 runtime. Huh? You mean there's no breaking changes even with the major rev of the Framework? No, because they are the same runtime under the hood.
For me, it is slightly reminiscent of the naming mess Sun is in with Java. After all, you have J2EE (Java2) 5.0 (which actually uses version 1.5 of the Java language). It's disappointing as Microsoft had done relatively with with 1.0, 1.1, and 2.0. So, what are the other options?
One option is .NET Framework 2.1. To me, this option is only slightly better than 3.0. True, people won't think of breaking changes taking place. However, this still suffers from the fact that the Framework version is different than the runtime version (and hence, leading to some of the same confusion). Cross this off the list.
Another option is .NET Framework 2.0, Service Pack 1. With this option, the framework version is the same as the runtime version, so that confusion is alleviated. With a "Service Pack", it is not clear that there are a bunch of new features with it though. At least, not by definition it's not. However, isn't this what Microsoft basically did Windows XP, Service Pack 2? I still think there would problems convincing marketing to go with this title as I think it would be more difficult to "sell" this to customers. I'm not in marketing though, so I could be way off on this one :). This is probably the one that I like out of the other options (including ones that other people have posted about).
So what will I personally do about this? I guess I'll just sit back and accept it (with a frown). Overall, I believe it is perhaps the lesser of all evils once the decision was made to integrate it into the .NET Framework "product". At times like this, there is one word that comes to mind: Unfortunate!
Disclaimer: as usual, this is just one man's opinion and yours might differ.
I was asked recently what excited me most about the various Vista technologies. While I took a valiant stab at limiting my answer down to a handful of them, the proper answer with the way I feel would have been "what _doesn't_ excite me about the various Vista technologies." Yes, I could get into the various aspects that excite me about Workflow Foundation, Presentation Foundation, and/or Communication Foundation. I will save that for a later blog post though. Save to say, I'm extremely stoked right now about doing some development with all the different Foundation technologies. I think I'm going to do some deep-diving into Workflow Foundation for a while though :).
So, after a hiatus for almost a year (has it really been that long?), I will be spending time again getting into the various Vista technologies that are coming our way. So stay tuned in the future for more Vista updates :).
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 :).
|