Beiträge von gandro

Zitat von xchrissix95

Also HTTP funktioniert hervoragend.

An sich müsste HTTP funktionieren ja.

Auch wenn das nicht ganz deutlich rüberkommt hier im Thread: Es gibt keine Zwangsumleitung auf HTTPS.

$ wget --quiet --spider --server-response http://www.winhistory-forum.net
  [b]HTTP/1.1 200 OK[/b]
  Content-Type: text/html; charset=UTF-8
  Cache-Control: private
  Pragma: private
  X-UA-Compatible: IE=7
  Connection: keep-alive
  Date: Tue, 08 Mar 2011 20:04:15 GMT
  Server: lighttpd/1.4.28

Dass manche umgeleitet werden, muss ein Bug sein, jedenfalls ist das nichts absichtliches. Es sei denn, TAL hat sonst was Gefrickelt, davon wüsste ich aber nichts.

Ja, weil das Spiel vermutlich mindestens 1-1,5GB RAM will.

Der virtuelle Speicher verhält sich ja dann aus Sicht des Spiels wie echter Arbeitsspeicher, nur dass der Zugriff auf die in den virtuellen Speicher geladenen Daten dann total langsam ist, weil der Rechner die Daten von der Platte lesen muss; und das Spiel deswegen vermutlich teilweise ruckelt.

Von den Dateirechten her müsste alles passen meint TAL. Bei mir funktioniert an sich auch alles - könnt ihr ggf. mal nen Link zu nem Testbild geben was nich hochgeladen werden will?

Ich bin heinzes Meinung. Als einer, der in der Pampa aufgewachsen ist (kein ÖPNV dort).

Eine grossartige Aufnahme die ich noch gar nicht kannte:

YouTube - Rio Reiser der Traum ist aus Live @ Seelenbinderhalle Berlin

Der einzige Auftritt von Rio Reiser in der DDR 1988, bei dem er "Der Traum ist aus" spielt, ein Lied, was sich ursprünglich auf die BRD der 70er-Jahre bezog, hier bei der Aufnahme aber genau auf den Nerv der DDR und des Publikums traf. Hört selbst, gibt Gänsehaut.

Nunja, die Umfrage ist bei 16:14 fürs vB4 stagniert, wie jeder sehen kann.

Die Frage ist, ob alle die fürs vB4 gestimmt haben, nach wie vor fürs vB4 stimmen würden, selbst wenn das IPB von den 11 Leuten bezahlt würde. Ich gehe davon aus, dass eine zweite Umfrage ähnlich knapp fürs vB4 ausgeht.

Eine erneute Umfrage ob vB4 oder IPB (unabhängig der Finanzierung, da diese an sich gelöst ist) kommt nur dann in Frage, wenn hier jetzt genügend Leute sagen, sie hätten bei der Umfrage zwar fürs vB4 gestimmt, würden aber, wo sich genügend Spender gefunden haben, doch fürs IPB stimmen.

In C++ ist es einfacher, aber da kann ich kaum Support geben, hab da nie viel mit gemacht. Aber da müsste es in etwa folgendes sein:

#include <iostream>
using namespace std;
int main(void) {
   string password;
   cout << "Enter your password: ";
   cin >> password;
   if(password == "bla") {
     cout << "Permission granted" << endl;
   }
   return 0;
}

C++-Strings halt, sind bisschen einfacher.

Wie gesagt, String-Handling in C ist mühsam, schau mal hier, da hats nen Beispiel was deinem recht ähnlich ist: Galileo Computing :: C von A bis Z – 11.12 Einlesen von Strings

Mehrere Zeichen hintereinander sind eine Zeichenkette, oder auf englisch eben String.

In C ist das String-Handling etwas mühsam, in C++ ist es weniger schlimm.

Generell müsstest du aber das Passwort irgendwie als String einlesen und dann mit der Funktion strcmp() (bzw. bei C++ mit dem == Operator) vergleichen.

Wie man unter Windows allerdings nen String in der Konsole einliest, ohne dass der beim Eingeben angezeigt wird, weiss ich gerade nicht.
Unter UNIX gäbe es desweiteren auch noch die Funktion getpass(), kA ob die bei Windows auch irgendwo versteckt ist.

Du brauchst kein scanf.

C/C++ macht keinen Unterschied zwischen Zeichen und Zahlen, Bits sind Bits, wie man sie interpretiert ist die Frage.

Es reicht eigentlich schon, einfach der der printf-Ausgabe die Variable als Zeichen (%c) und nicht als Dezimalzahl (%d) auszugeben. Ansonsten kannst du die Variable auch nach unsigned char casten, wenn das Auslesen erfolgreich war (zahl != EOF).

Nachtrag: Okay, ich habe erst jetzt gesehen, dass du die Werte danach auch vergleichst. Wenn deine Tastatureingabe immer eine Zahl sein soll, insbesondere auch eine mit mehr als einem Zeichen, dann kannst du durchaus scanf verwenden.

ARM und MS Office wurde schon ewig offiziell bestätigt.

Thema

Windows 8 (WinNT) kommt für ARM!

Jahre nach Einstellung des Alpha und PPC-Ports, und kurz vor der Versenkung der Itanic, gibts endlich mal wieder eine Nicht-Intel-Builds von Windows NT:

http://www.microsoft.com/presspass/pres…SOCsupport.mspx

Dieses Mal ist es kein Gerücht (siehe Pressemitteilung oben); und soll mit der nächsten Windows-Version kommen. Nebenbei wird MS Office ebenfalls für ARM rauskommen.

Das sind ja mal echt interessante Windows-News. Mal schauen, wie sich das generell entwickelt. Viel mehr fällt mir spontan…

gandro

6. Januar 2011 um 00:35

YouTube - Amplifier - Interstellar

Irgendwie mag ich dieses Progressive-Zeugs in letzter Zeit einfach.

Zitat von niwax

Aber nur, wenn man gegen Bots spielt. echte Spieler sollten das doch selbst finden, man könnte einfach auswählen, auf welcher Seite man spielen möchte.

Wir sprechen von Tower-Defense. Da ist eigentlich immer so, dass die Creeps vom Computer gesteuert werden, selbst wenn sie einem Spieler gehören (was bei uns ja aber vorerst nicht der Fall sein wird).

Okay, ich dumpe hier dann mal noch alle restlichen Gedanken die ich so hatte:

Generell Spielprinzip: Es gibt eine zu verteidigende Basis in der Mitte der Karte. computergesteuerte Viecher strömen herein und gehen auf die Basis los, mit dem Ziel diese zu erreichen. Haben genügend Creeps die Basis erreicht, ist das Spiel verloren.

Multiplayer würde also so funktionieren, dass es zwar ein gemeinsames zu verteidigendes Hauptquartier gibt, aber jeder Spieler sein eigenes Einfallstor hat, das er mit Geschütztürmen verteidigen muss und wo er Geld für getötete Viecher kriegt.

Internals:

Spielfeld also wie gesagt ein Raster aus aus Kästchen, die für Creeps (die Viecher) betretbar sind oder nicht, und falls sie betretbar sind, ob sie auch bebaubar sind. Ich würde empfehlen das Raster recht grob zu machen, um die Wegfindung weniger rechenintensiv zu machen, dafür können Creeps dann Positionen von 1/4 eines Kästchens oder so besitzen (also 1 Gebäudefeld = 4x4 Creepfelder).

Protokoll: Das ich gelesen habe ist TCP für RTS-artige Multiplayerspiele ausreichend gut. UDP alleine wäre zu wenig und der Geschwindigkeitsvorteil den Programmier-Aufwand nicht wert: RTS Multiplayer - GameDev.net

Die Position (aka Wegfindung) der Creeps würde vom Server berrechnet, so dass der Client die nur darstellt. Ist davon auszugehen, dass es verschiedene Clients gibt, also macht das wenig Sinn dass da die Clients all zu viel bestimmen.

Ähnliches gilt für "Geschosse", wobei es imho keine kluge Idee ist, Positionen einzelner Kanonenkugeln übers Netzwerk zu schicken.
Vielmehr gäbe es protokollintern zuerst die Anweisung, dass ein Geschützturm ein bestimmts Ziel im Visier hat und wie lange es dauert bis geschossen wird; und danach eine Anweisung, dass der Geschützturm den Creep getroffen hat (oder keine mehr, wenn der Creep inzwischen Tod oder ausser Reichweite ist). Dann ist es den Clients überlassen, die einzelnen Kugeln dann einzuzeichnen oder ob sie in "Revenge of the Titans"-Manier einfach nur Laser mit Suchscheinwerfer machen: YouTube - First Minutes Of: Revenge Of The Titans - Endless #1

Nachtrag: Am Anfang würde ich vorschlagen, dass wir ein Mazing TD machen, bei dem die Gebäude keinen Schaden nehmen: Die Creeps würden also einfach strikt Richtung Ziel laufen, bis sie an ein Hindernis stoßen und dann da drum herum gehen, also sowas hier: http://www.youtube.com/watch?v=7QdAU4o7NZ4

Und erst wenn wir gescheite Wegfindung haben, dass wir auch Gebäude zerstören lassen können, so dass die Viecher sich ggf. ihren eigenen Weg bahnen.

Bezüglich Spielkonzept müssten vorher noch ein paar Entscheide getroffen werden:

- Klassisches Tower-Defense wo die Viecher einen bestimmten Weg entlang gehen und man den Wegrand dann mit Türmen vollpflastert
- oder "Mazing" Tower-Defense wo die Viecher überall hin dürfen und wo man selber Pfade plastert.

Bei Zweiterem muss auch entschieden werden ob die Tower zerstörbar sein sollen oder nicht.

Ich persönlich fänd eine freie Map mit zerstörbaren Towern am interessantesten, das benötigt aber halt dann doch echt gute Wegfinde-Algorithmen.

Also wie schon oben gesagt, wird es aus genau dem Grund ein Multiplayer-Spiel, damit jeder seinen eigenen Client mit oder ohne .NET und mit oder ohne Browser haben kann.

Serverseitig denke ich an Java für eine erste Implementation, sofern da mehr als eine Person dran arbeitet, weil das ist die Sprache die alle können und die überall läuft. Ich persönlich würde gerne mal was mit node.js (serverseitiges Javascript) machen, aber wenn da sonst keiner mitmacht, bringt das nichts. Und wer sadistisch genug ist, kann den Server dann immer noch nach C oder Shellscript portieren.

Clientseitig wird halt das genommen, was der/die Client-Programmierer (müssen ja nicht die gleichen sein, wie diejenigen die den Server machen) dann halt mögen. Zuerst müssen eh erstmal grundlegende Features, Protokoll und andere Schnittstellen zwischen Client und Server festgelegt werden.

Klingt interessant.

Wie sieht es denn jetzt aus von den Leuten hier die tendenziell mitmachen würden?
Wenn es genügend Leute/Motivation gibt, können wir hier ja mal anfangen zu planen, grundlegende Konzepte festlegen und dann anfangen Milestones setzen und bisschen Aufgabenverteilung machen.

Also man kann auf beiden Seiten Gebäude platzieren? Oder gibt es eine gemeinsame Zone ums HQ?

Das mit dem Geld ist eine gute Frage, ein gemeinsamer Pool würde sicherlich die "wir sitzen im gleichen Boot"-Mentalität stärken, andererseits kann es auch den Spass verderben wenn der eine alles Geld sofort verbaut bevor man seine eigene Verteidigung hat.

Ein Zwischending wären zwar eigene Geldmengen pro Spieler, dann aber die Möglichkeit einander Geld zu schenken oder einen gemeinsamen Pool zu führen, in dem 50% der Einnahmen eines Spielers landen oder so. Haben alle Systeme so ihre Vor- und Nachteile.

Die Karte selbst würde ich durchaus als festes Raster bevorzugen, macht die Sache mit der Wegberechnung auch einfacher und wir müssen uns nicht auf Pixel festlegen (suckt falls jemand mal ne Mobile-Version machen wollte). Wobei ein normales Gebäude dann standardmäßig vll. 2x2 Kästchen gross wäre, um die Sache nicht ganz so schachbrettartig zu machen. Die Viecher und Geschosse hingegen müssten präziser sein, vll. 1/10 eines Kästchens oder sogar direkt Floating-Point.

Nachtrag: Zu klären ist natürlich auch noch, ob Gebäude schaden nehmen können oder nicht. Imho gehört das schon dazu, aber ich habe gesehen es gibt auch Spiele wo Gebäude keinen Schaden nehmen, dafür kann der Weg nie gesperrt komplett werden.

Okay, ein paar Gedanken:

Grundsätzliches Spielprinzip: Man hat nen Ziel was man durch Plaztierung von Kanonen/Fallen etc gege eindringende Horden Verteidigen muss. Ich denke da tendentiell an ein Hauptgebäude, kann im Prinzip aber auch ne Linie oder sogar ein bewegendes Ziel sein. Wobei ich auf ersteres Tendiere.

Eine abzuklärende Frage wäre, worin das Multiplayer besteht. Klassischerweise sind Towerdefense eher Singleplayer, für MP sähe ich da zwei Möglichkeiten:

- Gemeinsame Verteidigung, also man eine gemeinsame Basis hat, die man verteidigt.
- Einander gegenseitig Horden zuschickt. Wobei die Horden dann doch computergesteuert sein sollten (sonst wirds RTS) und nur die Menge bzw. Stärke der Horden vom Spieler beeinflusst werden kann, nicht auch die Wegfindung.

Als Punktesystem gibt es pro getöteten Gegner Geld, womit wieder neue Waffen gekauft werden können. Ansonsten kann man sich auch PowerUps oder simple Gelderzeugungsfabriken überlegen.

Nebenfeature: Mit ein paar intelligenten Algorithmen könnte man es sogar implementieren, dass Clients ihre eigenen Abwehrgeschütze und Horden gestalten könnten, in dem Kaufpreis einer Einheit auf die jeweiligen Merkmale verteilt werden (Viel Stärke, dafür Langsam etc), so dass der Server nur das Movement macht. Wobei da die Frage nach dem Model (Aussehen) etwas schwieriger wird.

Nebenfeature: Map-Editoren.

Am Anfang kritisch würde sicherlich die Server-Software sein. Das schwierigste dürfte Wege-finden der Horden und Hitpoints/Geschosse ausrechnen sein, auch dass dann rechtzeitig wieder dem Client mitteilen, weil da doch ordentlich viel Positionsdaten anfallen (Position alle Horden, Position aller Geschosse).

Spontan fänd ich die Idee eines Multiplayer-Tower-Defense-Spieles nicht so übel. Gäbe serverseitig allerdings doch einiges zu implementieren.