Forum / Bits und Bytes / Spiele programmieren

Community

Szene & News

Parties

Fotos

Locations

Impressum

Forum / Bits und Bytes

Spiele programmieren

<<< zurück

-1- -2-

Flopchop

Champion (offline)

Dabei seit 01.2005
4707 Beiträge

Geschrieben am: 12.09.2006 um 12:17 Uhr

Zitat von bassmaster:

Zitat von matzelp:

mit 13 hat man mit sicherheit nicht das wissen ein vernünftiges Spiel zu programmieren.

es gibt auch 16 jährige die das solaris betriebsystem bei einem programmier wettbewerb gehackt haben und 1/4 milion dollar kassiert haben. der kleine ist jetzt multimillionär und arbeitet als sicherheitsexperte für kryptographie...

mhm sowas hats immer .. is abe rnich die norm von der man ausgehn kann ;-)

[zustimmen]

_-_

xyertex

- 35
Halbprofi (offline)

Dabei seit 02.2006
265 Beiträge

Geschrieben am: 12.09.2006 um 12:45 Uhr
Zuletzt editiert am: 12.09.2006 um 12:50 Uhr

zitat : Ich hab ihn, ihr auch? Mozila Firefox 2.0 Beta.... :-)

ich hab windows vista ultimate edition [und was sagsch jetzt]

Aber trotzdem Spiele programmieren kannsch vergessen.

In delphi hier n tourtorial ausschnitt:
Freies Bewegen

Bis jetzt können wir Akteure in die Welt einbinden und dort herumstehen lassen. Das würde z.B. gut für Gegenstände passen, die man im Spiel mitnehmen kann. Bei Figuren aber möchte man, dass diese sich bewegen. Im Idealfall tun sie dies sozusagen aus freien Stücken, also ohne dass sie etwa über die Tasten gesteuert werden müssen. Damit unsere Figur also nicht nur eine Statistenrolle einnimmt, müssen wir ihr das Laufen beibringen:
procedure TFigur.Walk;
const xDiff=0.1;
var Richtung: Integer; Winkel: geFloat;
begin
Richtung := Random(15);
case Richtung of
// kurze Drehung
isLeft : TurnVector.y := TurnVector.y + xDiff;
isRight: TurnVector.y := TurnVector.y - xDiff;
// sonst vorwärts/geradeaus
else
begin
LookVector.x := ViewVector.x + MSpeed * sin(TurnVector.y);
LookVector.z := ViewVector.z + MSpeed * cos(TurnVector.y);
end;
end;
// Neue View-Werte nur, wenn keine Kollision
if not Collision then
ViewVector := LookVector
// sonst Drehung, Schritt zurück
else
begin
Winkel := (Random(7)-3)*Pi/3; // 60 bis 180 Grad
TurnVector.y := TurnVector.y + Winkel;
LookVector.x := ViewVector.x - MSpeed * sin(TurnVector.y);
LookVector.z := ViewVector.z - MSpeed * cos(TurnVector.y);
end;
end;

Weil mit MSpeed die Laufgeschwindigkeit bereit gegeben ist, benötigen wir mit xDiff nur eine Konstante. Ansonsten erinnert eine Menge an die GetInput-Methode aus der Hauptunit. Anstelle einer Tastenabfrage wird hier eine zufällige Richtung erzeugt.
Richtung:= random(15);

Die Konstanten für Links und Rechts werden als einfache ganze Zahlen vereinbart:
const isRight = 1; isLeft = 2;

Die erreichbare Zufallszahl ist deshalb hoch, damit die Figur nur ab und zu einen Schwenk nach links oder rechts macht:
case Richtung of
isLeft : TurnVector.y := TurnVector.y + xDiff;
isRight: TurnVector.y := TurnVector.y - xDiff;

Ansonsten und meistens geht es vorwärts und geradeaus:
LookVector.x := ViewVector.x + MSpeed * sin(TurnVector.y);
LookVector.z := ViewVector.z + MSpeed * cos(TurnVector.y);

Auch bei der Figur gibt es nur dann neue Werte für ViewVector, wenn es zu keiner Kollision kommt:
if not Collision then ViewVector := LookVector;

Was aber, wenn doch? Um z.B. von einer Wand wegzukommen, hilft am besten eine kräftigere Drehung (um 60 oder mehr Grad) und vielleicht noch ein Schritt zurück:
Winkel := (random(7)-3)*Pi/3;
TurnVector.y := TurnVector.y + Winkel;
LookVector.x := ViewVector.x - MSpeed * sin(TurnVector.y);
LookVector.z := ViewVector.z - MSpeed * cos(TurnVector.y);

Sollte Euch später diese "Kollisionsverarbeitung" nicht zusagen, heißt es andere Winkel ausprobieren oder auch mal den Schritt zurück weglassen.

In der Hauptunit haben wir uns mit einer recht einfachen Kollisionsfunktion begnügt. Treppen hinaufsteigen oder heruntergehen wurde dabei nicht berücksichtigt. Damit jedoch unsere Figur nicht vor ein paar Stufen schlappmacht, erweitern wir nun die Collision-Methode entsprechend ? erst einmal für TFigur:
function TFigur.Collision: Boolean;
var TempVector: geVec3D; KontaktInfo: GE_Collision;
begin
Result := Boolean(geWorld_Collision (World, @MinVector, @MaxVector,
@LookVector, @ViewVector, GE_CONTENTS_SOLID_CLIP, GE_COLLIDE_ALL,
0, nil, nil, @KontaktInfo));
if not Result then exit;
// Kontrolle ob Treppe oder "Schräge"
TempVector := ViewVector;
TempVector.y := TempVector.y + StepJump;
LookVector.y := LookVector.y + StepJump;
// Test aus höherer Sichtposition
Result := Boolean(geWorld_Collision (World, @MinVector, @MaxVector,
@LookVector, @TempVector, GE_CONTENTS_SOLID_CLIP, GE_COLLIDE_ALL,
0, nil, nil, @KontaktInfo));
// ggf. zurück auf alte "Sichthöhe"
if Result then LookVector.y := LookVector.y - StepJump;
end;

Zuerst erfolgt die normale Kollisionskontrolle (die sich für Wände bereits bewährt hat). Als nächstes heben wir die Figurposition ein bisschen an, um von hier aus zu überprüfen, ob wir auf ein Hindernis stoßen (würden). Ein temporärer Hilfsvektor dient zur Zwischenspeicherung des "Versuchswertes":
TempVector := ViewVector;
TempVector.y := TempVector.y + StepJump;
LookVector.y := LookVector.y + StepJump;
Result := Boolean(geWorld_Collision (World, @MinVector, @MaxVector,
@LookVector, @TempVector, GE_CONTENTS_SOLID_CLIP, GE_COLLIDE_ALL,
0, nil, nil, @KontaktInfo));

Sollte das zu einer Kollision führen, kehren wir zurück zur alten Sichthöhe:
if Result then LookVector.y := LookVector.y - StepJump;

StepJump wir als Konstante vereinbart, z.B. mit diesem Wert:
const StepJump = 50;

Mit der erweiterten Kollisionsmethode ist es unserer Figur möglich, die Treppe zu erklimmen ? aber nun kommt sie nicht mehr herunter. Ein weitere Fall für die Kollisionskontrolle also: Eine neue Methode soll sich um die Gravitation kümmern, also dafür sorgen, dass die Figur ständig auf dem Boden bleibt. Ein passender Name ist mit CheckGravity auch gleich gefunden:
procedure TFigur.CheckGravity;
var TempVector: geVec3D; KontaktInfo: GE_Collision; isFalling: Boolean;
begin
// Kontrolle, ob noch "festen Boden unter Füßen"
TempVector := ViewVector;
TempVector.y := TempVector.y - StepJump;
isFalling := Boolean(geWorld_Collision (World, @MinVector, @MaxVector,
@ViewVector, @TempVector, GE_CONTENTS_SOLID_CLIP, GE_COLLIDE_ALL,
0, nil, nil, @KontaktInfo));
// ggf. zurück auf Bodenhöhe
if isFalling then TempVector.y := KontaktInfo.Impact.y;
LookVector := TempVector;
ViewVector := LookVector;
end;

Auch hier arbeiten wir wieder mit einem temporären Hilfsvektor, dem wir gleich die Werte von ViewVector zuweisen. Anschließend wird ein Konstantenwert subtrahiert:
TempVector := ViewVector;
TempVector.y := TempVector.y - StepJump;

Nun probieren wir aus, ob wir die Figur ein Stückchen nach unten sacken lassen könnten:
isFalling := Boolean(geWorld_Collision (World, @MinVector, @MaxVector,
@ViewVector, @TempVector, GE_CONTENTS_SOLID_CLIP, GE_COLLIDE_ALL,
0, nil, nil, @KontaktInfo));

Sollte das nicht klappen, befindet sich die Figur offensichtlich auf festem Grund. Andernfalls muss sie sich auf den Boden fallen lassen:
if isFalling then TempVector.y := KontaktInfo.Impact.y;

Der Vektor Impact in der KontaktInfo-Struktur enthält die aktuellen noch erlaubten "Berührungspunkte" für alle Achsen. Weil das Fallen entlang der y-Achse verläuft, wird hier also Impact.y benötigt, womit TempVector.y auf Bodenhöhe gesetzt wird. (Dieses Kontrollprinzip funktioniert nicht nur für Treppen, wenn man sie hinuntergehen will: Dort lässt man sich sozusagen von Stufe zu Stufe fallen. Auch ein Hinunterplumpsen in ein Loch oder einen Abgrund wäre jetzt möglich. Und sollte es auch noch so tief hinuntergehen, man kommt immer heil unten an. Allerdings nur, wenn irgendwo ein Stückchen fester Boden ist. Andernfalls wird der Fall endlos.)

Als (vorläufig) letzte Methode bekommt die Unit G4DFigur noch eine Prozedur zur Demontage des Akteurs:
destructor TFigur.Destroy;
begin
if ActorDef nil then geActor_DefDestroy(@ActorDef);
if Actor nil then geActor_Destroy(@Actor);
inherited Destroy;
end;

Damit die Freigabe reibungslos klappt, werden hier über zwei Genesis-Methode die Definitionsdaten und dann der Actor selbst entfernt.

hier n link
genesis3d

[zustimmen]

fat32

Experte (offline)

Dabei seit 09.2006
1465 Beiträge

Geschrieben am: 12.09.2006 um 14:13 Uhr

Was für ein Spiel stellt sich der eigentlich vor? sowas wie GTA oder eher tetris?

[zustimmen]

bassmaster

- 48
Profi (offline)

Dabei seit 10.2004
631 Beiträge

Geschrieben am: 12.09.2006 um 15:02 Uhr

@fat32: hab leider den fall nicht gefunden, wo der 16 jährige den solaris server gehackt hat, aber andere noch spektakuläre 16 jährige hacker.

die dvd - damals angeblich sicherstes medium, da es einen asymetrischen schlüssel verwendet. gehackt von einem 16 jährigen (als er das programm geschrieben hat war er 15). ohne seine hilfe könnten wir heute keine einzige videodvd kopieren (außer die selbstgemachten)

http://www.zdnet.de/news/business/0,39023142,2050319,00.htm

oder hier ein 16 jähriger der die 56 größten webseiten gehackt hat:

http://archiv.chip.de/news/c1_archiv_news_stories_17490396.html

vielleicht finde ich den 16 jährigen noch der das solaris betriebsystem gehackt hat. naja er hat nicht das betriebsystem gehackt,sondern hat sich einen buffer underrun in den angeblich sichersten webserver den es gibt (apache) zur nutze gemacht eine hintertüre aufzumachen um ins betriebsystem adminrechte zu bekommen....

achja, der programmierer von den schlimmsten virus der geschichte (sasser) war auch ein 18 jähriger, der den virus vorher programmiert hat und dadurch nur jugendstraffe genossenhat...

[zustimmen]

http://www.impala64.de/blog - http://www.impala64.de/ - www.myspace.com/impala64lowrider

Cheesys

- 35
Champion (offline)

Dabei seit 10.2005
2978 Beiträge

Geschrieben am: 12.09.2006 um 15:08 Uhr

Zitat von bassmaster:

is ja geil

[zustimmen]

Inoffizieller Ps3 Kundendienst ;-)

fat32

Experte (offline)

Dabei seit 09.2006
1465 Beiträge

Geschrieben am: 12.09.2006 um 15:11 Uhr

Zitat von bassmaster:

Ich frag mich nur, wo die sowas gelernt haben.... Trotzdem Danke, ich les mir mal die Artikel durch

[zustimmen]

bassmaster

- 48
Profi (offline)

Dabei seit 10.2004
631 Beiträge

Geschrieben am: 12.09.2006 um 16:21 Uhr

Zitat von fat32:

Ich frag mich nur, wo die sowas gelernt haben.... Trotzdem Danke, ich les mir mal die Artikel durch

sowas lernt man nebenbei. das fängt so an:
mein schreibt ein programm und definiert eine variable die 5 buchstaben lang ist.
schreibt aber 10 buchstaben rein. was dann passiert ist, dass in den meisten fällen das programm abstürzt, weil speicher mit unsinn überschrieben wird. irgendwann mal stellt man fest, das diese restlichen 5 buchstaben nicht nur buchstaben enthalten können, sondern auch assembler code. so kann man dann fremden code auf einem fremden rechner ausführen. das nennt sich buffer underrun. was bringt das ganze?
ich hab jetzt irgendwo erfahren, das die uralte version von apache (der meistverbreiteste webserver auf der welt) ein buffer underrun hat in einer bestimmten methode. dieser schicke ich nicht nur die wie oben genannten 5 buchstaben sondern hänge dahinter noch mein ftp programm ein und lass das unter den selben rechten startetn wie apache... damit kann ich min. die komplette homepage verändern. so ist es schon passiert, dass wenn man www.ebay.de eingegeben hat auf einmal eine seite kam "he he, ich wurde gehackt..." im prinzip für einen guten programmierer kein problem - nur die meisten guten programmierer verdienen geld mit den programmieren. es gibt aber jugentliche die mit 14 angefangen haben zu programmieren (so wie ich) und denen wird es irgendwann mal langweilig. dann kommt sowas dabei raus. die schlimmsten häcker sind nicht die besten programmierer sondern jugentliche programmierer, denen es lagweilig geworden ist oder ihren kumpels irgend was beweisen müssen....

[zustimmen]

http://www.impala64.de/blog - http://www.impala64.de/ - www.myspace.com/impala64lowrider

Caarcrinolas

- 41
Profi (offline)

Dabei seit 02.2006
909 Beiträge

Geschrieben am: 13.09.2006 um 16:35 Uhr

Zitat von bassmaster:

Jup oder man denke mal an die diversen Untergroundszenen, verschiedene Gruppierungen versuchen als erstes ein bislang als "Sicher" eingestuftes Programm zu cracken um den Ruhm einzufahren.
Man kann es auch als Waage oder endlos Schleife sehen:
cracked = false;
while ( ! cracked )
{
if (cracked = try_to_crack() )
{
sleep();
if ( exist_new_protection() )
cracked = false;
}
}

Das zeichnet sich sowohl in der Crackszene als auch Cheaterszene ab.
Viele Progger verspüren auch den Drang Geld damit zu verdienen, wie man in der Cheaterszene sieht. Public Hacks existieren zum Glück nur eine kurze Zeit. Jedoch gibt es auch Private Hacks die Geld kosten.

Ich finde den Wettbewerb in der Crackerszene auf der einen Seite gut und auf der Anderen Seite wiederrum nicht. Da Originalsoftware im Bruchteil von ein paar Tagen in etlichen Tauschbörsen herumzieht und man des Verdienstes und des geistigen Eigentums beraubt wird ist unfair. Auf der Anderen Seite werden dann instabile Schutzmechanismen wie Starforce entwickelt die sich in das System als Treiber einnisten und die zahlt der brave Käufer quasi indirekt mit.

Daher betitle ich das ganze gerne als Teufelskreis und ewiger Wettbewerb.......

[zustimmen]

Aristoteles: "Es gibt kein großes Genie ohne einen Schuß Verrücktheit."

Rifleman

- 40
Experte (offline)

Dabei seit 09.2003
1540 Beiträge

Geschrieben am: 13.09.2006 um 19:55 Uhr
Zuletzt editiert am: 13.09.2006 um 20:03 Uhr

Zitat von bassmaster:

mein schreibt ein programm und definiert eine variable die 5 buchstaben lang ist.
schreibt aber 10 buchstaben rein. was dann passiert ist, dass in den meisten fällen das programm abstürzt, weil speicher mit unsinn überschrieben wird. irgendwann mal stellt man fest, das diese restlichen 5 buchstaben nicht nur buchstaben enthalten können, sondern auch assembler code. so kann man dann fremden code auf einem fremden rechner ausführen. das nennt sich buffer underrun.

Das ganze nennt sich "buffer overflow". Ich wüsste nicht, was ein leerer Puffer an Schaden anrichten könnte. Und ganz so einfach ist das auch nicht. Man muss sich schon den Maschinencode sehr genau anschauen.
In der Regel versucht man dabei, Maschinencode in einem Pufferarray unterzubringen und dann in einer Funktion über das Array hinaus die Rücksprungaddresse im Stack so zu verändern, dass der eigene Code im Puffer angesprungen wird. Grundsätzlich ist sowas möglich, da in C beispielsweise keine Überprüfungen bei Pointeroperationen existieren (Arrays werden hier immer als Pointer interpretiert). Wenn man nun beim programmieren schlampt können solche Sicherheitslücken entstehen...

Zitat von bassmaster:

also wenn ich mich an meiner programmier prüfungen zurückdenke, dann war da eine rekursive schleife zu programmieren, einen programmablaufplan zu erstellen und das programm zu dokumentieren. sowas wie minesweeper wäre eine diplomarbeit über ein halbes jahr.

Naja...übertreiben wir da mal nicht....ich bin zwar kein Informatiker, aber ich hab n Vordiplom Informatik (Nebenfach), und sogar dafür wär das viel zu einfach gewesen....

[zustimmen]

Es sind die kleinen Dinge, die einen zum Wahnsinn treiben.

bassmaster

- 48
Profi (offline)

Dabei seit 10.2004
631 Beiträge

Geschrieben am: 14.09.2006 um 01:20 Uhr

Zitat von Rifleman:

[

Zitat von bassmaster:

Naja...übertreiben wir da mal nicht....ich bin zwar kein Informatiker, aber ich hab n Vordiplom Informatik (Nebenfach), und sogar dafür wär das viel zu einfach gewesen....

naja, wir hatten soweit ich mich erinnern kann 5 stunden zeit für eine aufgabe. in den 5 stunden mustest du ein programmablaufplan erstellen, manchmal ein uml diagramm, pflichen / lastenheft, manchmal ein abnahmedokument, planen, programmieren und eine doku schreiben. da kann man nicht verlangen, dass das programm irgendwelche wunder vollbringt. meist waren es dann irgend welche klassischen informatik probleme wie z.b. rekursion. in den genannten fall sollten wir so weit ich mich noch erinnern kann ein "dir" befehl nachprogrammieren, der alle unterverzeichnisse ausgibt und in einem bestimmten format ausgibt. ich hab für alles nur ein teil der 5 stunden gebraucht, es gab aber auch andere, die haben eine leere diskette abgegeben...

[zustimmen]

http://www.impala64.de/blog - http://www.impala64.de/ - www.myspace.com/impala64lowrider

Kugelfang

- 40
Anfänger (offline)

Dabei seit 11.2005
25 Beiträge

Geschrieben am: 14.09.2006 um 11:34 Uhr

Zitat von bassmaster:

hmm nur 5 Stunden ? Also die Diplomarbeiten bei uns gehen durchaus 6 Monate, und da muss man sich durchaus auch mit schwereren Themen beschäftigen als Minesweeper.

Hier nen Auszug aus unserer aktuellen Diplomprüfungsordnung:

(4) Die Zeit von der Ausgabe des
Themas bis zur Ablieferung der
Diplomarbeit beträgt sechs Monate. Im
Einzelfall kann auf begründeten Antrag
der Prüfungsausschuss die
Bearbeitung selbst ausnahmsweise
um bis zu drei Monate verlängern.

Quelle: http://www.informatik.uni-ulm.de/t3-home/uploads/media/DPO2001.pdf

[zustimmen]

<<< zurück

-1- -2-

[Antwort schreiben]

Forum / Bits und Bytes