Codestyle

Übersicht

BlitzBasic

Allgemein

Gehe zu Seite 1, 2 Weiter

	5k41 Betreff: Codestyle	Mi, März 01, 2006 17:10 Antworten mit Zitat
Hallo nochmal! (sry wegen der vielen Themen heute aber die kann man Partout nicht zusammen bringen und haben sich bei mir so angestaut) Wäre sehr dankbar für ein paar kleine Tipps zum schönen/übersichtlichen Programmieren und generell zum Ansatz ( ja ich weiss nun kommen Funktionen, Konstanten und Types aber alles benutz ich und irgendwie wirds bei mir jedesmal auf gutdeutsch...ein Schlachtfeld!). Beim Ansatz geht es mir darum, das wenn ich ein Spielkonzept fertig entworfen hab immer nicht weiss womit ich anfangen soll und mich nun gefragt hab obs da vielleicht eine non plus ultra lösung gibt also so: erst menü dann sämtliche Funktionen einzeln dann das Spiel oder so. Danke für die Hilfe!
Projekte: For a better World - Gesellschaftsspiel ( 100%) User posted image

5k41

Betreff: Codestyle

Mi, März 01, 2006 17:10
Antworten mit Zitat

Hallo nochmal! (sry wegen der vielen Themen heute aber die kann man Partout nicht zusammen bringen und haben sich bei mir so angestaut)
Wäre sehr dankbar für ein paar kleine Tipps zum schönen/übersichtlichen Programmieren und generell zum Ansatz ( ja ich weiss nun kommen Funktionen, Konstanten und Types aber alles benutz ich und irgendwie wirds bei mir jedesmal auf gutdeutsch...ein Schlachtfeld!). Beim Ansatz geht es mir darum, das wenn ich ein Spielkonzept fertig entworfen hab immer nicht weiss womit ich anfangen soll und mich nun gefragt hab obs da vielleicht eine non plus ultra lösung gibt also so: erst menü dann sämtliche Funktionen einzeln dann das Spiel oder so.

Danke für die Hilfe!

Projekte:
For a better World - Gesellschaftsspiel ( 100%)

User posted image

	HW	Mi, März 01, 2006 17:23 Antworten mit Zitat
Also es ist schonmal gut, wenn man das Zeug ordentlich kommentiert. D.h. man soll nicht wie ein Noob hinschreiben, was der eben angwandte Befehl in seiner Funktionsweise bewirkt, sondern was man damit eigentlich anfangen will. Vor allem bei Teamarbeit ist das sehr wichtig, da sonst andere Mitglieder eventuell bei einer Codepassage nicht verstehen, was diese bewirkt. Aber auch bei Soloarbeiten kann das nützlich sein, da man bei größeren Projekten irgendwann mal vielleicht selbst nicht mehr durchblickt. Auch können sinnvolle Includes immer wieder nützlich sein. Im Großen und Ganzen ist es eigentlich am Stil des Programmierers, den Code zu gestalten. Wer bereits etwas programmiert hat, kann wohl selbst entscheiden, wie ein Code am besten aufgebaut ist. Bei Teamarbeiten ist das dann aber nicht so leicht, da muss man sich schon etwas überlegen. Daher denke ich nicht, dass du allzu gute Antworten erhalten wirst. Jeder Programmierer hat so seinen Stil, den er natürlich anderen empfehlen würde. Aber es ist hinterher sinnlos, die Stile verschiedener Programmierer zu einem zusammenfassen zu wollen. Es ist besser, seinen eigenen Stil zu entwickeln und diesen anzuwenden. Edit: hectic hat Folgendes geschrieben: Also ich mach das immer so... Exakt das, was ich meine!

HW

Mi, März 01, 2006 17:23
Antworten mit Zitat

Also es ist schonmal gut, wenn man das Zeug ordentlich kommentiert. D.h. man soll nicht wie ein Noob hinschreiben, was der eben angwandte Befehl in seiner Funktionsweise bewirkt, sondern was man damit eigentlich anfangen will. Vor allem bei Teamarbeit ist das sehr wichtig, da sonst andere Mitglieder eventuell bei einer Codepassage nicht verstehen, was diese bewirkt. Aber auch bei Soloarbeiten kann das nützlich sein, da man bei größeren Projekten irgendwann mal vielleicht selbst nicht mehr durchblickt.
Auch können sinnvolle Includes immer wieder nützlich sein.

Im Großen und Ganzen ist es eigentlich am Stil des Programmierers, den Code zu gestalten. Wer bereits etwas programmiert hat, kann wohl selbst entscheiden, wie ein Code am besten aufgebaut ist. Bei Teamarbeiten ist das dann aber nicht so leicht, da muss man sich schon etwas überlegen.
Daher denke ich nicht, dass du allzu gute Antworten erhalten wirst. Jeder Programmierer hat so seinen Stil, den er natürlich anderen empfehlen würde. Aber es ist hinterher sinnlos, die Stile verschiedener Programmierer zu einem zusammenfassen zu wollen. Es ist besser, seinen eigenen Stil zu entwickeln und diesen anzuwenden.

Edit: hectic hat Folgendes geschrieben:

Also ich mach das immer so...

Exakt das, was ich meine!

Zuletzt bearbeitet von HW am Mi, März 01, 2006 17:25, insgesamt einmal bearbeitet

	hectic Sieger des IS Talentwettbewerb 2006	Mi, März 01, 2006 17:24 Antworten mit Zitat
Also ich mach das immer so... Ein Konzept ausarbeiten! Bei einfachen Sachen reicht mir auch mein Gedächnis... Variablen die überall benötigt werden, kommen gleich am Anfang und werden ausführlich dokumentiert. Damit man den Code auch nach ein paar Monaten verstehen tut... Bei größeren Projekten nenne ich die erste Datei prepare.bb und in dieser werden Variablen deklariert, Einstellungen durchgeführt (wie Camera, Light, etc.), Standardsachen geladen wie Sounds, Grafik etc... Am Ende dieser prepare.bb kommt dann eine Reihe von includes die dann den gesammten Code zusammenfügt... Die anderen Includes sind dann größere einzelne Sachen wie beispielsweise: - manager.bb (Menü aus welchem dann die einzelnen Sachen 'gemanaget' werden, also die GUI für den User). - spielen.bb Das spiel selber ohen Levelladen etc. das macht alles manager.bb - loadmap.bb (und savemap.bb bei einem mitgelieferten Editor). Erklärt sich von selbst. Im grunde bleibt es aber jedem selbst überlassen wie er eine Struktur aufbaut. Es sollte nur für jedem verständlich sein. Nur so kann man davon ausgehen das man selbst dann in späterer Zeit sich da zurechtfindet.

hectic

Sieger des IS Talentwettbewerb 2006

Mi, März 01, 2006 17:24
Antworten mit Zitat

Also ich mach das immer so... Ein Konzept ausarbeiten! Bei einfachen Sachen reicht mir auch mein Gedächnis... Variablen die überall benötigt werden, kommen gleich am Anfang und werden ausführlich dokumentiert. Damit man den Code auch nach ein paar Monaten verstehen tut... Bei größeren Projekten nenne ich die erste Datei prepare.bb und in dieser werden Variablen deklariert, Einstellungen durchgeführt (wie Camera, Light, etc.), Standardsachen geladen wie Sounds, Grafik etc... Am Ende dieser prepare.bb kommt dann eine Reihe von includes die dann den gesammten Code zusammenfügt... Die anderen Includes sind dann größere einzelne Sachen wie beispielsweise:
- manager.bb (Menü aus welchem dann die einzelnen Sachen 'gemanaget' werden, also die GUI für den User).
- spielen.bb Das spiel selber ohen Levelladen etc. das macht alles manager.bb
- loadmap.bb (und savemap.bb bei einem mitgelieferten Editor). Erklärt sich von selbst.

Im grunde bleibt es aber jedem selbst überlassen wie er eine Struktur aufbaut. Es sollte nur für jedem verständlich sein. Nur so kann man davon ausgehen das man selbst dann in späterer Zeit sich da zurechtfindet.

	5k41	Mi, März 01, 2006 17:34 Antworten mit Zitat
Danke schonmal für die Antworten Hectics Stil gefällt mir ganz gut! Werde das glaub ich mal Probeweise beim nächsten Projekt machen wäre trozdem erfreut über neue Anregungen!
Projekte: For a better World - Gesellschaftsspiel ( 100%) User posted image

5k41

Mi, März 01, 2006 17:34
Antworten mit Zitat

Danke schonmal für die Antworten Smile

Hectics Stil gefällt mir ganz gut! Werde das glaub ich mal Probeweise beim nächsten Projekt machen wäre trozdem erfreut über neue Anregungen!

Projekte:
For a better World - Gesellschaftsspiel ( 100%)

User posted image

	hectic Sieger des IS Talentwettbewerb 2006	Mi, März 01, 2006 18:13 Antworten mit Zitat
Hallo HW, ich habe am Ende auch geschrieben Im grunde bleibt es aber jedem selbst überlassen wie er eine Struktur aufbaut. Es sollte nur für jedem verständlich sein. Nur so kann man davon ausgehen das man selbst dann in späterer Zeit sich da zurechtfindet. Ausserdem wollte ich 5k41 eine Möglichkeit geben, wie man es machen kann. Deine Hilfe wird ihm nicht wirklich viel weiter gebracht haben, da kein Lösungsansatz vorzufinden ist. Das einzige vernünftige von dir war Also es ist schonmal gut, wenn man das Zeug ordentlich kommentiert. D.h. man soll nicht wie ein Noob hinschreiben, was der eben angwandte Befehl in seiner Funktionsweise bewirkt, sondern was man damit eigentlich anfangen will. Ich habe ja nicht geschrieben "Hey 5k41 du musst das so machen und die erste Datei hast du gefälligst prepare.bb zu nennen", sondern lediglich meine Struktur wieder gegeben... Diese Struktur kann wesentlich hilfreicher sein als Hilfsschnippsel die nichts weiter aussagen. Es ist also eine Gesankenanstoß für eine Lösung. Man kann Menschen ins kalte Wasser schmeissen und zusehen ob sie sich selbst halten können, oder ihnen eine Möglichkeit an einer einfachen Schwimmtechnik zeigen um sie dann erst ins Wasser zu schmeissen. Solche Lösungswege und Gedankenstützen sind durchaus üblich zB Fahrschule beim rückwärtz einparcken mit der C-Säule, für Leute die es einfach nicht können. /EDIT: Deine Erklärung trägt überhaut nicht dazu bei, eine Struktur in ein Code zu bekommen, welche nun mal angefragt wurde. Man kann kommentieren so viel man will. Eine Struktur ist es nicht! Mit solch Aroganter art sollte man hier nicht mit Menschen umgehen wie es deiner mir gegenüber war. 5k41 hat geschrieben: obs da vielleicht eine non plus ultra lösung gibt also so: erst menü dann sämtliche Funktionen einzeln dann das Spiel oder so.

hectic

Sieger des IS Talentwettbewerb 2006

Mi, März 01, 2006 18:13
Antworten mit Zitat

Hallo HW, ich habe am Ende auch geschrieben

Im grunde bleibt es aber jedem selbst überlassen wie er eine Struktur aufbaut. Es sollte nur für jedem verständlich sein. Nur so kann man davon ausgehen das man selbst dann in späterer Zeit sich da zurechtfindet.
Ausserdem wollte ich 5k41 eine Möglichkeit geben, wie man es machen kann. Deine Hilfe wird ihm nicht wirklich viel weiter gebracht haben, da kein Lösungsansatz vorzufinden ist. Das einzige vernünftige von dir war

Also es ist schonmal gut, wenn man das Zeug ordentlich kommentiert. D.h. man soll nicht wie ein Noob hinschreiben, was der eben angwandte Befehl in seiner Funktionsweise bewirkt, sondern was man damit eigentlich anfangen will.
Ich habe ja nicht geschrieben "Hey 5k41 du musst das so machen und die erste Datei hast du gefälligst prepare.bb zu nennen", sondern lediglich meine Struktur wieder gegeben... Diese Struktur kann wesentlich hilfreicher sein als Hilfsschnippsel die nichts weiter aussagen. Es ist also eine Gesankenanstoß für eine Lösung. Man kann Menschen ins kalte Wasser schmeissen und zusehen ob sie sich selbst halten können, oder ihnen eine Möglichkeit an einer einfachen Schwimmtechnik zeigen um sie dann erst ins Wasser zu schmeissen. Solche Lösungswege und Gedankenstützen sind durchaus üblich zB Fahrschule beim rückwärtz einparcken mit der C-Säule, für Leute die es einfach nicht können.

/EDIT: Deine Erklärung trägt überhaut nicht dazu bei, eine Struktur in ein Code zu bekommen, welche nun mal angefragt wurde. Man kann kommentieren so viel man will. Eine Struktur ist es nicht! Mit solch Aroganter art sollte man hier nicht mit Menschen umgehen wie es deiner mir gegenüber war. 5k41 hat geschrieben:

erst menü dann sämtliche Funktionen einzeln dann das Spiel oder so.

	HW	Mi, März 01, 2006 20:32 Antworten mit Zitat
Ich wollte mit dem Zitat eigentlich nicht zu aufdringlich erscheinen. Allerdings ist das wohl leider eine Nebenwirkung einer solchen Anmerkung. Außerdem habe ich in meiner Erklärung keinesfalls gesagt, dass man für das Inkrafttreten meiner Beschreibung dem Hilfesuchenden mit solch einem aufdringlichen "Du musst das so und so machen..." kommen muss. Es genügt, wenn man seine Gewohnheiten beschreibt. Ich habe in meiner Beschreibung übrigens niemanden persönlich im Auge gehabt. Ich habe dich nur zitiert, weil du einen so schön zu meiner Beschreibung passendes Zitat geschrieben hast. Wenn dir meine Art arrogant erschien, entschuldige ich mich dafür. Und ich bin mir bewusst, dass ich nicht viel weitergeholfen habe, da ich selbst noch keinen einheitlichen Stil entwickelt habe.

HW

Mi, März 01, 2006 20:32
Antworten mit Zitat

Ich wollte mit dem Zitat eigentlich nicht zu aufdringlich erscheinen. Allerdings ist das wohl leider eine Nebenwirkung einer solchen Anmerkung. Außerdem habe ich in meiner Erklärung keinesfalls gesagt, dass man für das Inkrafttreten meiner Beschreibung dem Hilfesuchenden mit solch einem aufdringlichen "Du musst das so und so machen..." kommen muss. Es genügt, wenn man seine Gewohnheiten beschreibt.
Ich habe in meiner Beschreibung übrigens niemanden persönlich im Auge gehabt. Ich habe dich nur zitiert, weil du einen so schön zu meiner Beschreibung passendes Zitat geschrieben hast.
Wenn dir meine Art arrogant erschien, entschuldige ich mich dafür.

Und ich bin mir bewusst, dass ich nicht viel weitergeholfen habe, da ich selbst noch keinen einheitlichen Stil entwickelt habe.

	Florian Betreff: Re: Codestyle	Mi, März 01, 2006 21:10 Antworten mit Zitat
5k41 hat Folgendes geschrieben: Beim Ansatz geht es mir darum, das wenn ich ein Spielkonzept fertig entworfen hab immer nicht weiss womit ich anfangen soll und mich nun gefragt hab obs da vielleicht eine non plus ultra lösung gibt also so: erst menü dann sämtliche Funktionen einzeln dann das Spiel oder so. 95% der Programmierer, die zuerst den Menü beginnen, bringen das Projekt nie zu ende. Ich würde bei den Kern anfangen. Zuerst überlegt man die Daten stucktur, z. B. die Objekte die zur Spielwelt gehörten. Objekte können die folgenen sein: -Der Spieler selbst -die unterschiedlichen Feinde -Gegenstände -Hindernisse -usw. Jedes Object kann auf eine bestimmte artunweise verändert werden. Jedes Object muss auf Ereignisse reagieren können. /EDIT: Jetzt stell ich vieleicht fest das zwei Objecte ähnlich sind. Das könnte heißen Sie haden gemeinsame Eigenschaften ober Ereiginisse. Es wäre wahrscheinlich unnötig das zwei zu Programmieren. Also versuche Ich das zusammen zu fassen.(Wiederverwendbarkeit) Ich würde auf jedes Object Funktionen definiren -die das Object erstellen und entfernen -die auf Ereignisse reagiren -die das Object manipulieren /EDIT: Jetzt stellt sich die Frage "Wie spreche ich die Objecte an?" Es gibt verschiede Möglichkeiten: -Über ihren Namen -über ihren Index -über ID -usw. /EDIT: Wie vergebe ich den Funktionsnamen. z. B. Object+Methode Methode+Object z. B. Function Create_Spieler(Name$,PosX,PosY) End function Function Spieler_Create(Name$,PosX,PosY) End function Danach würde ich mit den Funktionen mit den Erstellen mit den Objecten beginnen(Zuerst mit den wichtigsten) Zuerst würde ich mit den Groben und immer ins Detail gehen. /EDIT: Datenstrucktur: Ich würde dazu: Type End Type verwenden. z. B. Type TSpieler Field Name$ Field PosX Field PosY Field Leben End Type Global Spieler.TSpieler Beispiel einer Methode: Function Create_Spieler(Name$,PosY,PosX,Leben) Spieler=New TSpieler Spieler\Name$=Name$ Spieler\PosY=PosY Spieler\PosX=PoX Spieler\Leben=Leben Return HANDLE(Spieler.TSpieler) End function /EDIT: INCLUDE Ja ober nein? Bei sehr großen Projekten ist es sinnvoll. Datei sollten man auf die Logischen-Einhaitenachten. Wer jedoch den Befehl zuviel verwendet, wird der Quelltext "Unübersichtig". Der Quelltext wird zerstückelt.
Das große BlitzBasic Community Tutorial Stackmaschine 2.0

Florian

Betreff: Re: Codestyle

Mi, März 01, 2006 21:10
Antworten mit Zitat

5k41 hat Folgendes geschrieben:

Beim Ansatz geht es mir darum, das wenn ich ein Spielkonzept fertig entworfen hab immer nicht weiss womit ich anfangen soll und mich nun gefragt hab obs da vielleicht eine non plus ultra lösung gibt also so: erst menü dann sämtliche Funktionen einzeln dann das Spiel oder so.

95% der Programmierer, die zuerst den Menü beginnen, bringen das Projekt nie zu ende.

Ich würde bei den Kern anfangen.

Zuerst überlegt man die Daten stucktur, z. B. die Objekte die zur Spielwelt gehörten.

Objekte können die folgenen sein:
-Der Spieler selbst
-die unterschiedlichen Feinde
-Gegenstände
-Hindernisse
-usw.

Jedes Object kann auf eine bestimmte artunweise verändert werden.
Jedes Object muss auf Ereignisse reagieren können.

/EDIT:
Jetzt stell ich vieleicht fest das zwei Objecte ähnlich sind.
Das könnte heißen Sie haden gemeinsame Eigenschaften ober Ereiginisse.
Es wäre wahrscheinlich unnötig das zwei zu Programmieren.
Also versuche Ich das zusammen zu fassen.(Wiederverwendbarkeit)

Ich würde auf jedes Object Funktionen definiren
-die das Object erstellen und entfernen
-die auf Ereignisse reagiren
-die das Object manipulieren

/EDIT:
Jetzt stellt sich die Frage "Wie spreche ich die Objecte an?"
Es gibt verschiede Möglichkeiten:
-Über ihren Namen
-über ihren Index
-über ID
-usw.

/EDIT:
Wie vergebe ich den Funktionsnamen.

z. B.

Object+Methode
Methode+Object

z. B.

Function Create_Spieler(Name$,PosX,PosY)
End function

Function Spieler_Create(Name$,PosX,PosY)
End function

Danach würde ich mit den Funktionen mit den Erstellen mit den Objecten beginnen(Zuerst mit den wichtigsten)
Zuerst würde ich mit den Groben und immer ins Detail gehen.

/EDIT:
Datenstrucktur:

Ich würde dazu:

Type
End Type

verwenden.

z. B.

Type TSpieler
Field Name$
Field PosX
Field PosY
Field Leben
End Type

Global Spieler.TSpieler

Beispiel einer Methode:

Function Create_Spieler(Name$,PosY,PosX,Leben)
Spieler=New TSpieler

Spieler\Name$=Name$
Spieler\PosY=PosY
Spieler\PosX=PoX
Spieler\Leben=Leben

Return HANDLE(Spieler.TSpieler)
End function

/EDIT:
INCLUDE Ja ober nein?
Bei sehr großen Projekten ist es sinnvoll.
Datei sollten man auf die Logischen-Einhaitenachten.

Wer jedoch den Befehl zuviel verwendet, wird der Quelltext "Unübersichtig".
Der Quelltext wird zerstückelt.

Das große BlitzBasic Community Tutorial
Stackmaschine 2.0

Zuletzt bearbeitet von Florian am Mi, März 01, 2006 22:11, insgesamt 6-mal bearbeitet

	5k41	Mi, März 01, 2006 21:14 Antworten mit Zitat
Danke! Sehr allgemein Formuliert aber so kann man sich doch schonmal alles zusammenstückeln nun kann dich die "Dateiverwaltung" von hectic benutzen und deine vorgehensweise. Trozdem würde ich gern noch die Meinung einiger anderer Leute dazu hören
Projekte: For a better World - Gesellschaftsspiel ( 100%) User posted image

5k41

Mi, März 01, 2006 21:14
Antworten mit Zitat

Danke!
Sehr allgemein Formuliert aber so kann man sich doch schonmal alles zusammenstückeln nun kann dich die "Dateiverwaltung" von hectic benutzen und deine vorgehensweise. Trozdem würde ich gern noch die Meinung einiger anderer Leute dazu hören Wink

Projekte:
For a better World - Gesellschaftsspiel ( 100%)

User posted image

	hectic Sieger des IS Talentwettbewerb 2006	Mi, März 01, 2006 21:30 Antworten mit Zitat
@HW, nagut. Habe eigendlich darauf gehofft, daß hier ein paar Leute mehr schreiben um neue Ideen sammeln zu können. @5k41, hab mal vor Jahren im Internet was gelesen wie man eine Struktur eines Quelltextes hinbekommt. Dieses wahr ein 'vergeblicher' Versuch eine einheitliche Regelung für die Struktuierung eine Quelltextes zu bekommen. Also eine Art Standard an die sich alle Programmierer lehnen sollten, um untereinander besser in Kontakt tretten zu können. Habe leider nichts mehr davon gehört und wie es ausgegangen ist. Auch nichts mehr bei Mr. Google finden können...

hectic

Sieger des IS Talentwettbewerb 2006

Mi, März 01, 2006 21:30
Antworten mit Zitat

@HW, nagut. Habe eigendlich darauf gehofft, daß hier ein paar Leute mehr schreiben um neue Ideen sammeln zu können.

@5k41, hab mal vor Jahren im Internet was gelesen wie man eine Struktur eines Quelltextes hinbekommt. Dieses wahr ein 'vergeblicher' Versuch eine einheitliche Regelung für die Struktuierung eine Quelltextes zu bekommen. Also eine Art Standard an die sich alle Programmierer lehnen sollten, um untereinander besser in Kontakt tretten zu können. Habe leider nichts mehr davon gehört und wie es ausgegangen ist. Auch nichts mehr bei Mr. Google finden können...

	Firstdeathmaker	Mi, März 01, 2006 21:40 Antworten mit Zitat
Also ich fange immer erst mit der Struktur an (Also den verschiedenen Menüs, den GAMESTATS). In BMax gibt es dafür ein schönes Modul, das hab ich mir noch ein wenig modifiziert, aber in BB mache ich es folgendermaßen: 1. Globale und Konstanten definieren (Da sie im gesamten Code gelten,werden sie in der Hauptdatei definiert) 2. Dims definieren 3. Types definieren 4. Allgemeine Funktionsbibliotheken includen (Hab da ein paar Sammlungen zu GFX und sonstigen, "nützlichen" Sachen die ich immer wieder brauche. Auch allgemeine Funktionen werden hier geladen, die sind extra in einer Include-Datei verpackt, die je nach Verwendungszweck dann gfx.bb oder sfx.bb heisst. 5. Die einzelnen Spielzustände sind bei mir die GAMESTATS. Sie lagern in einem extra Ordner, und sind voneinander unabhängig. Wenn ich von einem in den anderen wechseln möchte, übergebe ich der globalen Variabel GAMESTAT die Nummer des neuen Gamestats und verlasse die Schleife des aktuellen. Beispiel: Die Hauptauswahlschleife Code: [AUSKLAPPEN] [EINKLAPPEN] Repeat FlushKeys() Select GAMESTAT Case 1 Include "GAMESTATS\Intro.bb" Case 2 Include "GAMESTATS\Mainmenue.bb" Case 3 Include "GAMESTATS\Option.bb" Case 4 Include "GAMESTATS\Credits.bb" Case 5 Include "GAMESTATS\Game.bb" Case 6 Include "GAMESTATS\Out.bb" End Select Until GAMESTAT=0 End Ein Gamestat als Codebeispiel: Code: [AUSKLAPPEN] [EINKLAPPEN] ; >>Initialisierung<< ;>>Hauptschleife<< Repeat Cls Text 10,10,"Hauptmenü (Space=Start Esc=Quit o=Options i=Intro)" If KeyHit(1) GAMESTAT = 6 ;Out If KeyHit(57) GAMESTAT = 5 ;Game If KeyHit(24) GAMESTAT = 3 ;Options If KeyHit(23) GAMESTAT = 1 ;Intro Flip Until GAMESTAT<>2;Jeweiligen Gamestat einfügen ;>>Verlassen<< ;>>Spezielle nur für diesen Gamestat gebrauchte Funktionen<< Wie gesagt, ist meine Arbeitsweise in BB, vielleicht hilf es dir ja dabei deinen eigenen Stil zu verbessern oder aufzubauen.
www.illusion-games.de Space War 3 \| Space Race \| Galaxy on Fire \| Razoon Gewinner des BCC #57 User posted image

Firstdeathmaker

Mi, März 01, 2006 21:40
Antworten mit Zitat

Also ich fange immer erst mit der Struktur an (Also den verschiedenen Menüs, den GAMESTATS). In BMax gibt es dafür ein schönes Modul, das hab ich mir noch ein wenig modifiziert, aber in BB mache ich es folgendermaßen:

1. Globale und Konstanten definieren (Da sie im gesamten Code gelten,werden sie in der Hauptdatei definiert)
2. Dims definieren
3. Types definieren
4. Allgemeine Funktionsbibliotheken includen (Hab da ein paar Sammlungen zu GFX und sonstigen, "nützlichen" Sachen die ich immer wieder brauche. Auch allgemeine Funktionen werden hier geladen, die sind extra in einer Include-Datei verpackt, die je nach Verwendungszweck dann gfx.bb oder sfx.bb heisst.
5. Die einzelnen Spielzustände sind bei mir die GAMESTATS. Sie lagern
in einem extra Ordner, und sind voneinander unabhängig. Wenn ich von einem in den anderen wechseln möchte, übergebe ich der globalen Variabel GAMESTAT die Nummer des neuen Gamestats und verlasse die Schleife des aktuellen. Beispiel:

Die Hauptauswahlschleife
Code: [AUSKLAPPEN]

Repeat
FlushKeys()
Select GAMESTAT
   Case 1
      Include "GAMESTATS\Intro.bb"

   Case 2
      Include "GAMESTATS\Mainmenue.bb"

   Case 3
      Include "GAMESTATS\Option.bb"

   Case 4
      Include "GAMESTATS\Credits.bb"

   Case 5
      Include "GAMESTATS\Game.bb"

   Case 6
      Include "GAMESTATS\Out.bb"
End Select
Until GAMESTAT=0
End

Ein Gamestat als Codebeispiel:
Code: [AUSKLAPPEN]

; >>Initialisierung<<

;>>Hauptschleife<<
Repeat
Cls
   Text 10,10,"Hauptmenü (Space=Start Esc=Quit o=Options i=Intro)"
   If KeyHit(1) GAMESTAT = 6 ;Out
   If KeyHit(57) GAMESTAT = 5 ;Game
   If KeyHit(24) GAMESTAT = 3 ;Options
   If KeyHit(23) GAMESTAT = 1 ;Intro

Flip
Until GAMESTAT<>2;Jeweiligen Gamestat einfügen

;>>Verlassen<<

;>>Spezielle nur für diesen Gamestat gebrauchte Funktionen<<

Wie gesagt, ist meine Arbeitsweise in BB, vielleicht hilf es dir ja dabei deinen eigenen Stil zu verbessern oder aufzubauen. Wink

www.illusion-games.de
Space War 3 | Space Race | Galaxy on Fire | Razoon
Gewinner des BCC #57 User posted image

	Hip Teen	Mi, März 01, 2006 21:45 Antworten mit Zitat
Der Programmierstil ist so eine Sache. Du kannst hundert Programmierer in einen Raum stecken und diskutieren lassen. Dabei wirst du so ziemlich genau 100 verschiedene Meinungen hören. Denn genauso wie jeder eine andere Programmiersprache bevorzugt und man sich nach hunder Jahren immer noch nicht geeinigt hat, so ist es auch mit dem Programmierstil. Der eine schreibt die Kommentare lieber vor eine Funktion, der nächste innerhalb der Funktion an den Anfang. Der eine benutzt gerne Präfixe bei Variablen, der andere Postfixe. Die Liste kann man beliebig fortsetzen, bei solchen Sachen können sich Progammierer einfach nicht einigen. Im Grunde muss man sich da jeder selbst entscheiden, wie er es handhabt, sollte es aber einheitlich machen, das hilft ernorm. Zu der Herangehensweise hat Florian schon so ziemlich das wichtigste gesagt.
Spruch der Woche: "Ahh, ein neues Gesicht?!" - "Nein, das hab ich schon länger"

Hip Teen

Mi, März 01, 2006 21:45
Antworten mit Zitat

Der Programmierstil ist so eine Sache. Du kannst hundert Programmierer in einen Raum stecken und diskutieren lassen. Dabei wirst du so ziemlich genau 100 verschiedene Meinungen hören. Denn genauso wie jeder eine andere Programmiersprache bevorzugt und man sich nach hunder Jahren immer noch nicht geeinigt hat, so ist es auch mit dem Programmierstil. Der eine schreibt die Kommentare lieber vor eine Funktion, der nächste innerhalb der Funktion an den Anfang. Der eine benutzt gerne Präfixe bei Variablen, der andere Postfixe. Die Liste kann man beliebig fortsetzen, bei solchen Sachen können sich Progammierer einfach nicht einigen.
Im Grunde muss man sich da jeder selbst entscheiden, wie er es handhabt, sollte es aber einheitlich machen, das hilft ernorm.

Zu der Herangehensweise hat Florian schon so ziemlich das wichtigste gesagt.

Spruch der Woche: "Ahh, ein neues Gesicht?!" - "Nein, das hab ich schon länger"

	ke^kx	Mi, März 01, 2006 21:49 Antworten mit Zitat
@Fdm: So könntest du aber Problem bekommen, wenn du sehr viele ingame sachen hast, also einen riesiegen Batzen an Funktionen, in einem Include. (Schon klar, ich will dich damit nicht irgendwie anprangern, verbessern, belehren, bevormunden o.ä. Ich wollte es nur erwähnt haben) Ich persönlich mache es immer so, dass ich Funktions zu bestimmten Themen in einzelnen Includes habe (etwa script.bb, laden.bb, menü.bb, bewegung.bb... (sind nur beispiele)) und dann eine init.bb-file habe, in der alle Globals, Types, Dims... geladen werden. Außerdem gibt es das "Herzstück" des Programms, die main.bb-file. In ihr ist die Hauptschleife, mit ihren verschiedenen Gamestats (wie bei dir, fdm) und es wird auf verschieden Functions verwiesen (etwa lade_level () oder intro ()...). Ich hoffe das kann man einigermaßen verstehen^^ Jiriki
http://i3u8.blogspot.com Asus Striker II Intel Core2Quad Q9300 @ 2,5 GHz (aber nur zwei Kerne aktiv aufgrund der Instabilität -.-) Geforce 9800 GTX 2GB RAM

ke^kx

Mi, März 01, 2006 21:49
Antworten mit Zitat

@Fdm: So könntest du aber Problem bekommen, wenn du sehr viele ingame sachen hast, also einen riesiegen Batzen an Funktionen, in einem Include. (Schon klar, ich will dich damit nicht irgendwie anprangern, verbessern, belehren, bevormunden o.ä. Wink

Ich wollte es nur erwähnt haben)

Ich persönlich mache es immer so, dass ich Funktions zu bestimmten Themen in einzelnen Includes habe (etwa script.bb, laden.bb, menü.bb, bewegung.bb... (sind nur beispiele)) und dann eine init.bb-file habe, in der alle Globals, Types, Dims... geladen werden. Außerdem gibt es das "Herzstück" des Programms, die main.bb-file. In ihr ist die Hauptschleife, mit ihren verschiedenen Gamestats (wie bei dir, fdm) und es wird auf verschieden Functions verwiesen (etwa lade_level () oder intro ()...).

Ich hoffe das kann man einigermaßen verstehen^^
Jiriki

http://i3u8.blogspot.com
Asus Striker II
Intel Core2Quad Q9300 @ 2,5 GHz (aber nur zwei Kerne aktiv aufgrund der Instabilität -.-)
Geforce 9800 GTX
2GB RAM

	Firstdeathmaker	Mi, März 01, 2006 22:05 Antworten mit Zitat
Na, man muss ja nicht alles in einer Include-Datei haben. Die Spieldatei ist bei mir ja auch weiter unterteilt in verschiedene Bereiche. Und eine laden.bb oder eine menü.bb würde in die entsprechenden Bereiche eingelagert, die laden.bb z.B. in den GAMESTAT der das Lademenü darstellt. Und die Menü.bb ist insofern überflüssig, dass ich am Anfang in meinen Bibliotheken eine Menüengine lade über die ich im Spiel und in den anderen Menüs alles laufen lasse, insofern diese Globale gültigkeit besitzt und nicht nur für einen einzelnen speziellen Teil gecodet ist.
www.illusion-games.de Space War 3 \| Space Race \| Galaxy on Fire \| Razoon Gewinner des BCC #57 User posted image

Firstdeathmaker

Mi, März 01, 2006 22:05
Antworten mit Zitat

Na, man muss ja nicht alles in einer Include-Datei haben. Die Spieldatei ist bei mir ja auch weiter unterteilt in verschiedene Bereiche. Und eine laden.bb oder eine menü.bb würde in die entsprechenden Bereiche eingelagert, die laden.bb z.B. in den GAMESTAT der das Lademenü darstellt. Und die Menü.bb ist insofern überflüssig, dass ich am Anfang in meinen Bibliotheken eine Menüengine lade über die ich im Spiel und in den anderen Menüs alles laufen lasse, insofern diese Globale gültigkeit besitzt und nicht nur für einen einzelnen speziellen Teil gecodet ist.

www.illusion-games.de
Space War 3 | Space Race | Galaxy on Fire | Razoon
Gewinner des BCC #57 User posted image

	5k41	Fr, März 03, 2006 13:09 Antworten mit Zitat
@hectic: bei deinem Code-Style gibts ja eine Manager und eine Spiel (oder main? ) datei aber was kommt nun in die Main und was in die Manager? Ich mein gibts da ne Datei wo alle Funktionen drin sind oder kommen die aufgeteilt in die beiden Dateien? Erläutere vielleicht doch einfach deine Vorgehensweise nochmal ein bisschen genauer Danke! mfg!
Projekte: For a better World - Gesellschaftsspiel ( 100%) User posted image

5k41

Fr, März 03, 2006 13:09
Antworten mit Zitat

@hectic:
bei deinem Code-Style gibts ja eine Manager und eine Spiel (oder main? ) datei aber was kommt nun in die Main und was in die Manager? Ich mein gibts da ne Datei wo alle Funktionen drin sind oder kommen die aufgeteilt in die beiden Dateien? Erläutere vielleicht doch einfach deine Vorgehensweise nochmal ein bisschen genauer Wink

Danke!

mfg!

Projekte:
For a better World - Gesellschaftsspiel ( 100%)

User posted image

	hectic Sieger des IS Talentwettbewerb 2006	Fr, März 03, 2006 18:40 Antworten mit Zitat
Hi 5k41, mein Beispiel sollte ja auch nur ein `Beispiel´ sein... Jedes Spiel hat natürlich auch gewiß klein wenig andere Anforderungen... Aber um mal deine Frage zu beantworten... prepare beinhaltet Globale Variablendeklaration wie auch Dims oder Types. Am Ende dieser kommen alle Includes mit rein... manager ist dann das Menü und das was das Spielen soweit vorbereitet, wie das laden der Map aus einer Userauswahl (Also eine Art Main obwohl man auch von der prepare vom gewissen Main gesprochen werden kann. Da ich aber keine Lust auf Kilometerlange Codes habe, teile ich sie lieber auf). spielen ist dann das Game, also Bewegungssteuerung, Grafikdarstellung, Kollisionsabfrage etc... Alles andere sind dann andere Dinge die noch benötigt werden. zB zeichne für die Erstellung von dynamischen Meshes (zB Textmeshes etc...) oder loadmap und eventuell savemap und editor... Alle Includes bis auf manager und prepare sind nur komplette Funktionen... Aber wehe du machst es jetzt genauso wie ich... Was ich damit sagen will ist... Mache dir mal Gedanken wie du am besten mit deinem Code zurecht kommst. Ich selber habe recht lange dafür gebraucht um ein für mich sinnvolles Struktursystem auszuarbeiten...

hectic

Sieger des IS Talentwettbewerb 2006

Fr, März 03, 2006 18:40
Antworten mit Zitat

Hi 5k41, mein Beispiel sollte ja auch nur ein `Beispiel´ sein... Jedes Spiel hat natürlich auch gewiß klein wenig andere Anforderungen... Aber um mal deine Frage zu beantworten... prepare beinhaltet Globale Variablendeklaration wie auch Dims oder Types. Am Ende dieser kommen alle Includes mit rein... manager ist dann das Menü und das was das Spielen soweit vorbereitet, wie das laden der Map aus einer Userauswahl (Also eine Art Main obwohl man auch von der prepare vom gewissen Main gesprochen werden kann. Da ich aber keine Lust auf Kilometerlange Codes habe, teile ich sie lieber auf). spielen ist dann das Game, also Bewegungssteuerung, Grafikdarstellung, Kollisionsabfrage etc... Alles andere sind dann andere Dinge die noch benötigt werden. zB zeichne für die Erstellung von dynamischen Meshes (zB Textmeshes etc...) oder loadmap und eventuell savemap und editor... Alle Includes bis auf manager und prepare sind nur komplette Funktionen...

Aber wehe du machst es jetzt genauso wie ich... Very Happy

Was ich damit sagen will ist... Mache dir mal Gedanken wie du am besten mit deinem Code zurecht kommst. Ich selber habe recht lange dafür gebraucht um ein für mich sinnvolles Struktursystem auszuarbeiten...

	5k41	Sa, März 04, 2006 2:59 Antworten mit Zitat
mh... dachte ich mir schon das sowas kommt hab ich auch nicht vor, ich will mir halt nur ein paar anregungen holen, welche das Entwerfen des eigenen Styles erleichtern... danke erstmal für die genaue aufklärung!
Projekte: For a better World - Gesellschaftsspiel ( 100%) User posted image

5k41

Sa, März 04, 2006 2:59
Antworten mit Zitat

mh...
dachte ich mir schon das sowas kommt hab ich auch nicht vor, ich will mir halt nur ein paar anregungen holen, welche das Entwerfen des eigenen Styles erleichtern... danke erstmal für die genaue aufklärung!

Projekte:
For a better World - Gesellschaftsspiel ( 100%)

User posted image

	x-pressive	Sa, März 04, 2006 13:22 Antworten mit Zitat
Endlich mal ein sinnvolles Thema - finde ich toll, das sich mal jemand darüber Gedanken macht. Hier einige Tipps, wie ich das mache: Deutsch / Englisch Ich schreibe Kommentare, Variablen- und Funktionsnamen, also eigentlich alles, grundsätzlich in Englisch. Das macht es einfach, wenn man sich eines Tages dafür entschliesst, den Code zu verkaufen. Kommentare groß schreiben, sieht übersichtlicher aus und so sind sie besser zu finden. Variablennamen Variablen klein schreiben, einzelne Silben aber mit großem Anfangsbuchstaben. Ist übersichtlich. Auf Unterstriche in den Namen verzichte ich, da das bei vielen Variablen schnell wie Buchstabensalat aussieht. Bei GLOBALEN Variablen stelle ich ein kleines g davor, damit ich die jederzeit auf einen Blick erkenne: playerSize% --- lokale Variable gPlayerSpeed% --- globale Variable Objekte Objekte, Types und Entities groß schreiben. Ausserdem hat jeder Objekt-Typ bei mir eine Vorsilbe, an der ich erkenne, um was es sich handelt: Snd_Birds - Sounds beginnen mit Snd Mus_Song1 - Musik beginnt mit Mus Img_Title - Bilder (Images) beginnen mit Img Spr_Laser - Sprites mit Spr Ent_Ship - Entities (Modelle) mit Ent Tex_Wall - Texturen und so weiter... Die "Familiennamen" von Types beginnen bei mir mit einem großen T, damit man auf einen Blick sieht, das es sich hier um einen Type handelt. Eine einzelne Instanz eines Types beginnt ebenfalls mit einem grossen Buchstaben: Enemy.TEnemies Variablen in Funktionen Lokale Variablen in Funktionen immer schön sauber mit LOCAL am Anfang der Funktion definieren. So erkennt man auf einen Blick, welche Variablen man in dieser Funktion benutzt und verhindert Konflikte mit globalen Variabeln (die man aber eh schon verhindert, in dem man globale Variabeln mit einem kleinen g versieht). Einrücken Einrücken und Leerzeichen sind ULTRA-wichtig! Bei Schleifen, inerhalb Funktionen usw. wird grundsätzlich eingerückt. So erkennt man auf einen Blick, wo das Ding anfängt und wo es wieder endet. Leerzeichen benutzen, um verschiedene Zeilen optisch so anzupassen: Code: [AUSKLAPPEN] [EINKLAPPEN] ScaleMesh Ent_Ship,1000,700,1000 MoveEntity Ent_Ship,0,-25,0 EntityOrder Ent_Ship,1 FlipMesh Ent_Ship EntityFX Ent_Ship,1+8 PositionEntity Ent_Ship,0,100,0 Sieht viel ordentlicher aus! Funktionen und Programmabschnitte optisch hervorheben Über jeder Funktion setzte ich einen Kommentar, der so aussieht: Code: [AUSKLAPPEN] [EINKLAPPEN] ; ------------------------------------------------------------------ ; FUNCTION: LOAD AND CREATE 3D SCENE ; ------------------------------------------------------------------ Wenn jede Funktion so deutlich gekennzeichnet ist, kann man auch bei schnellem Durchscrollen durch den Code schnell einzelne Funktionen finden. Codestruktur Ein kompletter Code ist bei mir so strukturiert: Konstanten ------------------ (Trennlinie) Variablen ------------------ (Trennlinie) Hauptteil ------------------ (Trennlinie) Funtionen ------------------ (Trennlinie) Code aufteilen Wenn ein Code eine bestimmte Größe erreicht, gliedere ich alle Funktionen, die thematisch zusammenhängen in Include-Dateien aus. Beispielsweise alle Funktionen, die das Titelbild betreffen in eine Datei namens "inc_title.bb", alle Funktionen die die Spielerbewegung betreffen in eine Datei namens "inc_movement.bb", alle Funktionen, die Grafikdarstellung betreffen in "inc_render.bb" und so weiter. Die Hauptdatei wird "main.bb" genannt, damit man auch später noch weiss, welche Datei man öffnen muß, um alles zu kompilieren. WICHTIG: Wenn man Funktionen in mehrere Include-Dateien aufteilt, sollte man allen Funktionen, die sich in der selben Datei befinden, die gleiche Vorsilbe geben. Beispiel: alle Funktionen, die die Bildschirmanzeige (HUD) betreffen, sammelt man in einer Datei namens "inc_display.bb". Alle Funktionen darin sollten dann mit Display_ beginnen. Das hat den großen Vorteil, das man sofort weiß, in welcher Include-Datei man diese Funktion letztendlich findet. Dateinamen Im Media-Ordner kommen schnell viele Dateien zusammen. Auch hier schaffe ich Übersichtlichkeit, indem ich jeder Datei eine Vorsilbe gebe: snd_buttonclick.wav snd_gameover.wav mdl_ship.b3d mdl_enemy.3ds gfx_titlelogo.bmp So werden alle Dateiten im Explorer automatisch sortiert und untereinander angezeigt. Das macht es sehr viel übersichtlicher. Es gibt noch tausend weitere kleine Tipps, aber das nur mal auf die Schnelle.
• BLITZ SHOWCASE: PARTICLE CANDY • PARTICLE CANDY FOR iPHONE • SPRITE CANDY • DON'T GET ANGRY! 2-3 • CLICK CLACK XL

x-pressive

Sa, März 04, 2006 13:22
Antworten mit Zitat

Endlich mal ein sinnvolles Thema - finde ich toll, das sich mal jemand darüber Gedanken macht. Hier einige Tipps, wie ich das mache:

Deutsch / Englisch
Ich schreibe Kommentare, Variablen- und Funktionsnamen, also eigentlich alles, grundsätzlich in Englisch. Das macht es einfach, wenn man sich eines Tages dafür entschliesst, den Code zu verkaufen. Kommentare groß schreiben, sieht übersichtlicher aus und so sind sie besser zu finden.

Variablennamen
Variablen klein schreiben, einzelne Silben aber mit großem Anfangsbuchstaben. Ist übersichtlich. Auf Unterstriche in den Namen verzichte ich, da das bei vielen Variablen schnell wie Buchstabensalat aussieht. Bei GLOBALEN Variablen stelle ich ein kleines g davor, damit ich die jederzeit auf einen Blick erkenne:

playerSize% --- lokale Variable
gPlayerSpeed% --- globale Variable

Objekte
Objekte, Types und Entities groß schreiben. Ausserdem hat jeder Objekt-Typ bei mir eine Vorsilbe, an der ich erkenne, um was es sich handelt:

Snd_Birds - Sounds beginnen mit Snd
Mus_Song1 - Musik beginnt mit Mus
Img_Title - Bilder (Images) beginnen mit Img
Spr_Laser - Sprites mit Spr
Ent_Ship - Entities (Modelle) mit Ent
Tex_Wall - Texturen

und so weiter...

Die "Familiennamen" von Types beginnen bei mir mit einem großen T, damit man auf einen Blick sieht, das es sich hier um einen Type handelt. Eine einzelne Instanz eines Types beginnt ebenfalls mit einem grossen Buchstaben:

Enemy.TEnemies

Variablen in Funktionen
Lokale Variablen in Funktionen immer schön sauber mit LOCAL am Anfang der Funktion definieren. So erkennt man auf einen Blick, welche Variablen man in dieser Funktion benutzt und verhindert Konflikte mit globalen Variabeln (die man aber eh schon verhindert, in dem man globale Variabeln mit einem kleinen g versieht).

Einrücken
Einrücken und Leerzeichen sind ULTRA-wichtig! Bei Schleifen, inerhalb Funktionen usw. wird grundsätzlich eingerückt. So erkennt man auf einen Blick, wo das Ding anfängt und wo es wieder endet.

Leerzeichen benutzen, um verschiedene Zeilen optisch so anzupassen:
Code: [AUSKLAPPEN]

ScaleMesh Ent_Ship,1000,700,1000
MoveEntity Ent_Ship,0,-25,0
EntityOrder Ent_Ship,1
FlipMesh Ent_Ship
EntityFX Ent_Ship,1+8
PositionEntity Ent_Ship,0,100,0

Sieht viel ordentlicher aus!

Funktionen und Programmabschnitte optisch hervorheben
Über jeder Funktion setzte ich einen Kommentar, der so aussieht:

Code: [AUSKLAPPEN]

; ------------------------------------------------------------------
; FUNCTION: LOAD AND CREATE 3D SCENE
; ------------------------------------------------------------------

Wenn jede Funktion so deutlich gekennzeichnet ist, kann man auch bei schnellem Durchscrollen durch den Code schnell einzelne Funktionen finden.

Codestruktur
Ein kompletter Code ist bei mir so strukturiert:

Konstanten
------------------ (Trennlinie)
Variablen
------------------ (Trennlinie)
Hauptteil
------------------ (Trennlinie)
Funtionen
------------------ (Trennlinie)

Code aufteilen
Wenn ein Code eine bestimmte Größe erreicht, gliedere ich alle Funktionen, die thematisch zusammenhängen in Include-Dateien aus. Beispielsweise alle Funktionen, die das Titelbild betreffen in eine Datei namens "inc_title.bb", alle Funktionen die die Spielerbewegung betreffen in eine Datei namens "inc_movement.bb", alle Funktionen, die Grafikdarstellung betreffen in "inc_render.bb" und so weiter.

Die Hauptdatei wird "main.bb" genannt, damit man auch später noch weiss, welche Datei man öffnen muß, um alles zu kompilieren.

WICHTIG: Wenn man Funktionen in mehrere Include-Dateien aufteilt, sollte man allen Funktionen, die sich in der selben Datei befinden, die gleiche Vorsilbe geben. Beispiel: alle Funktionen, die die Bildschirmanzeige (HUD) betreffen, sammelt man in einer Datei namens "inc_display.bb". Alle Funktionen darin sollten dann mit Display_ beginnen. Das hat den großen Vorteil, das man sofort weiß, in welcher Include-Datei man diese Funktion letztendlich findet.

Dateinamen
Im Media-Ordner kommen schnell viele Dateien zusammen. Auch hier schaffe ich Übersichtlichkeit, indem ich jeder Datei eine Vorsilbe gebe:

snd_buttonclick.wav
snd_gameover.wav
mdl_ship.b3d
mdl_enemy.3ds
gfx_titlelogo.bmp

So werden alle Dateiten im Explorer automatisch sortiert und untereinander angezeigt. Das macht es sehr viel übersichtlicher.

Es gibt noch tausend weitere kleine Tipps, aber das nur mal auf die Schnelle.

• BLITZ SHOWCASE:
PARTICLE CANDY • PARTICLE CANDY FOR iPHONE • SPRITE CANDY • DON'T GET ANGRY! 2-3 • CLICK CLACK XL

Zuletzt bearbeitet von x-pressive am Mo, März 06, 2006 17:23, insgesamt 2-mal bearbeitet

	5k41	Sa, März 04, 2006 13:36 Antworten mit Zitat
Super! Sowas hab ich gebraucht! Vielen Danke X-Pressive! Mal einfach ne komplette Richtlinie und nicht immer dieses komisch man könnte es so machen aber mach das nicht so usw. . Du hast was von 1000 weiteren kleinen Tipps geschrieben und wenn du Lust/Zeit hast könntest du auch davon mir ja noch ne kleine Auswahl schreiben, würde mich sehr freuen! nochmals Danke! mfg
Projekte: For a better World - Gesellschaftsspiel ( 100%) User posted image

5k41

Sa, März 04, 2006 13:36
Antworten mit Zitat

Super! Sowas hab ich gebraucht! Vielen Danke X-Pressive!
Mal einfach ne komplette Richtlinie und nicht immer dieses komisch man könnte es so machen aber mach das nicht so usw. . Du hast was von 1000 weiteren kleinen Tipps geschrieben und wenn du Lust/Zeit hast könntest du auch davon mir ja noch ne kleine Auswahl schreiben, würde mich sehr freuen!

nochmals Danke!

mfg

Projekte:
For a better World - Gesellschaftsspiel ( 100%)

User posted image

	Hip Teen	Sa, März 04, 2006 17:51 Antworten mit Zitat
Jo, die Tipps von X-Pressive sind sehr gut, mach das meiste genauso. Sollte aber auch mal die globalen Variablen irgendwie markieren, dürfte schon sinnvoll sein Nur benutz ich zum einrücken Tabs. Habs früher auch mit Leerzeichen gemacht, aber mit Tabs geht das wesentlich schneller. Zudem verliert man die Formatierung nicht so schnell verloren, besonders wenn man irgendwo posten, wo mehrere Leerzeichen hintereinander verschluckt werden. Was ich aber scheinbar komplett anders mache, wie alle anderen: Ich deklarier Globale Variablen und Types nicht in einer extra Include oder in der Haupdatei, sondern in den Includes, in denen ich sie brauche. So hab ich immer genau das zur Hand, was ich gerade brauch. Liegt aber auch daran, dass ich schnell mal vergesse, wie ich eigentlich meine Variablen genannt habe So kann ich dann schneller nachgucken
Spruch der Woche: "Ahh, ein neues Gesicht?!" - "Nein, das hab ich schon länger"

Hip Teen

Sa, März 04, 2006 17:51
Antworten mit Zitat

Jo, die Tipps von X-Pressive sind sehr gut, mach das meiste genauso. Sollte aber auch mal die globalen Variablen irgendwie markieren, dürfte schon sinnvoll sein Laughing

Nur benutz ich zum einrücken Tabs. Habs früher auch mit Leerzeichen gemacht, aber mit Tabs geht das wesentlich schneller. Zudem verliert man die Formatierung nicht so schnell verloren, besonders wenn man irgendwo posten, wo mehrere Leerzeichen hintereinander verschluckt werden.

Was ich aber scheinbar komplett anders mache, wie alle anderen: Ich deklarier Globale Variablen und Types nicht in einer extra Include oder in der Haupdatei, sondern in den Includes, in denen ich sie brauche. So hab ich immer genau das zur Hand, was ich gerade brauch. Liegt aber auch daran, dass ich schnell mal vergesse, wie ich eigentlich meine Variablen genannt habe Embarassed

So kann ich dann schneller nachgucken Razz

Spruch der Woche: "Ahh, ein neues Gesicht?!" - "Nein, das hab ich schon länger"

	HW	Sa, März 04, 2006 17:59 Antworten mit Zitat
Ich muss sagen, dass X-pressives Art und Weise wirklich gut ist. Von so etwas kann z.B. ich noch eine Menge lernen. Ich stimme Hip Teen diesbezüglich wirklich zu. Allerdings deklariere ich wie die anderen auch Variablen etc. in einer einzigen Include und anders als X-Pressive dekariere ich die Konstanten und Variablen zusammen und trenne die Programmteile nicht mit Trennstrichen, sondern mit Includes. Aber das System ist wirklich einwandfrei.

HW

Sa, März 04, 2006 17:59
Antworten mit Zitat

Ich muss sagen, dass X-pressives Art und Weise wirklich gut ist. Von so etwas kann z.B. ich noch eine Menge lernen. Ich stimme Hip Teen diesbezüglich wirklich zu. Allerdings deklariere ich wie die anderen auch Variablen etc. in einer einzigen Include und anders als X-Pressive dekariere ich die Konstanten und Variablen zusammen und trenne die Programmteile nicht mit Trennstrichen, sondern mit Includes. Aber das System ist wirklich einwandfrei.

Gehe zu Seite 1, 2 Weiter

Übersicht

BlitzBasic

Allgemein

Nach Oben

BlitzBasic Portal

Codestyle

Betreff: Codestyle

Betreff: Re: Codestyle