Tutoriais

Nick Hodges, da Embarcadeiro começou uma série de tutoriais sobre Delphi Development Pretty Good Practices. O seu último se refere a “Source Control”, um recurso que nenhum desenvolvedor deveria viver sem. Se você acha que não precisa ou que não teria vantagem em utilizar (mesmo sendo um desenvolver sozinho), você se engana muito! Leia o artigo abaixo e mude sua opinião!

Delphi Development Pretty Good Practices #2 – Source Control

Okay, so for this first installment, I’ll be illustrating one of my core principles for developing applications:  All my code of any importance at all goes under source control.  All of it.

I’m all by myself – why should I use source control?

We ask about source control use on the annual survey, and a surprisingly large percentage of you are not using source control at all. That as a bit of a surprise.  If you are working on a team of any size, using source control is a no brainer.  But even if you are working alone, using source control is a really good idea.

Why, you might ask?  Well, there are a number of good reasons:

1. It’s good to be in the habit. Sure, you may be working alone.  But in the future you may not be.  Or your “weekend hobby project” might turn into a popular project with many developers.  If anything like that happens, being in the habit of using source code control will stand you in good stead.
2. It protects your code. Since your code is stored in on a server apart from your development machine, you have a backup. And then, you can even backup the code on the server.  Sure, you can zip it all up any time you want, but you don’t get all the other benefits I’m listing here.
3. It can save your butt. Sometimes, you might accidently delete something.  You might make mistakes and change code that you didn’t want changed.  You might start off on some crazy idea when you are feeling a bit saucy, and then regret it.  Source control can save you from all of these by making it a piece of cake to revert to any previous state.  It’s like a really powerful “undo” feature.
4. It allows you to “turn back time”. Say you are a shareware author. You like to release updates and new versions.  And say you get a support request from a customer that has a bug while using a version that is two major releases old. Source control lets you easily recreate the code base for that exact release and debug the problem that the user is seeing. Mais >

List of game design tips for narrative games by Jordan Mechner (Prince of Persia Creator).

Tips for game designers

Eons ago, in 1996, Next Generation magazine asked me for a list of game design tips for narrative games. Here’s what I gave them.

Reading it today, some of it feels dated (like the way I refer to the player throughout as “he”), but a lot is as relevant as ever. I especially like #8 and #9.

1. The story is what the player does, not what he watches.
2. List the actions the player actually performs in the game and take a cold hard look at it. Does it sound like fun? (Resist the temptation to embellish. If a cinematic shows the player’s character sneak into a compound, clobber a guard and put on his uniform, the player’s action is “Watch cinematic.” Letting the player click to clobber the guard isn’t much better.)
3. The only significant actions are those that affect the player’s ability to perform future actions. Everything else is bells and whistles.
4. Design a clear and simple interface. The primary task of the interface is to present the player with a choice of the available actions at each moment and to provide instant feedback when the player makes a choice.
5. The player needs a goal at all times, even if it’s a mistaken one. If there’s nothing specific he wishes to accomplish, he will soon get bored, even if the game is rich with graphics and sound. Mais >