Ich eröffne hiermit die PMBC "Pure Muppets Basic Crew". 1.Vorsitzende wird die glamouröse Schweine-Diva Miss Piggy.Sebe hat geschrieben:PureBasic Demo Coder Crew
Progschmiede
-
xperience2003
- Beiträge: 972
- Registriert: 04.10.2004 18:42
- Computerausstattung: Amiga, LinuxMint, Windows7
- Wohnort: gotha
- Kontaktdaten:
@PureBasic 4.0:
Ich bin nicht der Webmaster. Und was redest du da eigentlich? Nur Admins können in einem bestimmten Bereich posts lesen und schreiben.
Und ein ganzes komplexes Spiel zu programmieren wäre für den Anfang nicht sehr leicht. Schließlich kann nicht jeder mega Models und Texturen erstellen.
Aber eine andere Frage mal an die Leute, die hier die ganzen Sprüche ziehen: Habt Ihr denn schonmal in einem Team gearbeitet um zu sagen, mit was man anfangen soll und was man später tun soll? Ich wollte nur Fragen, wer noch Lust hätte und da kommen gleich fiese Kommentare.
Ich bin nicht der Webmaster. Und was redest du da eigentlich? Nur Admins können in einem bestimmten Bereich posts lesen und schreiben.
Du bist doch im BlitzForum, oder? Komisch, dass du sowas schreibst. Da wurde sowas schon öfters besprochen.Wer hat euch denn sowas erzählt, ROFL!
Entweder seid ihr verdammt leichtgläubig oder ihr hattet wirklich keine besseren Ausreden. Meine kleine Schwester darf auch Gears Of War 2 programmieren wenn sie will (und sie programmieren könnte). Wer sollte ihr das denn bitte verbieten Rolling Eyes
Mal abgesehen davon, dass es sogar Egoshooter ab 12 Jahren gibt, World Of Warcraft is auch ab 12 (ok, blödes Beispiel für ein Projekt), Ragnarok Online ist ebenfalls ab 12 und Guild Wars auch. Viele Echtzeit und Rundenbasierten Strategiespiele sind ab 12 Jahren freigegeben also gibt es da auch genügend potentielle Spieleideen, die ihr verfolgen könntet wenn ihr keine Spiele ab 18 Jahren entwickeln dürftet (was nicht der Fall ist, streng genommen ist nämlich jedes nichtkommerzielle Spiel ein Fall für "ab 18" mangels USK Prüfung).
Und ein ganzes komplexes Spiel zu programmieren wäre für den Anfang nicht sehr leicht. Schließlich kann nicht jeder mega Models und Texturen erstellen.
Aber eine andere Frage mal an die Leute, die hier die ganzen Sprüche ziehen: Habt Ihr denn schonmal in einem Team gearbeitet um zu sagen, mit was man anfangen soll und was man später tun soll? Ich wollte nur Fragen, wer noch Lust hätte und da kommen gleich fiese Kommentare.
Zuletzt geändert von X0r am 03.07.2007 20:01, insgesamt 1-mal geändert.
-
PureBasic4.0
- Beiträge: 785
- Registriert: 29.10.2006 17:26
- Wohnort: 127.0.0.1
Ja, auf bestimmte. Es gibt aber auch andere, auf die man nur als Admin zugreifen kann. Falls du es mit deinem bisherigen Wissen über Simple Machines geschafft haben solltest, das board zu hacken, kannst du ja simple machines ne mail schreiben. Die werden stolz auf dich sein. 
Andere Frage: Da du ja wunderbare Kommetare abgeben kannst und lachen kannst, kannst du mir ja erklären, was genau du eigentlich meinst? Welche Foren sollten denn unsichtbar für normale User sein?
Wir haben ja nicht die geringste Ahnung.
Für mich ist die Sache jetzt geklärt. Anscheinend hat keiner Lust. Gut.
Von mir aus kann der thread gelöscht werden.
Andere Frage: Da du ja wunderbare Kommetare abgeben kannst und lachen kannst, kannst du mir ja erklären, was genau du eigentlich meinst? Welche Foren sollten denn unsichtbar für normale User sein?
Wir haben ja nicht die geringste Ahnung.
Für mich ist die Sache jetzt geklärt. Anscheinend hat keiner Lust. Gut.
Von mir aus kann der thread gelöscht werden.
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
Hey, Forgee-Boy, spiel net glei wieder die Leberwurst....
> streng genommen ist nämlich jedes nichtkommerzielle Spiel ein Fall für "ab 18" mangels USK Prüfung
triftt meines wissens einfach zu.
keiner kann dich daran hindern, als zwölfjähriger ein game zu schreiben, wo du leute blutig töten musst.
zur vermarktung brauchst du generell jemanden voll geschäftsfähigen, auch für ein ab-3-game....
> streng genommen ist nämlich jedes nichtkommerzielle Spiel ein Fall für "ab 18" mangels USK Prüfung
triftt meines wissens einfach zu.
keiner kann dich daran hindern, als zwölfjähriger ein game zu schreiben, wo du leute blutig töten musst.
zur vermarktung brauchst du generell jemanden voll geschäftsfähigen, auch für ein ab-3-game....
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
Habt Ihr denn schonmal in einem Team gearbeitet um zu sagen, mit was man anfangen soll und was man später tun soll?
Das hängt eben ganz von den Fähigkeiten der Leute ab. So pauschal läßt sich das nicht sagen. Vielleicht wäre es halt mal ganz gut, wenn ihr euch einfach gegenseitig das Zeug, das ihr bisher schon selbst gemacht habt, zuschickt oder hochladet, ich denke, dann kann man das besser einschätzen.
Dann könnt ihr euch überlegen, was ihr nun in Angriff nehmen wollt. Letztendlich ist die Planung einer der wichtigsten Punkte, sogar wichtiger als die Implementierung. Denn bei guter Planung könnt ihr, wenn einer oder mehrere abspringen, auch später neue Leute ins Boot holen, und möglichst reibungslos weitermachen.
Teamarbeit ist nicht immer leicht, das weiß ich aus eigener Erfahrung. Besonders, wenn Leute im Team sind, die nicht viel draufhaben. Daher sollte man möglichst schon vorher festlegen, wer woran arbeitet, damit es nicht zu solchen Dingen wie "och mann, kriegt der's jetzt endlich mal gebacken" kommt.
Um einen Einstieg zu finden, könnt ihr euch ja auch erstmal ein Projekt aussuchen, das zwar cool ist, aber bei dem ihr denkt "das haben wir sowieso in 4 Wochen fertig". Dann könnt ihr sehen, wie ihr miteinander arbeitet, und bereits aus diesem Projekt fürs nächste lernen. Bei den 4 Wochen wird's höchstwahrscheinlich eh nicht bleiben
aber notfalls kann man's ja auch abbrechen. Aber dann habt ihr wenigstens ein paar Erfahrungen machen dürfen, und kriegt das beim größeren Projekt vielleicht sogar schon besser hin.
Am besten wäre, ihr wählt einen als Projektleiter aus, am besten den, der am meisten Ahnung von Programmierung bzw. Software-Architektur hat. Der sollte sich dann das Projekt mal aufskizzieren und in einzelne Module unterteilen, Schnittstellen definieren, Klassen bzw. Strukturen festlegen, das ganze am besten nochmal 3x durchdenken, und dann wird entschieden, wer welchen Teil machen darf. Das ganze Gerüst wird sich während der Implementierung so oder so noch ein bißchen ändern, das läßt sich eigentlich nie vermeiden, aber das sollte vorerst mal nicht stören. Wichtig ist, daß man eine Grundplanung hat. Wenn sich jedoch bestimmte Dinge massiv verändern, sollte auch die Planung wieder entsprechend angepaßt werden.
Wie Du die Aufgaben verteilst, hängt natürlich vom Projekt ab, aber generell sollte die GUI von der eigentlichen Logik getrennt sein (was natürlich nicht heißen muß, daß das dann auch zwei verschiedene Programmierer machen müssen, nur mal als Anmerkung). Dann gibt's ja noch viele weitere Untermodule, wie z.B. das Hilfesystem, das Speichern/Öffnen, dann gibt's Leute, die testen müssen (testen kann man auch als Programmierer, indem man kleine Programme schreibt, die bestimmte Funktionen aufrufen und deren Ergebnisse auswerten - in bestimmten Bereichen ist das sinnvoll). Und zu guter Letzt werden auch oft Tools benötigt, die man programmieren kann. Diese sind dann oftmals etwas losgelöster vom eigentlichen Projekt (bei einem Spiel z.B. der Leveleditor, der oft im Spiel drin sitzt, aber dennoch ein sehr eigenes Programm darstellt), das ist oft eine gute Aufgabe für diejenigen, die mit Teamarbeit nicht ganz so gut zurechtkommen und gerne in bestimmter Weise ihr eigenes Ding machen wollen.
Wir haben neulich ein Spiel an der Schule programmiert, in einem 6-Mann-Team. Hier war es so, daß drei von uns richtig programmieren konnten, davon haben zwei an der Engine gearbeitet und einer hat sich um Netzwerk-Highscore und Level-Editor gekümmert. Von den anderen drei hat einer komplett Grafiken erstellt, der andere hauptsächlich dokumentiert und einer war Projektleiter und hat sich um den ganzen Verwaltungskram gekümmert (also besonders das, was von schulischer Seite verlangt war - das ist bei euch zum Glück nicht so viel, also nehmt bei euch lieber einen Projektleiter, der Ahnung vom Programmieren hat und das Projekt plant). Das lief eigentlich ganz gut soweit, aber wir haben uns auch richtig treffen können. Online wäre das sicherlich schwieriger gewesen. Hin und wieder gab es auch Überschneidungen, was die Aufgaben anging, aber insgesamt war es doch recht gut aufgeteilt, und es wußte eigentlich jeder, was er zu tun hat.
Noch ein Tip, besorgt euch SVN oder was vergleichbares, um euren Code zu verwalten. Das war jetzt in unserem Fall nicht nötig (waren ja nur zwei Engine-Programmierer, und wir saßen meist vor einem Rechner), aber bei euch ist das Pflicht, sonst vergeht euch ziemlich schnell die Laune
Das hängt eben ganz von den Fähigkeiten der Leute ab. So pauschal läßt sich das nicht sagen. Vielleicht wäre es halt mal ganz gut, wenn ihr euch einfach gegenseitig das Zeug, das ihr bisher schon selbst gemacht habt, zuschickt oder hochladet, ich denke, dann kann man das besser einschätzen.
Dann könnt ihr euch überlegen, was ihr nun in Angriff nehmen wollt. Letztendlich ist die Planung einer der wichtigsten Punkte, sogar wichtiger als die Implementierung. Denn bei guter Planung könnt ihr, wenn einer oder mehrere abspringen, auch später neue Leute ins Boot holen, und möglichst reibungslos weitermachen.
Teamarbeit ist nicht immer leicht, das weiß ich aus eigener Erfahrung. Besonders, wenn Leute im Team sind, die nicht viel draufhaben. Daher sollte man möglichst schon vorher festlegen, wer woran arbeitet, damit es nicht zu solchen Dingen wie "och mann, kriegt der's jetzt endlich mal gebacken" kommt.
Um einen Einstieg zu finden, könnt ihr euch ja auch erstmal ein Projekt aussuchen, das zwar cool ist, aber bei dem ihr denkt "das haben wir sowieso in 4 Wochen fertig". Dann könnt ihr sehen, wie ihr miteinander arbeitet, und bereits aus diesem Projekt fürs nächste lernen. Bei den 4 Wochen wird's höchstwahrscheinlich eh nicht bleiben
aber notfalls kann man's ja auch abbrechen. Aber dann habt ihr wenigstens ein paar Erfahrungen machen dürfen, und kriegt das beim größeren Projekt vielleicht sogar schon besser hin.Am besten wäre, ihr wählt einen als Projektleiter aus, am besten den, der am meisten Ahnung von Programmierung bzw. Software-Architektur hat. Der sollte sich dann das Projekt mal aufskizzieren und in einzelne Module unterteilen, Schnittstellen definieren, Klassen bzw. Strukturen festlegen, das ganze am besten nochmal 3x durchdenken, und dann wird entschieden, wer welchen Teil machen darf. Das ganze Gerüst wird sich während der Implementierung so oder so noch ein bißchen ändern, das läßt sich eigentlich nie vermeiden, aber das sollte vorerst mal nicht stören. Wichtig ist, daß man eine Grundplanung hat. Wenn sich jedoch bestimmte Dinge massiv verändern, sollte auch die Planung wieder entsprechend angepaßt werden.
Wie Du die Aufgaben verteilst, hängt natürlich vom Projekt ab, aber generell sollte die GUI von der eigentlichen Logik getrennt sein (was natürlich nicht heißen muß, daß das dann auch zwei verschiedene Programmierer machen müssen, nur mal als Anmerkung). Dann gibt's ja noch viele weitere Untermodule, wie z.B. das Hilfesystem, das Speichern/Öffnen, dann gibt's Leute, die testen müssen (testen kann man auch als Programmierer, indem man kleine Programme schreibt, die bestimmte Funktionen aufrufen und deren Ergebnisse auswerten - in bestimmten Bereichen ist das sinnvoll). Und zu guter Letzt werden auch oft Tools benötigt, die man programmieren kann. Diese sind dann oftmals etwas losgelöster vom eigentlichen Projekt (bei einem Spiel z.B. der Leveleditor, der oft im Spiel drin sitzt, aber dennoch ein sehr eigenes Programm darstellt), das ist oft eine gute Aufgabe für diejenigen, die mit Teamarbeit nicht ganz so gut zurechtkommen und gerne in bestimmter Weise ihr eigenes Ding machen wollen.
Wir haben neulich ein Spiel an der Schule programmiert, in einem 6-Mann-Team. Hier war es so, daß drei von uns richtig programmieren konnten, davon haben zwei an der Engine gearbeitet und einer hat sich um Netzwerk-Highscore und Level-Editor gekümmert. Von den anderen drei hat einer komplett Grafiken erstellt, der andere hauptsächlich dokumentiert und einer war Projektleiter und hat sich um den ganzen Verwaltungskram gekümmert (also besonders das, was von schulischer Seite verlangt war - das ist bei euch zum Glück nicht so viel, also nehmt bei euch lieber einen Projektleiter, der Ahnung vom Programmieren hat und das Projekt plant). Das lief eigentlich ganz gut soweit, aber wir haben uns auch richtig treffen können. Online wäre das sicherlich schwieriger gewesen. Hin und wieder gab es auch Überschneidungen, was die Aufgaben anging, aber insgesamt war es doch recht gut aufgeteilt, und es wußte eigentlich jeder, was er zu tun hat.
Noch ein Tip, besorgt euch SVN oder was vergleichbares, um euren Code zu verwalten. Das war jetzt in unserem Fall nicht nötig (waren ja nur zwei Engine-Programmierer, und wir saßen meist vor einem Rechner), aber bei euch ist das Pflicht, sonst vergeht euch ziemlich schnell die Laune
ZeHa hat bisher kein Danke erhalten.
Klicke hier, wenn Du wissen möchtest, woran ihm das vorbeigeht.
@ Forge
ich schließe mich ZEHAs Worten an. Lehrne diese Sätze am besten auswendig.
Sei nicht böse wenn es hier kritik hagelt. Ich find es toll was ihr schon geschafft habt.
Mein Angebot steht noch, soweit ich euch helfen kann.
Braucht ihr noch ne coole Idee?
Was haltet ihr von der möglichkeit Drucker und Scanner zum datenaustausch zu benutzen? Keine gedruckten Buchstaben die man wieder einscannt, sondern einzelne Punkte bilden die Bits. So ein Moderner Drucker hat ja ne wahnsinns auflösung an DOTs/inch. Damit dürfte einiges an Daten auf ein A4 Blatt passen.
Und natürlich wieder anders herum, müssen die Zeilen vom scanner wieder eingelesen und in einer Datei geschrieben werden. könnt ja mal ausreizen welche auflösung wirklich fehlerfrei funktioniert.
Ich habe keine ahnung ob leicht oder schwer. sinnvoll oder nicht.
Aber die Idee find ich irgendwie cool. Und das Medium ist langlebig.
Dieter
ich schließe mich ZEHAs Worten an. Lehrne diese Sätze am besten auswendig.
Sei nicht böse wenn es hier kritik hagelt. Ich find es toll was ihr schon geschafft habt.
Mein Angebot steht noch, soweit ich euch helfen kann.
Braucht ihr noch ne coole Idee?
Was haltet ihr von der möglichkeit Drucker und Scanner zum datenaustausch zu benutzen? Keine gedruckten Buchstaben die man wieder einscannt, sondern einzelne Punkte bilden die Bits. So ein Moderner Drucker hat ja ne wahnsinns auflösung an DOTs/inch. Damit dürfte einiges an Daten auf ein A4 Blatt passen.
Und natürlich wieder anders herum, müssen die Zeilen vom scanner wieder eingelesen und in einer Datei geschrieben werden. könnt ja mal ausreizen welche auflösung wirklich fehlerfrei funktioniert.
Ich habe keine ahnung ob leicht oder schwer. sinnvoll oder nicht.
Aber die Idee find ich irgendwie cool. Und das Medium ist langlebig.
Dieter
>Sei nicht böse wenn es hier kritik hagelt. Ich find es toll was ihr schon geschafft habt.
Ich bin eigentlich nicht böse. Aber wenn wir vom Thema abkommen und zum OT übergehen und einige Leute mit ihren komischen Ideen (Muppets, Demo Coder) rumscherzen, dann kann man auch nicht erwarten, dass hier jemand etwas dazulernt.
Ich bin eigentlich nicht böse. Aber wenn wir vom Thema abkommen und zum OT übergehen und einige Leute mit ihren komischen Ideen (Muppets, Demo Coder) rumscherzen, dann kann man auch nicht erwarten, dass hier jemand etwas dazulernt.
