Zurzeit ist dieser Post auf Deutsch leider nicht verfügbar

It is a hard way to make the game you want without a big budget. There are a lot of steps like technical design document, game design document, programming skills, long time motivation. . . Each one of this tasks doesn’t only make the indies headache

Like we know, every project is based on time, money and quality. These are the next steps to conquer.

Despite everything, the are a lot of different solutions. We take it our way and call it “production drops”. The idea is to split one big project into many little projects ( I thing this is the point where everyone starts to laugh). But the clou of this idea is to finish all sub projects (production drop or PD) as a single project. That means, we put into every PD some key features of our big project. Each of this application is fin and can be thrown on the market.

This is our goal to be highly motivated over long time, because we make little project at a short time. In addition to this, we can test some big project features directly on the market without losing time and alter them for our aim. During this time we have all time we need for the documentation stuff. More over, it is possible to source out PDs on 3th party developers.

This workaround must be based on a very modular project library/source code. And that is the first logical step for the whole production. We are not sure how long it will take to work on this pipeline. But one thing is sure, the only parameter which will rise is time. Other problems like money and quality will be fixed by the production drops.

The first production drop will be released soon.

Bookmark It

Um den Umstieg von C++ oder Java auf ObjC (Objective-C) zu erleichtern, poste ich hier den meiner Meinung nach wichtigsten Unterschied.

Einer der Hauptunterschiede von ObjC (Objective-C) zu C++ und Java liegt in der Philosophie hinter dem Aufruf von Instanzfunktionen. Während man in C++ oder Java von einem Methodenaufruf eines Objektes spricht, ist es unter ObjC das verschicken einer Nachricht an das Objekt.

Bei einem Methodenaufruf unter C++ oder Java wird bereits vor dem Ausführen des Programms die Methode an das Objekt gebunden. Das heißt, die Methode des Objektes muss existieren, ansonsten gibt es einen Compilerfehler und ein Start des Programms ist unmöglich. Dieses frühe Binden hat den Vorteil fehlerhafte Methodenaufrufe zu vermeiden, ist jedoch sehr unflexibel.

Unter ObjC verschickt man Nachrichten an Objekte, was übrigens von Smalltalk stammt. Diese Nachrichten werden erst zur Laufzeit an das Objekt geschickt. Dadurch ist eine späte Bindung möglich. Die Nachrichten werden zur Laufzeit vom Objekt interpretiert und falls eine passende Funktion vorhanden ist, wird diese ausgeführt. Dies bedeutet dass der Compiler vor dem Start nicht überprüft ob das Objekt die aufgerufene Funktion besitzt. Spätes binden eines Funktionsaufrufs hat den Nachteil dass es fehlerhafte Funktionsaufrufe geben kann, jedoch den entscheidenden Vorteil der Flexibilität.

Dieses Beispiel sieht sehr simpel aus würde jedoch mit C++ oder Java nicht laufen:

implementation ClassOne
…
-(void)doSomeThing
{…}
@end

implementation ClassTwo
…
-(void)doSomeThing
{…}
@end

int main(…)
{
id *object = [[ClassOne alloc]init]; //id ist Typlos und steht für alle Typen von Objekten
[object doSomeThing]; //ruft die Methode von ClassOne
[object release];
object = [[ClassTwo alloc]init];
[object doSomeThing]; //ruft die Methode von ClassTwo
}

Bookmark It