If everything else fails, bake it in the oven

Three weeks ago, our laptop died. It’s an old Dell Inspiron 1501 we bought in 2007. Typically you’d just get a new one, recover the data from the old one, and be done with it. Thing is, while searching for a possible cause (and remedy), on one of the links Google returned, a bunch of people talked about doing a solder reflow in their ovens. If this sounds strange, just read the following:

http://russell.heistuman.com/2010/04/27/cooking-the-books-or-baking-my-macbook-pro-logic-board/

So the recipe involves removing anything that is not heat resistant (sponges, rubber parts, the battery and so on), leaving the board in question with just the connectors. You then wrap up in aluminum foil the parts of the PCB that holds the more sensitive components, put it on top of a few balls made of the same aluminum foil in a tray, and bake it for 7-8 minutes at 200 degrees Celsius (485 Fahrenheit I think).

Now, the reason why this works (and it worked also for me) is that at 200 degrees the soldering metal becomes liquid again, and fixes the soldering that went bad. This goes for pretty much any PCB with SMD components that tend to heat up – motherboards with the graphics chipset on them, video cards, you name it.

Question is, why does a soldering go bad?

The typical answer is that the graphics chipset heats up a lot, and in case of poor ventilation (like when using the laptop on a soft surface) the temperatures go high enough to break some of the soldering. This is aggravated by the fact that PCBs end up with some mechanical stress in them, so as soon as the solder goes liquid, there’s a good chance that the PCB will try to go back to its original shape – at the expense of the soldered components, which might end up with some terminals loose.

So, there you go … if everything else fails, just stick it in the oven for 8 minutes, at 200 degrees Celsius.

Advertisements

Ib – Play it!

If you haven’t played it, do that:

http://vgboy.dabomstew.com/other/ib.htm

It’s this kind of game that points out to me that gameplay beats graphics. In this case, even with the pixelated sprites the game uses, it still manages to be fun, creepy and a bit addictive.

Image

Everybody labels it as a horror adventure game; I feel it’s actually the other way around: it’s an adventure game with creepy-borderline-horror-ish elements. The core of the game is solving puzzles (and there are some good ones in it), exploring the area and just avoiding enemies, in order to find your way home.

It’s hard to pinpoint what makes the game good; the music is nice and suits the creepy-art-gallery settings the game takes place in, the puzzles are ok-ish to good and the premise of the game is interesting albeit a bit disturbing.

While not being THE reason why I enjoyed this game, I liked that the author didn’t use too many jump scares; one of them in particular is actually required so that Ib can return and obtain the blue rose. So, a very judicious and conservative use of jump scares – thumbs up from me.

I am now tempted to re-play it to get the other endings …

When would one need a database

If your app needs to store data, you’re facing the following options:

  • use a database
  • use a simple file (ini, xml, whatever)

Now, choosing the wrong one can lead into serious issues, especially when it comes to expanding the storage mechanism.

Data dimensionsSo, one thing I noticed is that if the data that needs to be stored varies in quantity by a large margin (typically it is customer generated), then it is likely it will also vary in complexity.

Let’s take two examples.

The first one is the settings stored by an application. In most cases, the settings have a reduced complexity, and usually a fixed quantity. In case of a simple text editor, you would save the default encoding type, the last opened file and the last folder used to save files. The amount of data won’t change too much, and the structure will remain simple.

In the second case, the data we’re storing is data generated by the customer. Let’s say, we’re making a photo library software. In version one, we’re just saving the file paths of the pictures and their associated category (like “lolcat pics”, “wallpapers”, “pics from vacations”). Our customer already introduced 200 pictures, and has plans to add 500 more. But now he also wants to save the date when he last viewed each picture.

Oops.

If you were to use a plain file to store the data, now you’d have a pretty serious issue: you can’t easily upgrade a simple file storage model to accommodate increased complexity. And things like this do happen. I mean if the app stores customer generated data, your storage data model needs to be flexible not only in quantity (simple files can cover this) but also in complexity. Because customers will push for changes in terms of what data are they allowed to save. And if you don’t provide the means for them to do that, they’ll just use another app.

A better one.

 

 

Valve is about to get an Epic ass whooping …

I appologise to Valve’s fanboys for the offensive nature of the title. I know it hurts, but that’s how the latest news felt like:

Steamworks now integrated into UDK

I can already hear you shouting: “But that means that actually Valve bitch-slapped Epic, not the other way around!”. Easy there! Although not a Valve fanboy, I like plenty of things from this company to be on your side on this one.

But, what if I am to tell you that development teams think about shifting from the Source Engine to UDK? Or the fact that Valve still didn’t match the offer made by both UDK or Unity?

It all started one year ago, in 2009. Unity released its engine for free. It was good news, despite the fact that the free version of Unity has some limitations (of which, by the way, some are actually plain stupid).

Then Epic did something … epic. It released it’s runtime at a very cheap price for indies. Don’t get me wrong, Epic did that before with UT2k4’s runtime. What made things different this time is that the Unreal guys allowed people to make and sell games based on the UT3 runtime that we now know as UDK. That’s the epic part right there!

Other than that, both companies have similar offers: binaries-only access, low (99 USD in case uf UDK) or inexistent (in case of Unity) prices, tools, examples …

So, when I saw that Epic, a company that once said it’s shifting focus from PC towards consoles, is now following the footsteps of Unity, I told myself: “Wait until Valve sees this! I bet they’ll release their Source engine (the non Orange Box thinggie) immediately!”.

So I waited … and waited … and waited … insert crickets noise here … and waited.

And nothing happened.

No, I’m lying, something did happen: UDK incorporated Steam.

You’ll shout out once more: “But Valve will be making money out of this!”

And I shout back: “That’s small potatoes!”. Here’s why Epic gained (and still gains) from this “let everyone use our engine” approach:

  1. Some money. Again, this is small potatoes. In order for this to matter, the next BIG thing on PC gamming MUST come from indies. I don’t see this happening any time soon.
  2. Fame. This matters more, actually, because the hidden message here is “our engine is so neat everyone can use it”. Plus, it puts Epic back in the eyes of the indie-wannabe modders. And this matters because Epic will ultimately gain something much more important than the above two:
  3. Developers.
    I’ll spend a bit of time explaining why this is important:A game lives for as long as the community built arround it keeps playing the game.Same goes for frameworks (game engines in our case): it lives as long as people develop applications (here games) for that said framework. There is a reason why Steve Ballmer kept shouting “Developers, developers, developers”:

    Having developers on your platform means that cool applications will appear for it and people will buy them AND the platform.

    And another insiduous effect is that a good deal of the gamming development workforce out there will be competent in Unreal. So their future employers will feel a stonger push to use Unreal in their products.

So you see, Epic is playing for the long term, trying to get their hands on the best asset out there, the development teams.

If for one second you belive that there are no teams switching from Source to UDK, well, think again:

http://www.moddb.com/mods/age-of-chivalry – a Source based mod, released in 2007

http://www.moddb.com/games/chivalry-battle-for-agatha – an UDK powered game

And it’s the same team. They once worked on a mod for source. Now they’re making their game for UDK. Apparently, moving the art assets from one engine to another is fairly simple, if you still have the original, engine-independent, files. Coding can be done in a reasonable ammount of time, especially since the Unreal community doesn’t seem to lack coders.

As for UDK using steam? Well, that’s just another feature that makes UDK attractive. The irony here is that they’re using a Valve product to acheive that.

Gabe, I know you’re not dumb. And you know that I have nothing against your company. I love how you make sure that ownership of the game is not limitted to a platform. I keep using Steam as a perfect example of a good DRM.

But you should look int this thing man. We know Source is not that straight forward to use, but people are willing to go pass that. All they want is an opportunity. Give them that opportunity, especially since your company always had a great modding community.

Otherwise, when the “game as a service” concept comes to fruition, you might not have enough developers behind it to keep it alive.

Be a developer, don’t turn into a publisher that sometimes develops games

Unity is like COM. But what is COM like?

Before staring this blog, I wrote one article regarding Unity, CATIA and the COM model. While it did show up some similarities between the three, it didn’t quite explain the whole idea behind COM’s object modeler. I mean I talk about interfaces, about components and lots of technical stuff that only show how similar he three are, but if a noob reads that article, I’m pretty sure he/she wouldn’t understand too much.

Well, this article tries to set things right.

The analogy I’m going to use has absolutely no connection to programming. You won’t hear words as “components”, “objects”. Instead, prepare yourself to enter the world of … refrigerators!
So, on our left we have our generic refrigerator. The only functionality this lump of plastic and metal has is that it keeps food cold. If you think of it, this is the primary function of the fridge.
Now, let’s assume you’re one of those people that love fridge magnets. But not these kind of fridge magnets! No. You’re a programmer trying to learn COM, so, obviously, you’re interested in fridge magnets that add value to your beloved fridge.
Let’s say that one day you find an obsure shop that sells weird magnets. You go in, looking for something … different. And there it is: The perfect fridge magnet! An LCD clock!
Now, as a smart programmer that you are, you simply put two and two together:

And it doesn’t have to stop there! You have a cheap pocket calculator? Glue a magnet on it’s back and voila! Your fridge gets another new functionality: it can now calculate stuff! And how about a barometer? That will turn your fridge into an indoor weather station. Not like the weather inside will actually change, but who cares? What matters now is that from a generic fridge you now have a super-multi-functional fridge. And you did that just by sticking extra gadgets to it!

Now, back to Unity and COM.

In terms of object modeling, that’s how COM works. Same for Unity.
In the image on our left, we have the FPS controller, that comes with Unity’s Island demo. I underlined for you two of the components that add functionality to our object:

  • FPS Walker – responsible for actually moving the player when the WASD keys are pressed. Also handles jumping.
  • Mouse Look – responsible for rotating the camera

Well, in our case, the fridge is the FPS Controller prefab. As for the fridge magnets, well, you’ve guessed it: they’re the FPS Walker and the Mouse Look scripts. And just like our fridge magnets, they’re adding new functionality to our prefab. And just like fridge magnets can be sticked to any metal surface (well, feromagnetic surfaces, if you’re a science maniac), Unity scripts can be associated to other componets as well. For example, you’ll notice that the Mouse Look script is also used on the Main Camera game object.

And this is another advantage of using a COM-like approach in Unity: you can re-use scripts. All you need to do is to drag them from the resource tree onto your object.

The only thing the fridge magnets (let’s call them components from now on) have in common is the fridge. In our case, the FPS Walker script and the Mouse Look share the object that owns them, the FPS Controller prefab. Now, this has an interesting effect, and I’ll give more details.

In the moddb article I mentioned before I’m talking also about GetComponent(). Now, the cool thing is that if I try to access the MouseLook component from the FPSWalker code:

MouseLook mouseLookInstance = gameObject.GetComponent<MouseLook>();

the GetComponent() function will return me the MouseLook instance that is associated to the same FPS Controller prefab that also owns the FPSWalker! And that’s quite allright, because we’re asking the game object to give us the MouseLook component.

Having a headache? That’s ok, a new way to create objects is a tough lesson. Still, what you should remember is that (1) you can stick existing (or new) functionality to a Unity game object by simply dragging a component (a script) to your object and (2) for a given game object, you can easily access all its components, by calling GetComponent().