Duality - 2D Game Engine & Visual Editor - Seite 6 - Projektvorstellungen und Stellenangebote

Treue Seele

04.04.2013, 20:21

Zitat von »TrommlBomml«

Zitat von »David_pb«

Zitat von »TrommlBomml«

Nur eins hat mich sehr gestört: Abkürzungen für Interfaces im Code...

. Danke, bitte formuliere das Interface oder Klassennamen aus!

Wieso stört dich das? Ist doch vollkommen No Go...

Weshalb kürzt denn heute noch Bezeichner? Nur wenn es technische Limitierungen gibt. Ansonsten halte ich die für sehr schlechten Stil. Oder das finde ich bei eine so rundum gelungenen Unternehmung sehr schade. Hier finde ich es besonders schlimm, weil ich Compare an statt Component schreibe.

Normalerweise verwende ich in Source Code Bezeichnern so wenige Abkürzungen wie möglich. An dieser Stelle halte ich eine Ausnahme jedoch für sinnvoll, da "ICmp" als Prefix für eine bestimmte Gruppe von Interfaces zu verstehen ist. Es gibt beispielsweise ICmpUpdatable, ICmpCollisionListener, ICmpInitializable, ICmpRenderer - und alle davon können unter Umständen von einer einzigen Komponente implementiert werden. Der Fokus einzelner Interfacebezeichner sollte hier nicht auf dem ohnehin redundanten "Component"-Teilwort liegen, sondern auf dem was darauf folgt, daher halte ich eine Abkürzung an dieser Stelle für vertretbar.

Man vergleiche mal das Folgende:

	C#-Quelltext
1 2 3 4	public class MyCustomComponent : Component, IComponentUpdatable, IComponentRenderer, IComponentInitializable, IComponentCollisionListener { /* ... */ }

...mit dem hier:

	C#-Quelltext
1 2 3 4	public class MyCustomComponent : Component, ICmpUpdatable, ICmpRenderer, ICmpInitializable, ICmpCollisionListener { /* ... */ }

Ich persönlich würde letztere Variante bevorzugen. Ein komplettes Weglassen des "Cmp" Prefixes wäre jedoch zu viel des Guten, denn so sind die entsprechenden Interfaces nicht mehr auf einen Blick als Komponentenschnittstellen erkennbar. Kleiner Bonus: In der jetzigen Lösung muss man nur an der richtigen Stelle "ICmp" schreiben und Intellisense schlägt einem direkt die möglichen Schnittstellen vor.

Zum Seitenanfang

Sacaldur

Community-Fossil

Beiträge: 2 301

Wohnort: Berlin

Beruf: FIAE

04.04.2013, 21:32

Vielleicht fehlt mir ein wenig Hintergrundwissen zu Duality, aber ich würde auch trotz deiner bisherigen Ausführungen das "Cmp" oder "Component" aus den Interfaces raus halten, sofern sie nicht alle das Interface "IComponent" erweitern.
am ehesten muss ich bei "Komponente" an das Komponentensystem in Unity denken, wo man allerdings keine eierlegende Wollmilchsau Komponente hat, die mehrere Funktionalitäten gleichzeitig übernimmt. Ich finde es also, sollte es mit den Unity-Komponenten vergleichbar sein, nicht gerade sauber, dass ein solcher Fall sogar vorgesehen ist.
Ich lass mich aber auch gerne eines Besseren belehren.

Spieleentwickler in Berlin? (Thema in diesem Forum)
---

Zitat von »Jonathan_Klein«

Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].

Zum Seitenanfang

Treue Seele

04.04.2013, 21:47

Zitat von »Sacaldur«

Vielleicht fehlt mir ein wenig Hintergrundwissen zu Duality, aber ich würde auch trotz deiner bisherigen Ausführungen das "Cmp" oder "Component" aus den Interfaces raus halten, sofern sie nicht alle das Interface "IComponent" erweitern.
am ehesten muss ich bei "Komponente" an das Komponentensystem in Unity denken, wo man allerdings keine eierlegende Wollmilchsau Komponente hat, die mehrere Funktionalitäten gleichzeitig übernimmt. Ich finde es also, sollte es mit den Unity-Komponenten vergleichbar sein, nicht gerade sauber, dass ein solcher Fall sogar vorgesehen ist.
Ich lass mich aber auch gerne eines Besseren belehren.

Auch wenn Duality grundsätzlich einen ähnlichen Komponentenbasierten Ansatz verwendet, so gibt es im Detail doch einige Unterschiede. Den Gedanken hinter den ICmp Interfaces hab ich in meiner Bachelorarbeit beschrieben, daher würde ich an dieser Stelle einfach mal darauf verweisen: Kapitel 3.2 "Objektmanagement", Seite 24

Nur soweit: Sie sind sicher nicht zufällig entstanden oder "weil es gerade so gepasst hat"

Es geht dabei um die Definition einer allgemeinen Schnittstelle, die Komponenten nutzen können um miteinander und anderen Objekten zu kommunizieren - die jedoch zur Compilezeit nicht unbedingt bekannt sind. Gleichzeitig soll aber auch die Schnittstelle selbst erweiterbar sein, daher wurde von einer monolithischen Implementierung à la "IComponent" oder virtuellen Methoden in "Component" abgesehen.

EDIT: Link auf Google Code umgeleitet, wegen Traffic. Unglücklicherweise ist das Pdf über 30 Mb groß.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Fetze« (04.04.2013, 22:16)

Zum Seitenanfang

TrommlBomml

Community-Fossil

Beiträge: 2 117

Wohnort: Berlin

Beruf: Software-Entwickler

05.04.2013, 07:40

Zitat von »Fetze«
Zitat von »TrommlBomml«

Zitat von »David_pb«

Zitat von »TrommlBomml«

Nur eins hat mich sehr gestört: Abkürzungen für Interfaces im Code...

. Danke, bitte formuliere das Interface oder Klassennamen aus!

Wieso stört dich das? Ist doch vollkommen No Go...

Weshalb kürzt denn heute noch Bezeichner? Nur wenn es technische Limitierungen gibt. Ansonsten halte ich die für sehr schlechten Stil. Oder das finde ich bei eine so rundum gelungenen Unternehmung sehr schade. Hier finde ich es besonders schlimm, weil ich Compare an statt Component schreibe.

Normalerweise verwende ich in Source Code Bezeichnern so wenige Abkürzungen wie möglich. An dieser Stelle halte ich eine Ausnahme jedoch für sinnvoll, da "ICmp" als Prefix für eine bestimmte Gruppe von Interfaces zu verstehen ist. Es gibt beispielsweise ICmpUpdatable, ICmpCollisionListener, ICmpInitializable, ICmpRenderer - und alle davon können unter Umständen von einer einzigen Komponente implementiert werden. Der Fokus einzelner Interfacebezeichner sollte hier nicht auf dem ohnehin redundanten "Component"-Teilwort liegen, sondern auf dem was darauf folgt, daher halte ich eine Abkürzung an dieser Stelle für vertretbar.

Man vergleiche mal das Folgende:
C#-Quelltext
1
2
3
4
public class MyCustomComponent : Component, IComponentUpdatable, IComponentRenderer, IComponentInitializable, IComponentCollisionListener
{
  /* ... */
}
...mit dem hier:
C#-Quelltext
1
2
3
4
public class MyCustomComponent : Component, ICmpUpdatable, ICmpRenderer, ICmpInitializable, ICmpCollisionListener
{
  /* ... */
}
Ich persönlich würde letztere Variante bevorzugen. Ein komplettes Weglassen des "Cmp" Prefixes wäre jedoch zu viel des Guten, denn so sind die entsprechenden Interfaces nicht mehr auf einen Blick als Komponentenschnittstellen erkennbar. Kleiner Bonus: In der jetzigen Lösung muss man nur an der richtigen Stelle "ICmp" schreiben und Intellisense schlägt einem direkt die möglichen Schnittstellen vor.

Ich empfinde es genau anders herum

. Wenn du von so vielen Interfaces erbst, wäre es vielleicht sinnvoller, Interfaces zusammenzufassen oder abstrakte Basisklassen anbieten an statt die Namen zu kürzen. Wenn es wenigstens "Comp" an statt "Cmp" heißen würde, wäre es noch halbwegs verschmerzbar. Ich lese sofort ICompareUpdatable, ICompareRenderer, ... usw. Und wenn dann wäre viellicht IUpdatableComponent usw. auch besser formuliert - davon sprichst du sogar in deiner Bachelorarbeit Seite 24

.

Es war auch nur ein Vorschlag, über Namensgebung von Klassen ist eh meistens ein Streitthema wenn sich zwei gefunden haben

Zum Seitenanfang

Treue Seele

05.04.2013, 07:49

Zitat von »TrommlBomml«

Interfaces zusammenzufassen oder abstrakte Basisklassen anbieten an statt die Namen zu kürzen

Zitat von »TrommlBomml«

davon sprichst du sogar in deiner Bachelorarbeit Seite 24 .

Du scheinst die entsprechende Textstelle in meiner Arbeit allerdings nur überflogen zu haben - denn beide Möglichkeiten gingen hier an der eigentlichen Zielsetzung vorbei.

Würde allerdings an dieser Stelle wirklich sagen, wir belassen es bei "Ist Ansichtssache". Ich habe meine Gründe und du hast deine. Ich gehe davon aus, dass beide Argumentationen ihre Daseinsberechtigung haben

Edit: Achja, nur um diesbezüglich mal Klarheit geschaffen zu haben: Mein obiges Beispiel war exemplarischer Natur. Natürlich wird man normalerewise nicht von allen Interfaces gleichzeitig erben, sondern nur von einigen wenigen.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Fetze« (05.04.2013, 07:57)

Zum Seitenanfang

xardias

Community-Fossil

Beiträge: 2 731

Wohnort: Santa Clara, CA

Beruf: Software Engineer

06.04.2013, 18:04

Zitat von »Fetze«

Man vergleiche mal das Folgende:

	C#-Quelltext
1 2 3 4	public class MyCustomComponent : Component, IComponentUpdatable, IComponentRenderer, IComponentInitializable, IComponentCollisionListener { /* ... */ }

...mit dem hier:

	C#-Quelltext
1 2 3 4	public class MyCustomComponent : Component, ICmpUpdatable, ICmpRenderer, ICmpInitializable, ICmpCollisionListener { /* ... */ }

Wegen solcher Zeilen gibt es sinnvollerweise in den meisten Style Guidelines eine Beschraenkung der Zeilenlaenge (ueblicherweise 80 Zeichen fuer die command line nerds

). Dann sind lange Namen auch kein Problem, da sie untereinander stehen, statt nebeneiannder.
Ob man Interfacenamen abkuerzen moechte ist Geschmackssache, aber soweit ich mit bekommen habe ist der allgemein akzeptierte Geschmack dies nicht zu tun...

Zum Seitenanfang

Spiele Programmierer

Alter Hase

Beiträge: 1 223

Wohnort: Deutschland Bayern

Beruf: Schüler

07.04.2013, 01:37

Mit dem Abkürzen selber habe ich weniger ein Problem, als damit, dass die C-Stdlib mich "Cmp" automatisch an "Compare" denken lässt.
Und als ich hier reingeschaut habe, habe ich mir echt gedacht, was wohl ein "IComparerUpdatable" sein soll.

Zitat

Wegen solcher Zeilen gibt es sinnvollerweise in den meisten Style Guidelines eine Beschraenkung der Zeilenlaenge (ueblicherweise 80 Zeichen fuer die command line nerds)

Wenn du mich fragst, ist das gar nicht sinnvoll.
Ich nehme mal an, ich habe hier den wohl einer der kleinsten Bildschirme hier (1280*1024), aber habe trotzdem mehr Platz in die Breite, als 80 Zeichen. Und selbst wenn man für eine Klassendeklararaton mal ein bisschen nach rechts scrollen muss, stört das mich doch gar nicht. Um so mehr stört es mich aber, wenn man dauernd vertikal scrollen muss und keine Übersicht über den Code bekommt, weil alles auf viel mehr Zeilen aufgeteilt ist, als nötig.

Zum Seitenanfang

xardias

Community-Fossil

Beiträge: 2 731

Wohnort: Santa Clara, CA

Beruf: Software Engineer

07.04.2013, 02:59

Zitat von »Spiele Programmierer«

Wenn du mich fragst, ist das gar nicht sinnvoll.
Ich nehme mal an, ich habe hier den wohl einer der kleinsten Bildschirme hier (1280*1024), aber habe trotzdem mehr Platz in die Breite, als 80 Zeichen.

Yep, du hast Platz fuer 2x 80 Zeichen nebeneinander

Zum Seitenanfang

Treue Seele

13.05.2013, 23:08

Community Forum

In den vergangenen Monaten habe ich immer wieder E-Mails und PNs zu verschiedenen Duality-verwandten Themen bekommen, teilweise über meinen Blog, teil weise über dieses und andere Foren. Außerdem wirkt es, als gäbe es mittlerweile Leute, die Duality als Grundlage für eigene Projekte nutzen, durch eigene Plugins erweitern oder auf anderem Wege am Projekt teilhaben wollen. Es war also langsam an der Zeit, für eine zentrale Kommunikationsplattform zu sorgen, damit nicht immer alles direkt über mich laufen muss. Mit anderen Worten: Ich hab mal ein Forum aufgesetzt.

--> Duality Forum <--

Ziel ist es, eine zentrale Plattform zum Austausch von Erfahrungen mit Duality zu schaffen. Themen, die wunderbar dort hinein passen:

Ich will ein Spiel mit Duality umsetzen. Wo fange ich an?
Wie löse ich Problem X?
Ich hätte gerne Feature Y, geht das?
Das hier ist mein Projekt! Feedback?
Ich habe ein Plugin für Duality geschrieben / einen tollen Workflow gefunden / ein verstecktes Feature entdeckt / ein tolles Codeschnipsel geschrieben
Du hast in deinem Blog geschrieben, dass [...] und ich habe was dazu zu sagen.
Fragen und Anmerkungen zu vergangenen Projekten meinerseits

Ist natürlich alles noch ein wenig leer, aber das macht nix. Anzustreben wäre nur, dass bei Themen der obigen Liste einfach keine PN oder E-Mail mehr an mich gesendet wird sondern ein Thread im Duality Forum erstellt - so profitieren dann auch andere davon

Zum Seitenanfang

Treue Seele

29.06.2013, 01:17

Der Ernstfall

Es ist mal wieder eine Menge passiert in den letzten sechs Wochen. Neben zahllosen Bugfixes, Tweaks, einem überholten Inputsystem, Joystick Support, Performance- und Speicheroptimierungen sowie einer SVN-freundlicheren XML Serialisierung gibt es für Duality auch eine Neuerung ganz anderer Natur: Es muss sich erstmals in professioneller Anwendung beweisen.

Der aktuelle Stand ist, dass ich Duality im Rahmen meiner Tätigkeit als Wissenschaftlicher Mitarbeiter gemeinsam mit einem Arbeitskollegen einsetze, um einen vergleichsweise kleinen Teil eines Forschungsprojekts voran zu treiben. Aufgrund der üblichen Vereinbarungen, Interna des Projekts vertraulich zu behandeln möchte ich da an dieser Stelle mal nicht weiter drauf eingehen - Fakt ist aber, wir haben eine Menge Zeit mit Prototyping verbracht und ausgelotet, wie Duality mit unseren Ideen und Umsetzungen klarkommt. Resultat: Soweit recht gut.

Als Nebenprodukt dabei herausgesprungen ist die Möglichkeit, Duality per Gamepad, Joystick oder sonstigem Eingabegerät anzusteuern. Darüber hinaus ist es möglich, durch eigene Implementierung im CorePlugin Geräte anzusteuern, die Windows nicht als Game Controller erkennt, oder aber um beliebigen User Input per Software zu emulieren. Ebenfalls ausprobiert haben wir, ob es ohne Weiteres möglich ist, einen eigenen DualityLauncher zu implementieren, beispielsweise um Multi-Monitor Support nachzurüsten oder Duality mit WinForms zu kombinieren - auch das klappt relativ problemlos und wird nun explizit unterstützt.

(Link)

Parallel dazu ist nun offiziell geworden, was sich bereits seit ein paar Wochen im Stillen ankündigte: Das sechsköpfige Indie-Team BatCat Games hat sich dazu entschlossen, Duality für sein nächstes Projekt zu verwenden, das allem Anschein nach den Namen Honourbound tragen soll - nachzulesen in einem aktuellen Blogeintrag des Teams. Dort wird auch ein Video eines alten (prä-Duality) Prototyps gezeigt, der einem schonmal eine grobe idee davon gibt, in welche Richtung das Ganze einmal gehen soll:

Ich bin jedenfalls sehr gespannt, wohin die Reise geht und hoffe sehr, dass sich die Entscheidung Duality zu nutzen für BatCat Games am Ende lohnen wird. Ein wenig mulmig ist mir dabei schon - es ist, als wären alle zuvor an Duality angelegten Maßstäbe plötzlich nicht mehr gültig und durch eine neue, gewichtigere Betrachtung ersetzt worden. Es bleibt jedenfalls spannend.