Spent most of today researching various topics. These two google IO presentations by Chris Pruett were great to start processing general ideas. I’ll probably spend the rest of the evening and tomorrow looking at the source to a few example games to get a better feel for the direction I want to go technically.
Last week, or maybe early this week a friend linked the google AI challenge. This re-energized my programming curiosity in a way that meshed well with the fact that my wife recently purchased a Droid 2. So I’ve been playing around with Elcipse, Java and the Android SDK for the last week or so. Eclipse is a bit of a beast, but I knew that going in. This is the first time I’ve given the Android platform any attention, and I’m glad I did.
So back to the AI Challenge… that lead me to Phil Hassey’s blog… which lead me to this Ludum Dare challenge. It’s simple really. Make a game, take it to market and sell a copy. Do it by the end of October. I’ve always been interested in what it would take to break out of the daily grind of business app development and try out some game dev. I’m certainly out of my general comfort zone. On the other hand, code is code.
So I’m going to hold myself to the challenge. Hopefully making a publicly accessible spectacle out of it will keep me on task for fear of shame and humiliation if I don’t finish. I kind of like the idea of blogging about the process, since I’ll basically be starting from zero practical experience with game development. Hopefully it’ll be informative and help me organize some ideas. I’m sure the game won’t have a lot of commercial viability, but it should be a good place to get my feet wet and have some fun.
I started tonight with a bit of general design and planning. I’ve got an idea, it’s going to be a game targeted towards younger kids. Not so much Baby Smash young… about the age where they ask you to play with your phone while you’re driving. It will be a 2D side scroller type game. That should keep the graphics intensity minimal. I’m pretty worried about the graphics aspect of this project because I’m not much of an artist.
Despite being mostly comfortable in a Microsoft stack (and partly because of it) I’ve decided to target Android phones. To start with, while I’ve not really done any appreciable Java development or extensive work with Eclipse, it’s not too large a departure from what I’m use to. iPhone is out because I’m just not as comfortable in the XCode/Objective-C paradigm. Given the timeframe, that’s a lot to grep. Additionally, I really don’t feel like shelling out $99 to get my foot in the door at the app store. I wouldn’t really expect to make it back.
Here’s my current list of technical hurdles:
Going to need a lot more familiarity with the Android SDK. Specifically
Entity Framework has haunted me from some time. The initial release suffered from no lack of mockery from the web as a whole. Rightfully so. I was always in the camp that liked LINQ to SQL pretty well, and I was sad to see it go. But like every ORM type framework out there both EF and LINQ had their advantages and disadvantages. I even spent a little time with NHibernate (via Fluent NHibernate) and found that to occupy the same space. On the outset it seemed like the greatest thing… upon further investigation it became less than its initial impression.
That said, I didn’t set out to create a rant here. The frustrations I’ve experienced all came together the other day as I was trying to wrap my head around some issues I was having with EF4. Specifically, attempting to come up with a good solution for dealing with the scope of EF contexts in a WPF client application. At the same time I was worrying about that bit of the overall solution architecture I ran into the bug in my previous post. It so happens it was just enough added stress to start the reaction and cause a juvenile rant.
The Guid issue was, is course, a simple workaround (but it still irks me). After a couple days of reflection and a couple trials I’m pretty comfortable with my solution to the context scope as well. In fact, the solution to that made me realize one of the big disconnects I’ve been having with ORMs in general. I realized I’ve been interacting with ORMs (EF in particular) in largely the same manner as I have every other data retrieval framework and api for years. That’s kind of an embarrassing thing to admit. Regardless, here I am and it’s just now that the light bulb tuned on.
In essence, I’ve been treating EF more or less like a set of utility functions. I’m not sure I can easily explain it off the cuff, nor do I really feel like writing it all down tonight. I’ve got a few other things on my mind. So I’m going to try and sum it up in a couple sentences.
I started treating ObjectContexts as if they were the database itself, not just a set of helpers that get me out of writing simple sql statements. It’s just like another file. It seems stupidly simple, I know, and I’m probably the last guy on the planet to grasp that. It is pretty apparently when you’re watching one of the canned demos that some MS shill is doing, on some sample app that you know will never approximate something that would be useful in the real world. Not always so when you’re digging into something concreted (or looking at a Ria services demo).
Your ObjectContext is your database. Treat it carefully and be concerned about accessing it consistently. Now go be productive.
I’m going about my business in EF4 today, generally making progress. Then I run into this. If this product wasn’t plagued with so many issues for so long I might be more accepting… but I’m so tired of having to do so much extra work because the EF team doesn’t have some form of adequate testing, development resources, scheduling, PM… whatever it is. Man, this is such a bummer. I know this is probably an unfair rant, maybe it’s an edge case that the majority of users don’t deal with, but honestly I’ve suffered more at the hands of Entity Framework than any single Microsoft technology since I started developing. I’m really ready to move on.
Over the past couple weeks I’ve been working on a newer WPF application that is using the MVVM Light Toolkit and thus the MVVM pattern. Like everything in this field, there are some great attributes of the pattern and some that are not so great. But all in all the MVVM Light Toolkit has some great resources to help you get along. I would really recommend taking a look, Laurent Bunion has done a really nice job of putting together a framework that is pretty easy to use and understand.
The only real hang-up I’ve had thus far is in displaying modal windows and dialogs. After some searching there are a couple good posts in the discussion forums about how to use the messaging framework (which I’ll admit, I’m no expert at) to display dialogs in a MVVM friendly way.
After reading through his sample app it all made sense, but what I really wanted was an example of displaying a modal window where some work was done, and information was then passed back to the main ViewModel after the modal was closed. I put together a quick example of one way to do this. Hopefully it’ll be useful to you if you’re in the same boat. Here’s the code.
At the center of the example is the ModalMessage<TViewModel> class. The idea is to use this in your main window to define your message that sends a ViewModel to the recipient.
[csharp]Messenger.Default.Register<ModalMessage<ModalWindowViewModel>>(
this,
msg =>
{
var dialog = new ModalWindow(msg.ViewModel);
var result = dialog.ShowDialog();
msg.Callback(result ?? false, msg.ViewModel);
});[/csharp]
The recipient (the modal window) then uses this ViewModel to present data, and ultimately send the object back via the msg.Callback() method.
While the message is registered in the main window codebehind, the whole process is kicked off, and the results received in the MainViewModel class.
[csharp]private void ShowDialog()
{
var vm = new ModalWindowViewModel()
{
DisplayText = "Please send a response!"
};
var message = new ModalMessage<ModalWindowViewModel>(vm, ShowDialogCallback);
Messenger.Default.Send(message);
}
private void ShowDialogCallback(bool confirmed, ModalWindowViewModel returnedVm)
{
if (confirmed)
{
this.Welcome = returnedVm.Response;
}
}[/csharp]
This is a pretty interesting video by the CTO of DevExpress, Julian Bucknall. It’s titled “What Pac-Man can tell us about Object-Oriented Programming“, but the core lesson here has nothing to do with Object-Oriented programming at all. More to the point, it’s a great story about solving a problem in a very different way than what you might be accustom or trained to.
Review your code from time to time. Look back at something you wrote that was particularly prickly. Is there a more innovative way? This kind of challenge is the sort of thing that really keeps me interested in development, and I don’t do it nearly enough. It’s always fascinating to hear these stories too…
While this is just a promotional video “Ubuntu Boot Promo”), I’m pretty sure if Ubuntu booted up with that splash screen I’d have to switch full time and return to the days when I completely shut down my machine every night.
I’ve been keeping track of a large number of notes and links lately in a very low tech way – a simple text file that lives in my dropbox folder. Mostly interesting article links that I want to get back to reviewing in detail or just general refreshers/ideas/todos. Mainly the types of things that are too fragmented and small to make it into my moleskin notebook, but things I want to keep track of regardless. The list keeps growing faster than I can address the items on it. Sound familiar? At any rate, it’s finally grown to the point where a little more organization is required.
Tonight I just happened to run across this great little wiki, tidlly wiki, which seems to be exactly the right fit. It’s entirely html/javascript and saves to itself when you open it via a file url in your browser, so it fits seamlessly into my current dropbox-share workflow. Plus, it has all the basic organizational capabilities of a basic wiki to allow me to bring some order to the chaos. It’s exactly what I was looking for. Thank you, intertubes.
I’ve decided to increase the general nerd factor of my life equation by re-kindling an old hobby I use to enjoy with dad, flying RC Aircraft. For starters I just wanted something quick and easy to get going and start practicing again. After a little research I decided the Electrify Lancair ES EP would be my guinea pig. I should probably apologize to this little model kit in the event that I do something stupid and ruin it on it’s maiden voyage.
The kit comes with pretty much everything you need, minus some important things you can’t fly it without. One of those items is a 12v DC power source for the included NiMH power pack charger. Rather than spend extra money on a dedicated battery/AC converter or just plain opening up the car hood and hooking it up this seems like a great opportunity to re-use one of the old PSUs that I still have lying around. Fortunately the web comes pre-packaged with useful information on the subject. If you’ve ever tinkered with the insides of your computer (and I know you have) you’ll know the PSU doesn’t generally stay on unless it’s hooked into some fashion of motherboard. So I was particularly interested in knowing about the inner workings of this mechanism. I came across this interesting video that explains not just the wiring itself, but the mechanism behind the familiar click when you hit the the power switch.
There are various other tutorials on actually doing the wiring, all relatively basic and strikingly similar. This article on wikiHow seems to be the granddaddy of them all.
I was listening to Hanselminutes 238 this evening where they discuss building the 2010 version of Ultimate Developer Machine in search of a Wei score of 7.9. I’m a big fan of the podcast, and as always this episode was a good listen.
During the podcast they reference the WEI Share project, which is devoted to letting users share their Windows Experience Index scores and with the web. The WEI Share site is a nice little silverlight app that lives in the Azure cloud. It displays the uploaded information and the advanced search lets you retrieve results on specific pieces of hardware. It seems like a great resource for anyone looking to upgrade their hardware situation. While the WEI index probably isn’t the only metric you’d want to look at, it’s another data point to consider if you’re looking to upgrade, or just plain interested in knowing how your hardware stacks ups.
I was hoping to take a look at the source, but the WEIShareSL projcet depend on a Blend assembly and won’t open. Oh well, not enough time to dig in now, but something to look into in the near future.