[15:19] <CABAListic> ich hatte gestern eine lustige idee für ein etwas skurrileres RTS. eines mit vollwertigem basisbau ohne einen herausragenden helden wie bei unserer sacrifice-idee, aber mit ähnlichem prinzip [15:19] <JJP> erzähl ;) [15:19] <CABAListic> also auch mit einer gottheit, von der man seine einheiten bekommt. dafür muss man dann opferschafe oder sowas züchten, und die werden im tempel geopfert (ressourcen quasi) *g* [15:20] <CABAListic> für upgradeforschungen einer einheit müsste man z. b. dann ein paar von dem einheitentyp opfern und die priester ein ritual durchführen lassen (kosten + zeit damit), dann werden die einheiten stärker [15:20] <JJP> vielleicht kann man den gott dadurch verändern oder beeinflussen was man ihm opfert ;) [15:20] <CABAListic> oder so etwa. damit könnte man bestimmt was lustiges aufziehen ;) [15:21] <CABAListic> ganz unten hätte man eben schafe, die man als “ressource abbaut” zum opfern, und man könnte dann einheiten wiederum auch opfern etc. ;) [15:21] <JJP> hm wenn man das weiterspinnt ergeben sich da auch interessante zusammenspiele [15:21] <CABAListic> joah. das kam mir nur gestern so, falls wir nicht doch lieber ein RTS mit vollwertigem basisbau machen wollten, hehe [15:22] <JJP> ich finde wir haben viel zeit an ideen zu arbeiten [15:22] <CABAListic> die haben wir in jedem fall :) [15:22] <CABAListic> und das ist auch gut so [15:22] <JJP> also kann man ja ruhig sammeln und es in ruhe angehen ;) [15:22] <CABAListic> hehe, joah [15:25] <JJP> vielleicht könnten dann auch bestimmte opfer die laune eines gottes so beeinflussen dass das einen globalen effekt auslöst [15:26] <CABAListic> du meinst, so eine art der superwaffe? ;) [15:26] <CABAListic> mit “laune” hätte ich so meine probleme, das könnte ein spiel etwas weniger berechenbar machen [15:26] <CABAListic> aber sowas wie einen gewittersturm heraufbeschwören ist sicher denkbar [15:26] <CABAListic> oder entsprechendes halt ;) [15:26] <JJP> zum beispiel. oder einfach, dass z.B. für 30 sekunden die eigenen einheiten erhöhten schaden haben [15:27] <JJP> laune war ein schlechtes wort dafür, ich meine nichts unberrechenbares [15:27] <CABAListic> hm jo, obwohl ich sowas vielleicht sogar noch priestereinheiten als spezialfähigkeit geben würde [15:27] <CABAListic> je nach wirkungsgrad natürlich [15:28] <CABAListic> vor allem kann man damit natürlich ein tolles setting schaffen, denn so standard gut/böse geht schon eigentlich nicht, einem wirklich guten gott dürfte man ja nichts opfern müssen ;) [15:28] <JJP> ja [15:29] <JJP> und mich würde echt mal ein strategiespiel interessieren dass keine pseudo-RPG-elemente hat sondern auf eine andere art weiterentwickelt ist [15:29] <CABAListic> joah, ich fänd das eine gute grundlage, auf der man in die richtung weiterdenken könnte :) [15:30] <CABAListic> ich glaube übrigens sogar, dass wir mit ogre-hilfe tatsächlich ein grid-free bewegungssystem hinkriegen können :) [15:31] <JJP> das ist gut [15:32] <CABAListic> wegfindung muss natürlich in gewissem sinne eins verwenden. [15:37] <JJP> hmm, wenn du schon mit opferschafen anfängst: man könnte auch die idee so weiterspinnen, dass man mit einer population von geschöpfen beginnt die einen gott anbeten und sich daraus ergibt was für “einheiten” man im verlauf des spiels kriegen kann [15:38] <JJP> aus schafen entstehen andere kreaturen als aus schildkröten oder löwen ;) [15:38] <CABAListic> damit hätte man dann verschiedene “ressourcentypen” ;) [15:38] <CABAListic> halt mal in einer neuen verpackung, hehe [15:39] <JJP> oder die kreaturentypen entsprechen verschiedenen völkern/parteien [15:39] <CABAListic> oder das [15:40] <CABAListic> obwohl ich eher auf verschiedene götter setzen würde und die “ressourcen” gleich. aber das müsste man im detail mal betrachten [15:40] <CABAListic> hängt natürlich auch davon ab, wie die aufzucht und opferung konkret funktioniert ;) [15:42] <JJP> hmm, ich bin auf die kreaturen fixiert ;) vielleicht eine mischung. schafe glauben sicher an eine andere art von gott als frösche zum beispiel ;) [15:43] <JJP> zumindest ist das mit unterschiedlichen kreaturen ein sehr praktischer ansatz um für verschiedene götter oder parteien ein eigenes aussehen zu kriegen [15:43] <CABAListic> ok, dein konzept ist halt, dass die kreaturen selbst die anbeter sind ;) [15:43] <CABAListic> dann brauchen wir aber eine andere art von ressourcen [15:43] <CABAListic> oder wachstumsverwaltung [15:44] <JJP> hm, eine möglichkeit für eine resource wäre dass götter ihre energie von ihren gläubigen beziehen [15:45] <CABAListic> hm, wäre das nicht schon durch die opferung gegeben? die frage ist eher, wodurch ist die anzahl meiner kreaturen, die ich opfern kann, gegeben? [15:47] <JJP> hm, man kann die anzahl der kreaturen begrenzen. durch ein limit und/oder dadurch, dass sie selbst begrenzte resourcen zum überleben (ver)brauchen [15:47] <JJP> oder noch anders, eine kombination aus opfern und dem anderen [15:47] <CABAListic> joah, hm. ich glaub, ich muss irgendwann meinen ansatz auch nochmal stärker im detail durchdenken und aufschreiben :) [15:47] <JJP> die kreaturen die durch opfern entstehen sind magischer natur [15:47] <CABAListic> hm [15:48] <JJP> und benötigen göttliche energie, die man durch seine gläubigen gewinnt [15:48] <JJP> d.h. wenn ich alles opfer sterben die kreaturen weil niemand da ist der an mich als gott glaubt ;) [15:48] <CABAListic> hm, hehe [15:48] <CABAListic> könnte auch was haben [15:49] <CABAListic> dann hätte man so eine art klassisches rts erweitert um das opferprinzip :) [15:50] <CABAListic> klassisch müsste man ressourcen abbauen und die grundeinheitentypen “finanzieren”, also bauleute, einfache krieger und priester, so in etwa [15:50] <CABAListic> für alles darüber hinausgehende müsste man dann opfern :) [15:50] <CABAListic> und zwar diese grundtypen [15:50] <CABAListic> und je nachdem, was man in welcher kombination opfert… :) [15:50] <JJP> jo [15:51] <CABAListic> so nach dem prinzip, 2 krieger + 2 priester könnte dann so eine art dämonenlord oder so bescheren ;) [15:52] <JJP> und 3 priester eine starke zauber-einheit oder so in der art [15:53] <CABAListic> joah [15:53] <CABAListic> und das einheitenlimit ist dann durch die glaubensstärke gegeben ;) [15:53] <CABAListic> oder so, hehe [15:54] <JJP> bzw. für die normalen einheiten muss es eine art limit geben, weil die ja keinen glauben verbrauchen [15:54] <CABAListic> hm ja [15:54] <CABAListic> evtl. kann man deren zahl ja sogar konstant halten? [15:54] <CABAListic> obwohl ne, das allein wär noch nicht so doll [15:54] <CABAListic> oder? naja, quasi mit gewisser zeit wird nachgeboren nach opferung. und die vorhandenen kann man beliebig umkonvertieren [15:55] <CABAListic> so eine art battle realms prinzip [15:55] <CABAListic> aber naja. da gibt's vielleicht noch bessere lösungen [15:56] <JJP> man könnte einen sehr vereinfachten basenaufbau haben, der das limit vorgibt und in dem rahmen entstehen neue [15:56] <CABAListic> hey, aber ich hab grad eine idee, wie man das glaubenslimit umsetzen könnte ;) [15:56] <JJP> wie ;)? [15:56] <CABAListic> es müsste dann auf der karte so kleine siedlungen vorgegeben geben. und man könnte da drin dann priester abstellen [15:57] <CABAListic> die “ausbeute” hinge von der größe der siedlung und von der anzahl priester ab, die da missionieren - mit gewisser begrenzung natürlich [15:59] <JJP> hm, wie man das am besten regelt hängt davon ab wie die zahl der normalen kreaturen bestimmt ist [15:59] <CABAListic> ja… [15:59] <CABAListic> naja, ich werd mir mal ein paar weitere gedanken machen :) [15:59] <JJP> wenn die zahl nicht konstant ist könnte es zu undurchsichtig werden, wenn man zusätzlich noch über die zahl von priestern einfluß darauf nimmt [15:59] <JJP> jo ich auch ;) [16:00] <CABAListic> ich denke aber, irgendeine form von “ressourcenabbau”, basenaufbau und einheitenproduktion braucht es schon. wenn auch nicht ganz klassisch, soll es ja doch irgendwie ein RTS werden :) [16:00] <JJP> ich schreib mal die tage was auf, wenn man die vorstellungen auf einen blick da hat kann man besser darüber diskutieren [16:00] <JJP> ja [16:00] <CABAListic> jup [16:00] <CABAListic> ich werd ebenfalls mal sehen, dass ich was zu papier bringen

[15:12] <CABAListic> jjp, ich hab meine gedankensammlung in deinem thread festgehalten [15:12] <JJP> :) gleich mal lesen ;) [15:13] <CABAListic> ist in teilen auf deinem konzept aufgebaut, in anderen teilen weicht es ab [15:17] <JJP> wie ist das mit erweiterten kreaturen - schlagen die im selben maße auf das einheitenlimit wie die grundeinheiten aus denen sie beschworen wurden? [15:18] <CABAListic> nicht notwendigerweise, ist im prinzip eine balancingfrage [15:18] <JJP> hm, das mit der magie stimmt: eine glaubwürdige einschränkung könnte sein, dass man nicht in der nähe des tempels/hauptgebäudes eines gegnerischen gottes zauber wirken kann [15:19] <CABAListic> ja, das wäre möglich. allerdings gibt es noch ein anderes “problem”, wenn man selbst direkt die gottheit verkörpert [15:19] <CABAListic> ich weiß, spielspaß vor realismus etc., trotzdem wäre eine frage, wieso man als gott einen nebel des krieges z. b. hätte, der aber imho wichtig ist [15:20] <CABAListic> ist man nicht mächtig genug, die feindbewegungen zu sehen? ;) [15:20] <CABAListic> ok, auch hier könnte natürlich der andere gott schützen [15:23] <JJP> hm, wenn man als gegeben annimmt das ein gott nicht allwissend und allmächtig sondern in seinen fähigkeiten durch seine anhänger begrenzt ist dann könnte man sagen das man nur “kleine” götter spielt [15:23] <CABAListic> ok, das ginge auch [15:23] <JJP> aber das ist ja eigentlich nicht so wichtig ob man jetzt den gott oder irgendeine gedachte person die den kreaturenstamm anführt verkörpert [15:24] <CABAListic> für MP ist es in der tat egal, im SP hätte es halt auswirkung auf die story. aber ich schätze, im zweifelsfall müsste man das mit der direkten magie halt ausprobieren [15:25] <CABAListic> so grundsätzlich würde ich da zwar den klassischen ansatz mit globalem “manavorrat” vorziehen, aber wer weiß? [15:25] <JJP> ich glaube das ist zwischen unseren ideen der entscheidenste unterschied [15:25] <JJP> hm [15:27] <CABAListic> joah, das einzig andere ist die sache mit dem glauben. wie gesagt, das mit der magie müsste man dann evtl. einfach mal ausprobieren [15:29] <JJP> ich glaube das system das ich vorschlage ist dynamischer und dein vorschlag rückt planung und strategie mehr in den vordergrund [15:30] <CABAListic> das kann sein, ja [15:31] <JJP> so etwas wie mana für eine sehr mächtige beschwörung oder einen zauber sammeln ist bei meinem vorschlag in dem sinne nicht möglich [15:31] * Quits: TheInfinity-weg (Ping timeout) [15:33] <CABAListic> ja, deine version des glaubens ist eine art simplifizierte ausgabe. im prinzip hab ich mein konzept da auch auf deinem und meinen früheren gedanken aufgebaut. in der hinsicht stimmt deine vermutung wohl wirklich, dass letzteres wohl mehr planung und strategie fokussieren würde [15:34] <CABAListic> was ich bei einem rts nun auch nicht unbedingt für falsch halte. man darf es bloß nicht ausufern lassen, damit action nicht verloren geht. [15:34] <JJP> hm, ich würde beides gerne mal ausprobieren. an meiner idee reizt mich, dass es sich sehr “direkt” anfühlen muss [15:35] <CABAListic> es sollte kein problem sein, beides zumindest im ansatz mal umzusetzen [15:35] <CABAListic> auch wenn ich nach wie vor die engine nicht so extrem modbar machen wollen würde wie manch anderer hier ;) so viel flexibilität sollte sie auch nach meiner vorstellung besitzen [15:36] <JJP> hehe [15:37] <CABAListic> z. b. bin ich mittlerweile der meinung, dass unsere engine modulare konstruktion a la earth nicht unterstützen können muss. auch gebäude sollten einzeln stehen, ein zusammensteckprinzip ist unnötig. beides würde imho erheblichen zusatzaufwand bedeuten [15:38] <JJP> die “modulare konstruktion” ist IMHO unnötig kompliziert. ein design ohne das ist sozusagen genauso mächtig aber meistens einfacher [15:39] <CABAListic> joah, der meinung bin ich mittlerweile auch ;) [15:40] <JJP> sowas ist auch vom grafik-design nicht so toll. es ist mehr arbeit und man läuft gefahr aus bequemlichkeit damit module möglichst oft passen zu gleichartige sachen zu bauen [15:41] <CABAListic> was imho für eine modfähigkeit wirklich wichtig ist, ist eine möglichst mächtige schnittstelle für effekte. mit effekten kann man verdammt viel machen [15:42] <CABAListic> ich meine jetzt effekte in der art wie magische auren [15:42] <CABAListic> aber wenn man das möglichst allgemein implementiert, könnte man mit solchen effekten sogar so etwas wie strom für gebäude implementieren [15:42] <CABAListic> der effekt würde dann permanent auf einem gebäude liegen und allen gebäuden im umkreis einen bonus auf den stromwert geben ;) [15:43] <JJP> jo, das ist interessant [15:43] <CABAListic> hier liegt imho ein sehr mächtiger bereich fürs modding, den wir unbedingt gut unterstützen sollten [15:44] <JJP> upgrades kann man doch auch so realiseren [15:44] <CABAListic> hm, jo [15:44] <CABAListic> möglicherweise jedenfalls [15:45] <CABAListic> obwohl da vielleicht aus performancegründen eine direktere möglichkeit für vorzuziehen wäre, käme drauf an, wie performant man die wirkung auf einheiten hinkriegt. [15:45] <CABAListic> müsste man ausprobieren, schätze ich [15:46] <CABAListic> EIGENTLICH dürfte es sich aber gar nicht so viel nehmen [15:46] <CABAListic> also eigentlich sogar eine gute idee :) [15:46] <JJP> ich meinte das als upgrade so, dass dann jede einheit eines typs z.B. eine “aura” kriegt die nur auf sie selbst wirkt [15:47] <CABAListic> hm, dann könnte man sie aus zwei effekten zusammensetzen: ein globaler effekt, der dann auch auf jede neue einheit angewandt würde und der dann das “upgrade” auf der einheit aktivieren würde [15:48] <CABAListic> denn irgendwie müsste man das ja registrieren, dass einheiten das upgrade überhaupt erhalten sollen, wenn sie neu konstruiert werden [15:48] <JJP> oder alle upgrades sind schon von anfang an da, und haben bloß einen “ein/aus-schalter” der durch eine forschung umgelegt wird [15:48] <CABAListic> naja, wie gesagt, “effekte” richtig implementiert bedeuten verdammt viele möglichkeiten :) [15:48] <JJP> jo, effekte ist wohl der bessere ausdruck [15:49] <JJP> konsistent wäre es vielleicht nicht unsinnig alle fähigkeiten als effekt zu realisieren. z.B. auch die fähigkeiten des tempels bestimmte einheiten zu beschwören [15:49] <CABAListic> hm ja [15:50] <CABAListic> waffen wären ein effekt, ressourcen abbauen auch… [15:50] <CABAListic> beten wäre ein effekt :) [15:51] <JJP> jo [15:52] <CABAListic> die möglichen einheiten, die ein gebäude produzieren kann, wären effekte [15:52] <CABAListic> hehehe, wie gesagt, das ist eigentlich schon ein verdammt hoher grad an flexibilität, wenn man das richtig macht :) [15:52] <JJP> hm, wie herum macht man es wenn eine einheit z.B. anderen einheiten boni gibt? [15:53] <CABAListic> ein effekt auf der quelleinheit, der in einem radius auf alle anderen wirkt, denke ich [15:53] <JJP> hat jede einheit den effekt jeder möglichen aura, der durch den effekt der einheit mit aura “angeschaltet” wird wenn die in der nähe ist? [15:53] <CABAListic> nein, das denke ich, wäre umständlich [15:54] <JJP> hm, es würde zumindest automatisch verhindern, dass auren doppelt oder mehrfach wirken [15:55] <CABAListic> das ist wahr, aber es wäre ein mehraufwand in programmierung und verwaltung, denke ich. da wäre es einfacher, als effektwirkung eine variable auf der einheit zu setzen [15:55] <JJP> ok, der verwaltungsaufwand ist höher weil das erstellen einer neuen aura erfordern würde allen bisherigen einheiten einen neuen effekt zu geben [15:56] <CABAListic> ich denke, effekte sollten folgende grundeigenschaft haben: ausgangspunkt des wirkens (objekt oder punkt), reichweite, wirkdauer (permanent oder begrenzt) [15:56] <CABAListic> art der betroffenen objekte: gebäude, einheiten, freundlich, feindlich, eigene? [15:56] <JJP> oder nur “sich selbst” [15:56] <CABAListic> richtig [15:57] <CABAListic> und dann bräuchte es aktivierungs- und deaktivierungsfunktionen, die dann so ziemlich alles mögliche tun können müssten :) [16:01] <JJP> hm, vielleicht hat man die spieler auch als “objekt” das ziel von effekten sein kann [16:11] <CABAListic> hm ja, ich denke, da sollte man noch einige gedanken reinstecken. richtig gemacht würde es wirklich eine sehr hohe flexibilität mit sich bringen, sogar mehr, als ich anfangs gedacht hätte, hehe. aber es muss sich mit standardspielmechaniken vertragen [16:12] <JJP> jo [16:12] <CABAListic> wenn man z. b. waffen als effekte realisiert, dann muss die standardattacke über rechtsklick damit kommunizieren [16:12] <CABAListic> die einheit muss z. b. wissen, wenn sie näher rangehen muss etc. [16:12] <CABAListic> aber alles in allem imho ein vielversprechender ansatz :) [16:13] <JJP> hm, die KI der einheit muss ja sowieso schon in der lage zu sein mit den effekten zu “kommunizieren”, z.B. auch für zauberfähigkeiten [16:14] <CABAListic> ja… [16:14] <CABAListic> das ist korrekt, das ist dieselbe geschichte dann :) [16:15] <JJP> und sich zu bewegen ist strenggenommen dann auch eine fähigkeit ;) [16:16] <CABAListic> hm, hehe, ja, aber hier könnte ein effekt wahrscheinlich höchstens aktivieren oder deaktivieren… mit bewegen ist auch pathfinding etc. verbunden, das muss schon fest in die engine… [16:16] <JJP> jo [16:17] <JJP> durch den ansatz kommt man immerhin auch dazu, dass man alles von einem “objekt” ableitet [16:20] <JJP> bzw. ist dann eine einheit im grunde wie ein gebäude das sich bewegen darf [16:20] <CABAListic> joah, im prinzip… :) [16:21] <CABAListic> EIGENTLICH könnten beide evtl. einfach nur objekte mit einer unterschiedlichen sammlung an effekten sein… [16:21] <JJP> jo [16:22] <CABAListic> das könnte sogar mensi gefallen, denke ich ;) [16:22] <CABAListic> aber man muss es verdammt gut durchdacht haben, sonst verschenkt man potential oder könnte in performancefallen laufen :) [16:22] <CABAListic> man braucht gute lösungen für aktivierung und deaktivierung von effekten bei reichweitebeschränkten auslösern :) [16:23] <JJP> ich glaube das ist eine der größten fallen das effizient zu regeln [16:23] <CABAListic> ja, allerdings braucht man die sowieso, wenn man sowas wie auren realisieren will :) [16:24] <CABAListic> man braucht aber halt einen guten ansatz, wann man welche objekte auf ihre entfernung wovon prüfen muss [16:25] <CABAListic> evtl. könnte man bounding-boxen für die effekte als näherung wählen, die mit den effektverursachern bewegt werden [16:25] <JJP> wenn man sagt, dass das die spielelogik mit 30 schritten pro sekunde rechnet würde es sicher z.B. reichen begrenzte effekte nur 3 mal pro sekunde zu überprüfen [16:25] <CABAListic> und wann immer die bounding box sich bewegt oder einheiten sie betreten oder verlassen (müsste man speichern, aber das ist performancemäßig wahrscheinlich nicht so tragisch) [16:25] <CABAListic> dann müsste man genauer prüfen [16:26] <CABAListic> ja, schöner wäre aber, wenn man das polling ganz umgehen könnte :) [16:26] <CABAListic> oder eben wirklich nur dann, wenn sich auch tatsächlich was getan haben kann [16:26] <CABAListic> hm, die bounding boxes funktionieren bei deaktivierung gar nicht, denkfehler [16:26] <CABAListic> naja, da muss man halt ein paar gedanken dran verschwenden :) [16:27] <JJP> hm, bei einheiten, muss man da nicht fast ausgehen dass sich was getan hat? meistens werden sie sich ja schon bewegen [16:29] <CABAListic> hm ja. aber es ist halt eine üble performancefalle, wenn man wirklich alle einheiten gegen jeden reichweitebegrenzten effekt testen müsste. ich würde die nach möglichkeit irgendwie etwas einschränken wollen [16:29] <CABAListic> gut, letztlich ist der check vermutlich auch nicht so tragisch, aber trotzdem :) [16:31] <JJP> das ist vor allem eine sache die im aufwand sicher exponentiell ansteigt je mehr objekte man hat die überprüft werden müssen [16:32] <JJP> bzw. je mehr einheiten eine aura haben (?) [16:33] <CABAListic> das wachstum ist linear mit jeder einfachen einheit, aber glaub exponentiell mit jeder rw-beschränkten aura, die dazukommt [16:34] <CABAListic> oder es ist beides linear, aber die kombination ist bös :) [16:35] <JJP> gibts bei e2160 effekte die reichweitenbeschränkt sind? wer weiß ob da nicht einer der hunde begraben liegt ;) [16:35] <CABAListic> radar, shadow, energie, baureichweite. [16:35] <CABAListic> aber zwei davon betreffen gebäude, die anderen beiden kommen in den meisten games nicht vor… [16:36] <CABAListic> oh, aber regenerator gäbe es noch [16:36] <CABAListic> bei e2150 gab's das banner ;) [16:36] <JJP> und regenerator [16:38] <CABAListic> evtl. ist es doch am einfachsten, von den effekten ausgehend alle objekte in der reichweite zu pollen, vorausgesetzt, man hat hier eine performante methode für. [16:39] <CABAListic> dann bräuchte man noch die liste der einheiten, die den effekt bisher hatte, und die, die man darin nicht mehr findet, muss man den effekt entfernen [16:39] <JJP> vielleicht fragt in e2160 ja jede einheit ständig nach, ob ein effekt in der nähe ist ;) [16:39] <CABAListic> aber eine performante methode, einheiten in einem bestimmten gebiet zu finden, werden wir vermutlich eh brauchen :) [16:39] <JJP> jo [16:39] <CABAListic> evtl. müsste man hier eine art tree konstruieren [16:40] <CABAListic> und die karte in immer feinere bereiche einteilen, quasi [16:40] <JJP> am elegantesten ist es hier einfach wenn man einfach nicht extrem viele einheiten im spiel hat [16:40] <CABAListic> aber das sind so gebiete, wo ich nicht 100% firm bin, was die informatik da schon alles hervorgebracht hat ;) [16:40] <CABAListic> ja, das auch jjp, aber bisschen skalierbarkeit schadet ja nicht :) [16:40] <JJP> jo [16:41] <JJP> und es ist auch eine nette herausforderung da eine intelligente lösung zu finden ;) [16:41] <CABAListic> richtig ;) [16:42] <JJP> ich schätze mal ich bekomme da die richtig interessanten sachen auch erst im hauptstudium zu hören ;) [16:44] <CABAListic> ja, gut möglich. dann bleibt eben recherche, hehe [16:52] <JJP> mal abwarten was mensi dazu sagt ;) [16:58] <JJP> hm, hätte es einen vorteil wenn man sozusagen eine globale “karte” davon hält in welchen bereichen gerade auren wirksam sind und einheiten holen sich davon die information ob ein effekt auf sie wirkt? [16:59] <CABAListic> ja, das wäre noch eine recht einfache möglichkeit für polling. würde vermutlich darauf hinauslaufen, falls wir nicht noch irgendeinen coolen algorithmus ausgraben können *g* [17:00] <JJP> es wäre vielleicht weniger aufwand, weil einheiten mit aura dann nur diese “karte” updaten müssen und vielleicht lässt sich da einiges optimieren [17:01] <CABAListic> eine erste optimierung wäre z. b., diese karte in bestimmte grobe gebiete einzuteilen und die aura in jedem gebiet zu registrieren, in das sie hineinragt [17:01] <JJP> jo [17:01] <CABAListic> dann bräuchten einheiten nur die auren durchgehen, die in ihrem momentanen gebiet tätig sind [17:02] <CABAListic> sowie die, bei denen sie bereits “registriert” waren, um zu prüfen, ob ein effekt evtl eben nicht mehr wirkt [17:04] <JJP> wenn es mal soweit ist kann man ja fleißig testszenarien basteln und ausmessen wieviel mit solchen ansätzen machbar ist :) [17:05] <CABAListic> joah, hehe [17:07] <mensi> [14:58] (JJP) ok mensi, “the green room” ist wirklich nicht schlecht ;) ←- freut mich sowas zu hören [17:07] <mensi> Mir tut grad so bissel alles weh [17:07] <mensi> hab grad Tonnenweise Erde rumgeschaufelt [17:07] <CABAListic> mal was anderes, wie funktioniert das eigentlich mit animationen? eine einheit kann ja im prinzip mehrere animationen parallel laufen haben, z. b. bewegungsanimation und schussanimation. kann man die unabhängig definieren? [17:08] <JJP> hm, über animationen muss ich auch noch viel rausfinden [17:08] <CABAListic> wäre schon praktisch, wenn man verschiedene animationen kombinieren könnte, sonst hat man ja echte mehrarbeit ;) [17:09] <JJP> ja, das geht auf jeden fall [17:09] <CABAListic> ich glaub, in ogre kann ich theoretisch verschiedene animationen updaten. vielleicht können wir ja mal ein testcase machen [17:09] <CABAListic> du bastelst ein pacman, das zusätzlich eine augenlider-blinzel-animation hat, und ich schaue mal, wie man beides gleichzeitig nutzen kann :) [17:09] <mensi> Wegen den Einheiten und Gebietspezifisch: Ein Array mit Listen oder Trees [17:10] <mensi> Da kann man schnell wegnewhmen/hinzufügen [17:10] <mensi> und Suchen mit einem Balanced Tree ist auch O(log(n)) [17:10] <CABAListic> hm, array mit listen wäre tatsächlich auch möglich, dann könnte man die karte wieder grob in einige gebiete aufteilen (array) und da dann rein, welche einheiten da momentan sind… [17:11] <CABAListic> bei einer suche müsste man dann nur die gebiete durchgehen, die von der reichweite und quellort betroffen sind… [17:13] <mensi> Joa geht recht schnell [17:13] <mensi> und auch das moven von einem Gebiet ins andere [17:13] <mensi> da du ein Grid hast [17:13] <CABAListic> jo… [17:13] <CABAListic> hm joah, gefällt mir :) [17:13] <mensi> ein Balanced Tree wär fürs suchen fast noch besser [17:14] <mensi> Extremfall wär natürlich pro Feld ein Element im 2D array [17:14] <mensi> minimalfall 1 grosses Feld, sozusagen die RP Methode ;) [17:14] <CABAListic> hehe, naja, das wär arg übertrieben ;) aber da muss man vermutlich experimentieren [17:15] <CABAListic> zumal wir ja keine echten festen grids für die einheitenposition haben. [17:16] <mensi> Joa, halt als Define oder sogar configdatei value machen [17:16] <mensi> dann kann mans tunen [17:16] <mensi> Ist halt immer ein Speed/Memory Kompromiss [17:16] <CABAListic> joah [17:18] <CABAListic> was hältst du von der idee, dass einheiten/gebäude im spiel im prinzip nur einfache objekte mit unterschiedlichen “effekten” sind? das ist imho flexibler als eine ableitungshierarchie :) [17:18] <JJP> bzw. les den chatlog ;) [17:18] <mensi> btw Reflection ist ne Tolle Sache [17:18] <CABAListic> reflection? [17:18] <mensi> .NET gefällt mir von Tag zu Tag besser [17:19] <mensi> joa, dass man runtime mässig die Typen und Vererbungen der Klassen anschauen kann [17:19] <mensi> sprich ich mach bei meinem IRC CLient zB einfach ein if( IConnection::typeid→IsAssignableFrom(FormXY)) [17:20] <mensi> Und dann weiss ich, ob meine FormXY das IConnection Interface implementiert [17:20] <mensi> so kannst aus Plugins völlig unbekanntes Zeug einlesen [17:20] <mensi> und dennoch damit arbeiten [17:20] <mensi> Im Gegensatz zu so Pointertricks in herkömmlichem C++ [17:21] <CABAListic> naja, C++ ist strenger typisiert. das hat halt je nach verwendungsgebiet vor- und nachteile :) [17:21] <CABAListic> grundsätzlich gelten in C++ solche abfragen wie die obere als schlechtes design ;) [17:24] <mensi> Ne wenn du mit modularen Apps arbeitest, die auch zur Runtime erweitert werden können, dann kommst mit Reflection einfach weiter [17:24] <mensi> evtl auch sauberer [17:25] <CABAListic> naja, bin ich nicht überzeugt von. mit sauberer inheritance und dem richtigen basisinterface sollte sich sowas auch ohne typabfragen realisieren lassen :) [17:26] <CABAListic> zumindest in C++ ist das der korrekte weg