C# XNA 2D MMORPG

Försöker bara vara hjälpsam, du har underskattat nätverksdelen av MMO-spel totalt. Du är påväg rätt ner i kaninhålet så att säga. En server som körs med .NET CLR (inkl GUI dessutom, som pollar events och massa skit) är en FET flaskhals för detta då det blir alldeles för mycket abstraktionslager mellan själva koden och resultatet. Jag tycker definitivt du bör läsa artiklar på om hur bla GW2 löser sin nätverkskod.

Detta är ett newbiemistake som är väldigt lätt att göra. Tänk också på att du måste balansera server/klient-kod för att både vara snabbt nog för tio/hundra-tusentals spelare, samt säkert nog.

Önskar dig dock all lycka med detta projektet!

Det är förvisso sant men lite perspektiv är viktigt när man håller på med sånt här, och det utgår tydligt ifrån hans inlägg att han inte alls har något realistiskt perspektiv just nu.

Det beror ju helt på hur många spelare man skall ha i spelet. Tiotusentals spelare?
Hans mål är ju att göra en sorts Tibia-klon. Tibia har som mest 700 spelare per server och inte något centraliserat system för spelarna.
Snackar vi EvE Online så snackar vi om ett centraliserat system med ett kluster av servrar som lirar i Python med lite C++ backend. Då snackar vi också 30 tusen spelare om dagen som alla existerar i samma värld.
Men det är väl inte målgruppen för detta spelet?

EDIT: Sedan angående overhead som finns i .Net CLR. Det är inte så extremt som vissa vill få det till att vara, visst är det märkbart men att påstå att det är en så stor flaskhals att man inte kan göra en server av det är bogus IMHO.
I så fall skulle det inte gå att göra någonting i C# som är tidskritiskt, detta inkluderar ju t.ex spel också.

Jag menar på att när man gör sitt första spel behöver man inte ha ett realistiskt perspektiv alls. Man gör vad man kan och lär sig på vägen.
Om man försöker alldeles för hårt så kommer man ingen stans utan spenderar all tid på att lära sig jätteavancerade saker i onödan eftersom man aldrig blir någorlunda färdig med sitt projekt vilket gör att man lika snabbt glömmer vad man lärt sig.

Det är som att förvänta sig att en 1-åring skall kunna springa 100 meter sprint utan att först lära den krypa.

Vad menar du egentligen med "inkl GUI dessutom, som pollar events och massa skit"? Och vad menar du med "abstraktionslager mellan själva koden och resultatet"? Du slänger dig med mycket vaga termer. Dessutom heter det "framgår tydligt ifrån hans inlägg" och inte "utgår", newbiemistake.

Håller med Haikarainen, utan att vara tankeläsare eller så tror jag att han menar att en del utav cpu-tiden för server går åt att presentera saker och ting istället för att göra det den bör göra, alltså att vara spelserver.

GUI:n lyssnar efter events från OS:et istället för att blockera huvudtråden, var ett tag sedan jag höll på med detta, men antar att någon annan kan förklara bättre. En vanlig loop för att lyssna efter events i SDL exempelvis ser ut ungefär såhär;

SDL_Event event;
int running = 1;
while (running) {
    while (SDL_PollEvent(&event)) {
        if (event.type == SDL_QUIT) {
            running = 0;
            // en break; om man vill också, eller exit(0);
        }
    }
    SDL_Delay(16);
}

I en liten mer advancerad produkt, som t.ex. .NET Forms, eller vad det nu heter, så går där ännu mer tid till att hantera GUI. Och med abstraktionslager menar han antagligen att datorer fungerar inte på ovanstående sätt, utan man måste ha ett system för att kunna hantera events på OS nivå, sedan ett till ovanpå det för att skapa .NET biblioteket, och sedan ett för att kunna tyda .NET bytekoden, eller hur MS nu har löst det. Detta tar massa procesortid ifrån vad servern egentligen ska göra, samma anledning som att man oftast kör Linux, eller något annat *NIX system utan någon GUI på servern, utav den simpla anledningen att det egentligen inte behövs.

Så egentligen borde man skriva serverkoden i något som C, eller annat språk som har en ordentlig kompiler och är tillräckligt low-level, alltså inte JavaScript genom V8 Men med alla sådan här saker är det viktigt att komma ihåg att det som är dyrast är många gånger att utveckla produkter, datorkraft är oftast betydligt mycket billigare. Men samtidigt, det finns ytterst bra anledningar till att exempelvis nginx är skrivet mestadels i C och inte Java, C# eller något sådant, och det är “bara” en webbserver. (nginx skrevs åt en rysk nyhetsida som hade väldigt mycket trafik, om jag minns rätt, och är ytterst bra på att servera statiskt innehåll och används ofta som load balanser, bland annat på AppFog och Heroku)

(Lite flummigt det hela men jag hoppas att det går att tyda, och inte innehåller allt för många fel)

Troligen kommer TS aldrig behöva ha en högpresterande spelserver som kan hantera flera tusentals samtida användare, och det är nog bara bra att skriva saker och ting i det språk som TS kan bäst.

Till TS: http://opengameart.org/ har massa bra resurser som kan användas i spel och liknande, vet sedan också att http://oryxdesignlab.com/ hade en hel del fina tilesets för ickekommersiellt bruk, som numera verkar kosta pengar, men jag vet inte om det fortfarande går att få tag på de som endast var för ickekommersiellt bruk, annars tror jag att jag har de liggandes någonstans på datorn (skicka pm) Antagligen har han finputsat de sedan dess dock. Lycka till förrästen

System.Threading nuff said.

Klippt bort det redan orelevanta.
.Net bilbioteket är wrappers runt t.ex Win32 calls. När du väl skapat en länk (t.ex TCP) så är overheaden extremt liten. Knappt relevant mot vad servern i sig behöver göra.
När man gör en server i C++ använder man också bibliotek för att köra nätverkstrafik. Om detta är Win32 eller andra bibliotek spelar inte så stor roll, prestandan mellan dom är näst intill irrelefant i relation till serverkoden. Visst, har man 1200 klienter på servern med mycket beräkningar (typ som EvE Online) kanske varje nanosekund spelar roll.
Det är bevisat att C++ "alltid" är lite snabbare än C# men igen, i relation till huvuduppgiften är det inte en markant skillnad.

.Net bytecode, vad syftar du på? Om du menar att man skickar objekt mellan klienten och servern med standardserialisering så behöver inte detta vara fallet. Det går med fördel att serialisera binärt. Där en struktur med 3 floats för position, 3 floats för rotation och t.ex en integer för hälsa skickas i exakt 28 bytes som det skall skickas, precis lika litet som med vilket annat språk som helst som stöjder binära streams.

Nej nej nej, när du kör ett C# program så skiljer det inte sig speciellt mycket från ett C++ program. Okej, kompileringen är bättre med C++ men det är inte som med Java där man kör det i en virtual machine. C# kompileras Just In Time (JIT) och blir för det mesta native code.
Dessutom kan C#, som kompileras med JIT Compiler dra nytta av alla instruktioner där C++ kompileras mot ett målset med instruktioner.

Läs denna frågan på stackoverflow då dom har mer kunskap än mig i frågan.
http://stackoverflow.com/questions/145110/c-performance-vs-ja...

Specialisering slår alltid generalisering, det är väl inget nytt?
Man kan programmera i Assembler också om man vill. Det är ju ännu bättre än C++ då du verkligen har full kontroll på varenda instruktion som körs och kan slippa en massa onödig bloat.
Det är också så dom allra största spelutvecklarna gör för att pressa ut den där sista droppen prestanda ur spelmaskinerna.

Som jag sagt tidigare alltså, det är inte så stor skillnad på C# och C++ i prestanda som många vill få det till... Så länge man programmerar rätt dvs.
För det är väldigt lätt att slarva i C# för man behöver inte tänka på lika många saker i C# som i t.ex C++.

SDL_Event event;
int running = 1;
while (running) {
    while (SDL_PollEvent(&event)) {
        if (event.type == SDL_QUIT) {
            running = 0;
            // en break; om man vill också, eller exit(0);
        }
    }
    SDL_Delay(16);
}

Har TS sagt att servern ska ha ett GUI?

Va?

Va? .Net har en JIT compiler, och det blir rätt snabbt. Tillräckligt snabbt.

Återigen har jag inte sett att TS har sagt nått om ett GUI. Och varför pratar du om *Nix? Man kan göra program utan GUI på Windows också.

Nej då, det borde man inte.

Jasså, vardå?

Jo, det är som med Java. C# (eller bytekoden man får när man kompilerar) körs i en virtuell maskin, och Java har också JIT-kompilering.

Varför skulle det vara lättare att slarva i C#? Det där med att man inte behöver tänka på lika många saker köper jag inte riktigt. Det är väl snarare en nackdel med C++.

Menar bara att det egentligen tar onödig CPU-tid, som Haikarainen också verkade snacka om. Försökte egentligen bara förklara för tufflax om det han frågade om, och varför det skulle kunna ha betydelse för servern. Dock, som sagt håller jag med dig om att i sammanhanget spelar det ytterst lite roll för TS. (Just nu åtminstone)

Några små syntetiska benchmarks; http://benchmarksgame.alioth.debian.org/u32/benchmark.php?tes... Så ser det ut som om C är normalt dubbelt eller upp till 14 gånger snabbare än C# (Mono). Där finns en overhead och den bör man inte glömma. Kan tänka mig att de små skillnaderna kan bli relevanta om man har väldigt många fiender i spelet som alla måste animeras och hitta från punkt A till punkt B. Eller som TS snackade om att han hade performance problem när väldigt många spelare på ett litet område. Även om det är ytterst svårt att säga vad som är problemet i detta fallet utan att ha sett någon kod.

Funderade att om man kan köra VisualBasic och C# på samma sätt måste de också ha ett gemensamt språk under ytan? Alltså att det som ligger i EXE-filen inte är C# kod utan någon form utav array utav bytes som formerar kod, därav bytecode. Men det är inget jag har kollat upp.

Men fortfarande så finns det fördelar med både C och Java över C# och viseversa. Java kör på betydligt fler platformar än vad C# gör, men dock inte lika många som C. Java och C# kräver många gånger mindre kod än vad man behöver i C. Själv tycker jag att C# är ett mycket trevligt språk och har gott stöd på Windows. Så i slutändan finns det inget som är bättre än det andra, det handlar bara vad man är ute efter. Och i just spelservrar kan prestanda vara avgörande, men om man inte är bekväm med C så finns det heller ingen anledning att använda det, då kan man istället lägga pengar på bättre servrar och spara en massa tid. I TS fall stödjer jag helt hens val i att använda C#, om nu hen är bekväm med det.

Har för mig att vissa ARM-processorer har stöd för att köra Java lika snabbt som vanlig maskinkod. Skillnaden mellan Java och C# är ännu mindre än den mellan C och C#; http://benchmarksgame.alioth.debian.org/u32/benchmark.php?tes... I vissa fall kan det nog till och med vara fördel att använda Java över C#, bara för performance: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?tes...

Men det är ju såklart något man måste kolla för varje enskilt användningsområde.

Tror dock det kan bli problem med Assembler om man plötsligt skaffar sig hundratals ARM-processorer istället för, säg x86 processorer?

Har för mig att V8 motorn gör något liknande med JavaScript, men det finns ändå fördelar med att använda andra system, det hela handlar om vad man är ute efter och vad man kan. Själv har jag börjat använda Node.js istället för PHP för att jag tycker att JavaScript är enklare att förstå och inte lika virrigt som PHP, sedan är ju alltid lite extra prestanda trevligt. Men vissa gånger har jag svårt att byta ut PHP med Node.js och då väljer jag såklart PHP då det ger fördelen att det redan finns på plats.

Det jag menar är att TS ska välja det som passar hen, även om det finns alternativ som kan vara bättre för ändamålet.

Tyckte att jag såg det för några poster sedan, jag försökte bara förklara vad jag antog att Haikarainen menade, eftersom du frågade. Dock vet jag inte om det skall tas bort sedan? Men i vilket fall som hellst kan GUI:n vara perfekt för debugging, beroende på vad man är van vid.

Har inte gått datorvetenskap eller så, men jag har för mig att events bara är en abstraktion utav hårdvaran från, bland annat OS:et.

Se ovan, men det gör det inte mindre sannt att något annat är snabbare.

Menade att man kan starta de flesta *NIX system i ett headless läge, alltså utan någon GUI, bara en commandline. Har för mig att det var länge sedan man kunde göra detta på en windows-dator.

Varför inte? Är man bekväm med det ser jag verkligen inte problemet.

Ja, det är klart det är en abstraktion, kan man säga. Men "datorer fungerar inte på ovanstående sätt". Vadå för ovanstående sätt?

Du pratade om abstraktionslager och tyda bytekod, men det försvinner ju med JIT. Det är alltid vanskligt att jämföra hur snabba "språk" är.

Aha, jo det är ju sant.

För att det tar sjukt mycket längre tid att göra nått i C än i något mer-högnivåspråk. Och resultatet blir enklare med vissa andra språk.

Jag är inte intresserad av att googla för dig, det är allmän vetskap.

Du har haft så rätt hittills så varför har du så fel på denna grundläggande punkten helt plötsligt?

http://stackoverflow.com/questions/9556354/if-c-sharp-is-not-...

Det är lättare att slarva i C# för att du alltid har GC där som städar upp efter dig, det är lätt att göra något horribelt misstag där man inte släpper en resurs och då kommer lilla mamma GC och gör det åt dig för en liten kostnad.

Det finns så mycket dåliga sätt att lösa saker på med .Net biblioteken och man vet inte vilket som är bättre för att implementationen är dold för dig.
Det blir lätt "Åh, detta ser ut som det jag behöver... Ah, det funkade. Då kör vi på det!" men sedan visar det sig att om man bara hade kollat lite närmare på det så hade man insett att det fanns effektivare metoder att göra samma sak på.
Det är inte att jämföra med en dålig implementation i C++ som man skrivit själv, då har man bara sig själv att skylla för att den inte är snabb nog.
I C# finns det många olika alternativ att välja och vissa är bättre än andra trots att dom gör i princip samma saker.

Ja, all form av GUI tar kraft. Så sätt har du helt rätt i att ju mer grafiskt GUI du har desto mindre kraft har du till Servern.
Men nu vill jag inte direkt påstå att det är ett tungt GUI och dessutom sitter det ju inte och hoggar massa resurser i onödan.
Alla program har en "main loop", oavsett om dom är console, "system" eller winforms applikationer. I denna mainloop finns det någon form av PEEK för att kolla om det finns meddelanden i kön för det programmet.
Finns det inga meddelanden så görs inget med GUI't och all kraft läggs på resten.
Windows är inte optimalt för en server dock, det vet vi ju redan. Men det duger gott och väl!

Alla dom benchmarks körs i Mono. Mono != .Net, senast jag kollade hade Mono fortfarande problem med prestandan för C# applikationer.

http://en.wikipedia.org/wiki/Common_Language_Runtime

Det spelar ingen roll vilket språk man skriver i, dom riktar sig mot CLR som är den egentliga kompilatorn. Man kan säga att språket är .Net och C#, VB och F# är olika smaker på samma språk. Dom översätts alla till CLR språk.

Igen, Mono != .Net...

Ja, då får man ju programmera en verision för ARM enheter. En för Windows, en utan windows, en för 32 bitars, en för 64 bitars.... ad infinitum.
Alla för hand, intruktion för instruktion.
Det är därför vi har High Level languages...

Men vissa saker piffas upp i Assembler för att klämma ut lite extra prestanda, speciellt i spel.
Tror inte det går att göra med C# program dock, om man inte JIT ändrar bytekoden som JIT Compiler genererar innan programmet startar. (på riktigt)

Hoppar över en del av ditt inlägg, har inga kommentarer.

Om inte jag är helt ute och cyklar nu så... En event är lite som en callback funktion.
När ett event triggas så körs flera funktioner på samma gång från samma utgångspunkt. Som vi alla vet (eller?) så är en funktion inget mer än en address i minnet där en viss mängd instruktioner befinner sig som skall köras.
Med andra ord, ta parametrar X, Y, Z, ... och anropa funktioner A, B, C, ...

Vissa events triggas från formens messagepump. Som t.ex musklick, musrörelser, tangentbordstryck, ändra storleken på fönstret etc etc.
Andra triggas då programmet kommit till en viss punkt i sin exekvering. Som t.ex Form.Load, när winformen laddas och Form.Shown, när fönstret ritats upp för första gången. (Eller efter att ha varit dolt)

Det är ingen speciell skillnad på ett event i .Net och en messagepump i C++.
Lite mer overhead (och därför användarvänligare) är allt. Men events triggas inte tusen gånger per sekund (om inte programmeraren ser till att så sker förståss) ändå, en droppe i havet.

Går med fördel att starta Windows i väldigt grundläggande läge. Men eftersom Windows är Windows (fönster) så startas ju alltid den mest grundläggande fönsterhanteraren när man startar Windows... Annars startar man ju inte Windows!
Men det finns också en kernel i Windows, precis som det finns en Linux kernel. Man kan (om man verkligen vill) bara starta Windows Kernel, utan GUI.
Varför någon skulle göra detta vet jag dock inte. Då kan man ju lika gärna köra Linux för Windows är sämre än Linux.

Benchmarks är inte bevis.

Du sa "...men det är inte som med Java där man kör det i en virtual machine. C# kompileras Just In Time (JIT) och blir för det mesta native code."
Det är precis så Java funkar också. Sen visste jag inte att Mono compilerar till maskinkod AOT, men det var ju inte det du menade, uppenbarligen.

Va? Om man inte släpper en resurs så kommer den inte att GC:as. Och på dig låter det som att GC är något negativt, men det är det ju inte, snarare tvärt om.

Jag fattar inte ditt argument riktigt. Att det finns bibliotek till C# är dåligt? Hm...

Det känns som att tråden har spårat ur lite för att gå ner på detaljer som ni konstaterat att TS gör rätt i som inte har i åtande just nu.
TS kanske följer detta lika intresserad som mig, men språkdiskussioner hör till en annan tråd eftersom TS redan valt ett.

Skickades från m.sweclockers.com

I ordning, orkar inte quotea en massa...

Har jag länkat till benchmarks eller antar du bara att jag syftar på benchmarks?
Java kör i en VM, det är en av "fördelarna" med Java. (http://en.wikipedia.org/wiki/Java_virtual_machine)
Om du sätter om en klassvariabel utan att släppa eventuella resurser som behöver släppas så tar GC hand om den när GC känner för det. Googla!
Antaganden kommer du inte långt med...

-------------------------------

Och eftersom BlasteRs bett om det, back on topic!

Har du någon aning om varför din collision detection segar ner med 2000 entities på samma ställe?
Kan du ge exempelkod så kan vi hjälpa dig lösa det.

Har du någon designplan för spelet? Jag har inte sett den i så fall, bara screenshots.
Kommer det vara en Tibiaklon rakt igenom eller har du några idéer på hur ditt spel kommer skilja sig från mängden kloner där ute?

P.S.
Du kan lära dig mycket av vårat nördkäbbel med.

Keep up the good work!

Hur vet du om dom är Close eller Very-Close?
Har du sett följande sida? Den förklarar collision detection rutiner väldigt bra. Kanske lite för bra för detta spelet men...

http://www.metanetsoftware.com/technique/tutorialA.html

Den andra artikeln kan dock vara av större intresse för dig!
http://www.metanetsoftware.com/technique/tutorialB.html

Den hanterar "broad phase", det som du gör med close och very-close.

Nu blev det högintressant igen!
Synd att hemsidan är väldigt svårläst från mobiler, blir att stationera mig vid datorn när jag får tid.

Skickades från m.sweclockers.com

Någon specifik anledning till varför du serialiserar kartorna till XML och inte istället har ett typ bitmap format? (En byte eller två bytes för varje tile)
Eller är det bara enklare så?
Hur stora kartor jobbar vi med för övrigt?

Okej, jag tänker mest på att om du t.ex har en karta med t.ex 2000x2000 tiles i framtiden så blir det 4.000.000 tiles totalt.
Sedan som du sa så tillkommer ju annan info också.
Lägger man då på c:a 9 ggr det i XML overhead (alltså extra text bara för att det är overhead) så kan det sluta med en väldigt stor fil som skall läsas från ett relativt långsamt medium.

Oroa dig inte för det nu men ha det i åtanke för senare.

Ja, det är nog smidigast att lösa det med tiles istället. Typ något så simpelt som "Tile.IsOccupied".
När en entity rör sig från en tile till en annan så sätter han "Tile.IsOccupied" till falskt i den han lämnar och sant i den han går in i.
Om en annan entity vill in på samma tile så ser han att den är occupied och kan därför inte slutföra rörelsen.

Vad gäller kartan så är det ganska enkelt fixat att göra en bitmap av den med extra information.
Det svåra blir att upprätthålla kompatiblitet men även det går att lösa, fast med en lite mer avancerad datastruktur i filen.

Fast som sagt, på tog för trött för att programmera just nu. Kollar på det imorgon.

EDIT:

Går även att lösa så att om nu av någon magisk anledning två entities skulle dela på en tile så kan man flytta den senaste som kom dit ut i samma riktning som han kom från. (Teleport situationer osv)

public void UpdateNearbyList(List<Entity> entites)
        {
            bool pNear = false;
            try
            {
                for (int i = 0; i < entites.Count; i++)
                {
                    Entity e = entites[i];

                    if (e.currentStatus == Status.Dead)
                    {
                        if (nearbyEntities.Contains(e)) nearbyEntities.Remove(e);
                        if (veryCloseEntities.Contains(e)) veryCloseEntities.Remove(e);
                        continue;
                    }

                    if (e == this || e == null) continue;
                    float distance = Vector2.Distance(e.position, position);
                    if (nearbyEntities.Contains(e))
                    {
                        if (e is Player) pNear = true;
                        if (distance <= 1000)
                        {
                            if (distance < 100 && !veryCloseEntities.Contains(e))
                            {
                                veryCloseEntities.Add(e);
                            }
                            else if (distance > 100 && veryCloseEntities.Contains(e)) veryCloseEntities.Remove(e);
                            continue;
                        }
                        else nearbyEntities.Remove(e);
                    }
                    else
                    {
                        if (distance <= 1000) nearbyEntities.Add(e);
                    }
                }
                playerNear = pNear;
            }
            catch
            {
                pNear = false;
            }
        }

        public void Say(string message)
        {
            EntitySay(this, message, EventArgs.Empty);
        }

Har för mig att man inte behöver kolla om ett element finns i en lista eller ej, om det kan tas bort så görs det. Try/Catch som en del utav logiken kan ta upp mycket cpu-kraft, fast det kan ha ändrats vid det här laget, var länge sedan jag skrev något i C#. Ser dock inte vart den skulle anropas, är det bara för att inte server ska krasha om något går fel? I sådana fall, lägg till en Console.WriteLine() eller något sådant så att du kan hålla reda på felen (blir lätt mycket svårfunna buggar ) Dessutom ser jag inte meningen med att sätta pNear till något här, variablen går ju ur scope direkt efteråt, menade du att den skulle sätta pNear till playerNear eller är bara kodsnutten okomplett?

Om man ska vara riktigt petig bör man nog använda foreach () istället för for-loopen när du kollar igenom entities. Har för mig att man sparar en processor instruktion eller något i den stilen

Med tanke på vad TheCadde skrev nyss, har kanske missat det, men hur ser server/klient kommunikationen ut? Skickar klienten ut saker som att jag gick ett steg i sydlig riktning och sade “hej!” och server svarar, du är där vid koordinaterna 502; 973 och sade hej medan dessa och dessa spelare befinner sig här. (Där kan dock din array över vem som befinner sig i vilka områden komma till nytta. Men det är nog bättre att du bara skickar områden med spelare, där spelarna är sorterade i listor beroende på vart de befinner sig och detta är data som finns tillsammans med världen och inte varje enskild spelare, beroende på hur projektet är strukturerat?) Eller hur kommunikationen nu ser ut?

EDIT: Som MugiMugi påpekade är det bara när catch blocket körs som det tar slöar ner exkaveringen utav koden. Menade att när man använder try/catch som en form utav ersättare till exempelvis if/else satser så lär man se problem med performance (om det nu händer att catch/else satsen exkaveras). Exempelkod:

List<int> array = new List<int>();
bool over9000 = false;
try {
    int i = array[9000];
} catch {
    over9000 = true;
}

List<int> array = new List<int>();
bool over9000 = (array.Length > 9000);