Terminal applicatie (game)

[Sp3ci3s8472]

Als hobby projectje wil ik een simpel spel schrijven wat in een terminal draait. Mijn doel is dat dit zowel op Windows als Linux kan draaien.

Een aantal dingen wil ik graag hierin verwerken; een grafische interface en de mogelijkheid dat mensen kunnen modden.

Nu mijn vraag, wat voor programmeertaal moet ik nemen. Ik zit te twijfelen tussen c++ en c# (mono?), ik ben zelf erg bekend met c# het bevalt mij vooral dat dingen zoals geheugen management gedeeltelijk voor mij worden gedaan.
Het voordeel van c++ is natuurlijk dat het sneller is, nu is het voor mijn applicatie waarschijnlijk niet erg belangrijk maar het speelt toch in mijn achterhoofd mee .

Zijn er nog andere voor of nadelen die ik moet overwegen?

Misschien nog belangrijk om te vermelden, de laatste 3 jaar heb ik vooral met Unity aan een aantal kleine hobby projectjes gewerkt (paar duizend regels code groot), deze stranden vooral omdat ik geen art kan maken en de scope soms te groot is. Maar vandaar mijn ervaring met c#, c++ is vooral "school" niveau.

[Oyster]

Wat let je om met beide opties een proof-of-concept te bouwen waarmee je aan de hand van de resultaten de uiteindelijke stack bepaalt?

[Hydra]

C# is een prima taal om mee aan de slag te gaan. Waarom probeer je 't niet gewoon? .Net Core werkt onder Windows, Mac en Linux.

[farlane]

Als je normaal C# bezigt is het misschien de moeite waard om met dit hobbyproject een andere taal mee te pakken, gewoon om er wat van te leren.

[Marco1994]

.net core lijkt mij het meest geschikt inderdaad als je in een spelvorm ook een GUI wil implementeren. Ook zou je kunnen kijken naar Java, de syntax hiervan komt overeen met C#, wellicht dat prototype een idee is. Dit is soort van java, met het voordel dat er veel librabies bischikbaar zijn die dingen vergemakkelijken als vectors etc.

[Verwijderd]

Ik zou gewoon voor C# kiezen. Makkelijk als je met Unity hebt gewerkt. Quill18 heeft bijv.. een console game gemaakt voor zijn Ludum dare entry. Misschien een mooie kans om eens met Mono te werken.

Maar als je C++ wilt leren, dan is dit een mooi projectje om mee te beginnen. Ik heb zelf ook met C++ een OpenGL gamepje gemaakt, geheugen management is "no-big deal". Bijna nooit had ik problemen met memory management, meer stoeien met de C/C++ syntax

[janwillemCA]

Verwijderd schreef op maandag 13 februari 2017 @ 11:54:
Maar als je C++ wilt leren, dan is dit een mooi projectje om mee te beginnen. Ik heb zelf ook met C++ een OpenGL gamepje gemaakt, geheugen management is "no-big deal". Bijna nooit had ik problemen met memory management, meer stoeien met de C/C++ syntax

Over het algemeen is werken met Pointers en Dynamische geheugen allocatie wel even wennen. Ik weet niet of je het uberhaupt gebruikt hebt?

[Verwijderd]

janwillemCA schreef op maandag 13 februari 2017 @ 14:32:
[...]


Over het algemeen is werken met Pointers en Dynamische geheugen allocatie wel even wennen. Ik weet niet of je het uberhaupt gebruikt hebt?

Ja pointers zijn lastig als je vanaf achtergrond in C# hebt. Dynamische geheugen heb ik niet gebruikt zo ver ik weet.

[janwillemCA]

Verwijderd schreef op maandag 13 februari 2017 @ 14:46:
[...]


Ja pointers zijn lastig als je vanaf achtergrond in C# hebt. Dynamische geheugen heb ik niet gebruikt zo ver ik weet.

Nouja dat is voor een deel dus het geheugen management. Wat soms best een hele administratie kan worden bij grote applicaties.

[Hydra]

Verwijderd schreef op maandag 13 februari 2017 @ 14:46:
Ja pointers zijn lastig als je vanaf achtergrond in C# hebt. Dynamische geheugen heb ik niet gebruikt zo ver ik weet.

Je hebt in C++ gewerkt zonder ooit 'new' te gebruiken?

[DroogKloot]

met een master UU-GMT op zak zou je deze fase toch wel gehad moeten hebben

Op het niveau van hobby projectjes maakt het geen bal uit of je geheugenmanagement uit handen geeft (hooguit als je ze eventueel zou willen demo'en) want je zult toch praktisch nooit tegen de performance limieten van een managed runtime aanlopen, die worden pas op grote schaal relevant en bij een terminal app al helemaal niet. Het is er in C++1x bovendien een stuk simpeler op gemaakt met std::shared_ptr&co (wat de afstand ten opzichte van C# verkleint), alhoewel je nog steeds zelf zult moeten nadenken.

Kortom, kies de omgeving waarmee je het snelste resultaat kunt bereiken.

[.oisyn]

Hydra schreef op maandag 13 februari 2017 @ 16:05:
[...]


Je hebt in C++ gewerkt zonder ooit 'new' te gebruiken?

'new' is hopeloos 1998

janwillemCA schreef op maandag 13 februari 2017 @ 14:32:
[...]


Over het algemeen is werken met Pointers en Dynamische geheugen allocatie wel even wennen. Ik weet niet of je het uberhaupt gebruikt hebt?

Als je het goed doet dan gebruik je pointers alleen voor voor referenties in objecten die de 'pointees' niet ownen, en die doen dus ook nooit iets met new/delete. Degene die de pointees wel ownen gebruiken daarvoor smart pointers als std::shared_ptr en std::unique_ptr, en doen dus óók niets met new/delete (goed, new is een optie, maar beter doe je std::make_shared() of std::make_unique())

[ Voor 63% gewijzigd door .oisyn op 13-02-2017 17:09 ]

[Hydra]

.oisyn schreef op maandag 13 februari 2017 @ 17:04:
'new' is hopeloos 1998

De laatste keer dat ik iets met C++ heb gedaan was in 2001 en het lesmateriaal was absoluut ouder dan 1998 dus dat geloof ik graag

[.oisyn]

Het natuurlijk was een beetje een flauwe opmerking en een referentie naar de oude C++98 standaard, maar sinds C++11 (ik had dus ook 2010 kunnen zeggen ) wordt eigen memory management voor gangbare client code over het algemeen afgeraden (het verandert natuurlijk als je een library implementor bent of iets speciaals wilt doen of zo) in faveure van smart pointers, zodat de lifetime van objecten automatisch gekoppeld is aan die van andere.

Herb Sutter had er een mooie talk over op de laatste CppCon: YouTube: CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default.&#...

Het is in het algemeen een paradigm shift die al langer gaande was, maar pas met C++11 echt bruikbaar was vanwege taalconstructies die het ook echt mogelijk maken (zonder move construction bijvoorbeeld geen std::unique_ptr, en dan zit je met zo'n gedrocht als de inmiddels deprecated std::auto_ptr)

[ Voor 22% gewijzigd door .oisyn op 13-02-2017 17:34 ]

[Oyster]

Wordt dit weer zo'n topic waarin alle middelen, mogelijkheden en hiaten tot in den treuren worden uitgekauwd terwijl mijn nichtje van 6 in de tussentijd vier POC's in elkaar heeft gedraaid met Scratch?

Voor iemand met een CS context master aan de UU is dit een opmerkelijke openingspost eerlijk gezegd.

[Sp3ci3s8472]

Gelijk die opleiding maar eens verwijderen .

De openingspost in wellicht wat opmerkelijk dat komt misschien ook doordat ik het wat laat op de "avond" heb gemaakt en ik meer dan een jaar niet echt meer bezig ben met programmeren. Ik kan zowel met c# als met c++ overweg (ook pointers etc). Alleen is dit voor mij een eerste keer dat ik ook iets voor Linux wil gaan maken. Nu is dit al meer informatie dan ik had verwacht, eigenlijk let het mij niet om gewoon eens aan de slag te gaan met mono.

Aan de UU waren het vooral hele kleine programma'tje; bijvoorbeeld maak een applicatie die een bezier curve en een b-spline kan tekenen, voer object tracking op dit filmpje uit, maak een aantal shaders in hlsl. De focus was meer op de wiskunde dan op het programmeren, wat ik voordat ik begon aan de UU eigenlijk nog niet echt had gedaan .
Mijn eigen focus was vooral op Unity omdat je daar zonder al te veel gezeur gelijk aan de slag kon. Ik denk dat ik voor dit project die insteek ook moet nemen.

Dat pocje had ik op een vrije dag al af gehad, denk alleen niet dat de baas het leuk vind als ik dit tijdens werk uren maak .

In ieder geval bedankt voor de reacties, denk dat dit topic wellicht voor mij in het gootje domme vragen topics had gemoeten (maar, voor alles een eerste keer).

[MrMonkE]

nvm

[ Voor 95% gewijzigd door MrMonkE op 13-02-2017 21:03 ]

[Oyster]

Sp3ci3s8472 schreef op maandag 13 februari 2017 @ 19:14:
Gelijk die opleiding maar eens verwijderen .

De openingspost in wellicht wat opmerkelijk dat komt misschien ook doordat ik het wat laat op de "avond" heb gemaakt en ik meer dan een jaar niet echt meer bezig ben met programmeren. Ik kan zowel met c# als met c++ overweg (ook pointers etc). Alleen is dit voor mij een eerste keer dat ik ook iets voor Linux wil gaan maken. Nu is dit al meer informatie dan ik had verwacht, eigenlijk let het mij niet om gewoon eens aan de slag te gaan met mono.

Aan de UU waren het vooral hele kleine programma'tje; bijvoorbeeld maak een applicatie die een bezier curve en een b-spline kan tekenen, voer object tracking op dit filmpje uit, maak een aantal shaders in hlsl. De focus was meer op de wiskunde dan op het programmeren, wat ik voordat ik begon aan de UU eigenlijk nog niet echt had gedaan .
Mijn eigen focus was vooral op Unity omdat je daar zonder al te veel gezeur gelijk aan de slag kon. Ik denk dat ik voor dit project die insteek ook moet nemen.

Dat pocje had ik op een vrije dag al af gehad, denk alleen niet dat de baas het leuk vind als ik dit tijdens werk uren maak .

In ieder geval bedankt voor de reacties, denk dat dit topic wellicht voor mij in het gootje domme vragen topics had gemoeten (maar, voor alles een eerste keer).

Mijn ervaring met Mono is zéér beperkt, maar ik heb net even de wiki gescand. Als je het over Unity hebt dan ga ik ervan uit dat je Unity bedoelt en niet Unity. Ik ken Unity niet, dus heb even de Unity for Dummies pagina bekeken. Zowel in de topictitel als in de openingspost geef je aan dat je een spel wilt schrijven met een GUI dat cross-platform in een terminal draait. Ik weet niet wat je aspiraties zijn met Unity3D (of zelfs Mono) maar je gaat een hele, hele zware tijd tegemoet als je deze UI renderingsengines binnen de context van een terminal wilt opereren. Of er gaat hier wat verkeerd, of ik snap het niet.

[Ramon]

Begrijp ik goed dat je een textbased game a la Zork wil maken? Dat kan dus echt met alles. Dan hoef je je echt geen zorgen te maken over geheugenmanagement. Ik zou zelf wellicht python gebruiken

[Sp3ci3s8472]

Oyster schreef op maandag 13 februari 2017 @ 20:58:
[...]


Mijn ervaring met Mono is zéér beperkt, maar ik heb net even de wiki gescand. Als je het over Unity hebt dan ga ik ervan uit dat je Unity bedoelt en niet Unity. Ik ken Unity niet, dus heb even de Unity for Dummies pagina bekeken. Zowel in de topictitel als in de openingspost geef je aan dat je een spel wilt schrijven met een GUI dat cross-platform in een terminal draait. Ik weet niet wat je aspiraties zijn met Unity3D (of zelfs Mono) maar je gaat een hele, hele zware tijd tegemoet als je deze UI renderingsengines binnen de context van een terminal wilt opereren. Of er gaat hier wat verkeerd, of ik snap het niet.

Mono staat volgens mij los van Unity3d, ik behoorlijk veel ervaring met Unity3d maar ik wil daar een keer buiten stappen . Zoals je al aan geeft is het sowieso erg lastig om een terminal applicatie te maken met Unity3d, het is daar niet voor bedoelt.

Zork ken ik niet, maar ik wil een rogue like maken.

[Oyster]

Sp3ci3s8472 schreef op maandag 13 februari 2017 @ 23:29:
[...]
Zork ken ik niet, maar ik wil een rogue like maken.
[afbeelding]

Zo'n vermoeden had ik al. Als je weet wat je context wordt kan je aan de hand daarvan je vereisten bepalen en de uiteindelijke keuze voor een taal onderbouwen. In het geval van een portable terminal applicatie denk ik om te beginnen bijvoorbeeld aan keyboard, grids, cells, x/y, events, kleuren, fonts, bitmaps, unicode, blitting, geo-primitieven, collision, etc. Je mogelijkheden zijn eindeloos. Als je jezelf even druk maakt lukt het vast met assembly op de 8086.

Bovenstaande onderwerpen worden al dan niet cross-platform veelal in een library gegoten. Als je jezelf daarop wilt richten is een asm, C, C++ stack mogelijk interessant. Als je gebruik wilt maken van een bestaande library kan je eventueel de Python en consorten weg bewandelen. Wil je multi-player en distributed gaan dan worden run-times zoals C#, Java, etc interessant. Uiteindelijk moet je met een hobby-project jezelf motiveren dus ga er even lekker voor zitten en kies uit wat je leuk vind. Je zit amper gebonden aan een specifieke stack. Tegenwoordig draai je Python op de JVM.

Als ik naar mezelf kijk kan ik overigens wel een verdeling herkennen. Voor taken scripts, voor processen native en voor networked een runtime. En vervolgens gebruik ik Javascript op de cli voor mijn build workflow. Gewoon omdat het kan en ik dat dan even leuk vind.