meh, use git, not mercurial, even on Windows. I used mercurial for 9 months first, loved it. Switched to git. Loved it more. There's a steeper learning curve with git but it's better than hg. When you decide to start git, read at least the first chapter of Pro Git(http://progit.org/book/) as it will explain some major difference between git and other VCS like git's stage for example.

I gotta add, don't do it yourself. I have no idea what you want to do, leaderboards maybe? but if you do it yourself and your server can't handle your traffic it will be a lot of work for you to deal with. Google App Engine will handle that for you. Don't know about other systems but I assume you really don't want to be the one running the servers, making them secure, adding more if what you have is not enough, backing up, etc etc etc...

Just remember, you have an entire browser to render text for you. If you are not porting something then consider using HTML for your text if it fits your needs. The browser will composite your HTML and it will only re-render it when you change something.

I haven't printed cards and I don't know how TGC operates but I have worked with Lulu and it sucked. Basically Lulu is just a middle man, they contract out all the printing to lots of different companies. That means no 2 prints will ever come out the same. It means sometimes something that printed before will not print the next time because it went to a different printing company with different equipment and different bugs. I don't know if TGC has the same problem.

It would be nice if the games market was more like the wine market but it's kind of hard to compare them directly given that wine is a consumable. 1 bottle is what, 4 glasses? 6? 8 at most. That means if you're a wine drinker you're generally going to go through several bottles a week. How many games do you go through a week? If people played as many games as they bought bottles of wine I would guess there would be a lot more artisanal games.

Looks like L.A. Noire might solve the eye problem http://www.rockstargames.com/lanoire/

Yes, what Brinstar said, apparently this was all taken out of context. The book is about how she started with the Tiger Mother method until her daughter massively rebelled in her early teens to the point Mrs Chua realized the Tiger Mother method, or at least her version of it, wasn't working. To some extent I come at it from the other side. My parents didn't push me at all. They knew nothing about college, didn't seem to care if I went or not. Of course they loved me and supported my hobby by buying me a computer but college was just not part of their world so the idea that I should strive to be the best and try to get into the best colleges just never came up. When I see my friends that did have parents that did push them I'm a little jealous. I kind of wish I had gone to Harvard, MIT, Caltech, Berkeley, Stanford etc. Of course I'm sure I'm filtering only to my the friends and people I look up to and ignoring the ones I don't.

I think this is only possible because of XBLA, PSN, WiiWare, iPhone. In other words, DRMed not resellable, non rentable games. The reason people didn't make short in the past is because they'd be rented to death and because there was no easy way to sell a $1 to $15 game. Now there is.

I had a similar problem. I got a brand new Dell with Vista, put it into my home network and spent the next week trying to figure out why I couldn't share it. In my case turned out it was some registry setting. The funny thing is, according the docs I found, it was NOT set to the default. Who changed it from the default, Dell or MS, I don't know but setting it to the default made my sharing work. Of course stupid me, I have no idea what that setting was and lost the link to the page :-(

The ServiceLocator thing sounds complex but in actual use it's a joy and not complex at all. It's not even complex to implement if you look at the code. It's rather short and elegant. I was skeptical myself before I was exposed to it. Before we basically had gApp and one way or another almost every module would eventually need access to something in gApp. Then it was broken into services and now each module only needs access to the services it uses. Usually that's about 1/10th to 1/15th of what used to be in gApp. It's helped not only with globals but also with dependencies so that changing one service means only modules that use that service get effected or recompiled. Before, since all the stuff was combined in gApp that meant changing almost anything ended up recompiling everything since gApp both included a ton of stuff and a ton of stuff included gApp.

Grr, your blog ate all my less than signs. The GetService lines should look like serviceLocator->GetService<IRenderer>();

Oh, btw, because of this ServiceLocator we don't have any Singletons. The advantage to this is for example in a unit test, like I mentioned before we do have a global service locator with a few services on it that lots of tests need so those tests will do something like Renderer* renderer = g_serviceLocator->GetService(); But, even with the global service locator, in many tests we can create another service locator, add some services do it and the tests in that unit will use that one as in // Create a new service locator ServiceLocator localServiceLocator; // Add a service to our local service locator. MockRendererer mockRenderer<&localServiceLocator>; // Call some test with our local serivce locator. DoTest(&localServiceLocator); ... void DoTest(ServiceLocator* serviceLocator) { Renderer* renderer = serviceLocator->GetService(); ... // Do something with the renderer. } Since DoTest takes a pointer to a SerivceLocator we can hand it the global one or one with our MockRenderer and it will find the one we want it to find. I wish I could point you to more easy to follow examples but our code is open source if you want to browse http://src.chromium.org/viewvc/chrome/trunk/src/o3d/core/cross/?dir_pagestart=150 service_locator.h is the class to find services. service_implementation.h defines a class you put in another class if you want that class to be a Service. service_dependency.h is a class that helps deal with to services that are dependent on each other. Otherwise, features.h, renderer.h, object_manager.h, class_manager.h, error_manager.h, event_manager.h and others are all examples of services. Those and about 10 others all used to be in client.h If you want instructions on how to build see http://o3d.googlecode.com Otherwise, this pattern is apparently also called Dependency Injection but I don't know any good articles on it. The one on wikipedia is way to abstract.

I used to believe like Jamie but on my latest project someone introduced me to the Service Locator pattern and it's been pretty awesome. No globals, much less dependencies, easy to test things in isolation. Originally we effectively had this App class that had a ton of dependencies and almost everything depended on it. Now we have 10-12 mini classes separated by responsibility. Most of them depend on almost nothing and each higher level thing in our app only needs to include the small interface class headers for the particular services they need. The only thing that has to be passed around is a pointer to the ServiceLocator or that can be the only global (as it is in our unit_tests).

I'm not even sure we that I'm talking about the same thing because my experience seems mostly totally backward to yours. It always feels (I guess I can't prove it) that speed increases in the majority of projects I've been on. The team gets used to the tools. The designers understand what works and aren't experimenting anymore. The artists know what they can and can't make. Everyone has gotten used to the system. All that stuff that was taking forever because no hard decisions had been made are now over and people are just churning out massive amounts of content and finishing up features. I don't really see how it could be otherwise but then maybe it's a difference of perception. My perception is each month, the number of things getting done accelerates. I'm pretty sure that is objectively true for pretty much every project I've been on. On the other hand, maybe it's a different approach. You mentioned feature creep. My experience is feature creep increases up to the first 1/2 of the project and then quickly decreases on the last 1/2 including cutting planned features there is no time for.