Onko pythonissa vastinetta WPF:lle?

Kuten tuossa sanoin: kartoitan vaihtoehtoja. Jos käyttöliittymä olisi ainoa vaikuttava asia, niin enhän minä WPF:lle vaihtoehtoja tarvitsisi.
Pythonista olisi kuitenkin muita hyötyjä, kuten se, että tiedostojen käsittely ja useamman ytimen/säikeen käyttö sujuu helpommin.

Anonyymi kirjoitti:

Kuten tuossa sanoin: kartoitan vaihtoehtoja. Jos käyttöliittymä olisi ainoa vaikuttava asia, niin enhän minä WPF:lle vaihtoehtoja tarvitsisi.
Pythonista olisi kuitenkin muita hyötyjä, kuten se, että tiedostojen käsittely ja useamman ytimen/säikeen käyttö sujuu helpommin.

Lue lisää

No jos olet sitä mieltä että uuden opettelu on helpompaa ja käy vaihtoehtona sinulle helpon WPF ympäristön sijasta, ei tarvitse kovin kauas mennä kun yhtäläisyyksiä löytyy, nimittäin https://ironpython.net/ mahdollistaa WPE -koodin sakottamisen python koodin sisään. En itse tunne tuota IronPythonia, mutta näin sitä kehutaan;

IronPython on erinomainen lisä .NET Frameworkiin, joka tarjoaa Python-kehittäjille .NET-kehyksen voiman. Nykyiset .NET-kehittäjät voivat myös käyttää IronPythonia nopeana ja ilmeikkäänä komentosarjakielenä uuden sovelluksen upottamiseen, testaamiseen tai kirjoittamiseen tyhjästä.

Anonyymi kirjoitti:

No jos olet sitä mieltä että uuden opettelu on helpompaa ja käy vaihtoehtona sinulle helpon WPF ympäristön sijasta, ei tarvitse kovin kauas mennä kun yhtäläisyyksiä löytyy, nimittäin https://ironpython.net/ mahdollistaa WPE -koodin sakottamisen python koodin sisään. En itse tunne tuota IronPythonia, mutta näin sitä kehutaan;

IronPython on erinomainen lisä .NET Frameworkiin, joka tarjoaa Python-kehittäjille .NET-kehyksen voiman. Nykyiset .NET-kehittäjät voivat myös käyttää IronPythonia nopeana ja ilmeikkäänä komentosarjakielenä uuden sovelluksen upottamiseen, testaamiseen tai kirjoittamiseen tyhjästä.

Lue lisää

Kiitos vinkistä. Täytyy tutustua tuohon IronPythoniin.

Ja tarkennuksena vielä: en etsi WPF:ää helpompaa vaihtoehtoa (koska sellaista tuskin on olemassakaan) vaan ylipäätään käyttökelpoista vaihtoehtoa, jolloin voisin toteuttaa koko projektin pythonilla C#:n sijaan.

Jos käyttöliittymän tekeminen IronPythonilla tai jollain muulla vastaavalla on liian työlästä niin joudun kuitenkin näkemään vaivaa kun selvitän miten kaiken muun saa toteutettua .NET:n ja C#:n kanssa.

Anonyymi kirjoitti:

Kiitos vinkistä. Täytyy tutustua tuohon IronPythoniin.

Ja tarkennuksena vielä: en etsi WPF:ää helpompaa vaihtoehtoa (koska sellaista tuskin on olemassakaan) vaan ylipäätään käyttökelpoista vaihtoehtoa, jolloin voisin toteuttaa koko projektin pythonilla C#:n sijaan.

Jos käyttöliittymän tekeminen IronPythonilla tai jollain muulla vastaavalla on liian työlästä niin joudun kuitenkin näkemään vaivaa kun selvitän miten kaiken muun saa toteutettua .NET:n ja C#:n kanssa.

Lue lisää

"Ja tarkennuksena vielä: en etsi WPF:ää helpompaa vaihtoehtoa (koska sellaista tuskin on olemassakaan) vaan ylipäätään käyttökelpoista vaihtoehtoa, jolloin voisin toteuttaa koko projektin pythonilla C#:n sijaan."

WPF tuskin on helpoin siihen GUI:n. Jos nyt tarvitsee vain ne napit ja vastaavat niin tästä voisi lähteä tutkimaan: https://microsoft.github.io/frontend-bootcamp/

TypeScript kielenä, React komponenttien tekoon ja Fluent UI sitten UI frameworkkina: https://developer.microsoft.com/en-us/fluentui

En nyt silleen ymmärrä miksi sen kielen pitäisi olla Python. C# on ihan kiva kieli, samoin TypeScript. Minusta tuossa ratkaisee enemmän nuo kaikki muut jutut mitä tarvitsee rakentamiseen. Esimerkiksi Unityllä voi olla kätevää tehdä ja voi käyttää C#:a.

Anonyymi kirjoitti:

"Ja tarkennuksena vielä: en etsi WPF:ää helpompaa vaihtoehtoa (koska sellaista tuskin on olemassakaan) vaan ylipäätään käyttökelpoista vaihtoehtoa, jolloin voisin toteuttaa koko projektin pythonilla C#:n sijaan."

WPF tuskin on helpoin siihen GUI:n. Jos nyt tarvitsee vain ne napit ja vastaavat niin tästä voisi lähteä tutkimaan: https://microsoft.github.io/frontend-bootcamp/

TypeScript kielenä, React komponenttien tekoon ja Fluent UI sitten UI frameworkkina: https://developer.microsoft.com/en-us/fluentui

En nyt silleen ymmärrä miksi sen kielen pitäisi olla Python. C# on ihan kiva kieli, samoin TypeScript. Minusta tuossa ratkaisee enemmän nuo kaikki muut jutut mitä tarvitsee rakentamiseen. Esimerkiksi Unityllä voi olla kätevää tehdä ja voi käyttää C#:a.

Lue lisää

Minä pidän kyllä WPF:ää helpompana kuin mitään JavaScript-johdannaisia, vaikka toki ymmärrän että se on makuasia. JS:lle (ja TS:lle) olen sen verran allerginen, että en käytä niitä ellei jokin asia projektissa sitä aivan välttämättä vaadi.

C#:istä kyllä tykkään ja muihin projekteihin käytänkin sitä ihan mielelläni, mutta lähinnä silloin jos ohjelmasta on odotettavissa sen verran raskas, että olisi fiksua käyttää useampia ytimiä/säikeitä, niin suosin pythonia. Kyllähän tuon moniydinajon saa C#:illakin aikaiseksi, mutta ei se ihan yhtä näppärästi käy.

Kiitoksia tästäkin vinkistä. Tähän projektiin en tosin aio JavaScript-johdannaisia sotkea, kun tarkoitus olisi nimenomaan vähentää työmäärää eikä kymmenkertaistaa sitä.

Jos JS olisi muuten välttämätön tässä projektissa niin voisin kyllä harkita, mutta koska koko homma on muuten mahdollista hoitaa järkevämmillä kielillä, niin en pelkän käyttöliittymän takia viitsi tehdä muista asioista vaikeampia.

Anonyymi kirjoitti:

Kiitoksia tästäkin vinkistä. Tähän projektiin en tosin aio JavaScript-johdannaisia sotkea, kun tarkoitus olisi nimenomaan vähentää työmäärää eikä kymmenkertaistaa sitä.

Jos JS olisi muuten välttämätön tässä projektissa niin voisin kyllä harkita, mutta koska koko homma on muuten mahdollista hoitaa järkevämmillä kielillä, niin en pelkän käyttöliittymän takia viitsi tehdä muista asioista vaikeampia.

Lue lisää

Eikö siinä pelissä ole grafiikkaa ollenkaan?

Yleensä pelejä vääntäessä käyttöliittymä merkitsee melko vähän ja säikeistys vielä vähemmän ja suurin kustannus siitä miten kaiken hässäkän saa tehtyä.

TypeScript ei lisää työmäärää ja se on eri kieli kuin Javascript. TypeScript käännetään Javascriptille ja efekti on sama kuin käännät C#:a tai Pythonia sille .NET:n CIL -kielelle.

TypeScript on kyllä ns. superset Javascriptistä, että halutessaan saa käytettyä mitä tahansa Javascript kirjastoa mutta kun kääntää natsivivut päälle niin sitten ei tietenkään JavasScript kura käy kun on kaikki tyypitettynä. Puhtaasti TypeScriptillä ohjelmoidessa ohjelmointi on kivaa eikä se mitään työmäärää lisää.

Ennemmin kannattaisi pohtia sitä että mikä ominaisuus siinä Pythonissa on niin ratkaisevaa. Tuota säikeistysasiaa en ihan hahmoita kun koodi kun on tilatonta, tilan muutoksia ei ole miten sattuu ja on funktionaalista niin nuohan säikeistyy käytännössä millä kielellä vaan siististi. Itseasiassa kun koodin rakenne on siisti niin se säikeistyy suurelta osin automaattisesti. Tuohon asiaan harvemmin tarvitsee ohjelmoijan itse tehdä säätämistä lisäämällä johonkin palikoihin säikeitä.

Ohjelman logiikan kannalta "tiedosto" on myös oikeastaan turha kun peleissä kyse on ennemminkin asseteista ja persistoidusta datasta. Peliä tehtäessä ei oikeastaan tarvitse mennä niin matalalle tasolle, että tarvitsisi käyttää yhtään koodia tiedostojen käsittelyyn.

Noin niinkuin äkkiseltään mietittynä saat työmäärää vähennettyä kun jätät matalan tason tarpeettoman nysvän pois ja käytät valmiiksi tehtyjä asioita. Tuo sitten pätee mihin tahansa kieleen.

Siksi sillä kielelläkään ei ole niin väliä kun ei vaivaa päätä niillä tiedostoilla ja säikeillä. Siksi mainitsin tuon BabylonJS:n ja Unityn kun ratkaisevat näitä tavallisempia työprosessissa vaadittavia asioita, että miten saa tuotettua pelin grafiikat helposti ja siirrettyä ne asseteiksi siihen pelisovellukseen. Tietysti jos on vain kaksiulotteisia grafiikkapintoja niin se helpottaa toki paljon.

Mutta, löytyi ratkaisu...

https://alpha.iodide.io/
https://github.com/iodide-project/pyodide

Eli Mozilla modernisoinut Python stäkin selaimeen ja vähän kun googletti niin sitten oli Reactia käytetty myös: https://alpha.iodide.io/notebooks/362/

Anonyymi kirjoitti:

Kiitoksia tästäkin vinkistä. Tähän projektiin en tosin aio JavaScript-johdannaisia sotkea, kun tarkoitus olisi nimenomaan vähentää työmäärää eikä kymmenkertaistaa sitä.

Jos JS olisi muuten välttämätön tässä projektissa niin voisin kyllä harkita, mutta koska koko homma on muuten mahdollista hoitaa järkevämmillä kielillä, niin en pelkän käyttöliittymän takia viitsi tehdä muista asioista vaikeampia.

Lue lisää

Sellainen juttu tuli mieleen, että käyttöliittymän voi tehdä eri kielellä kuin muun osan pelistä. Voi siis valita eri tilanteissa sopivimman kielen.

Voit käytännössä jakaa sen pelin arkkitehtuurin näin:

1. Käyttöliittymän näkymä, tapahtumat ja käyttöliittymän tilanmuutokset
2. Edustalla tapahtuva laskenta (käännät moduuleja joita voit kutsua käyttöliittymästä)
3. Persistoidun datan ja taustalaskennan ohjaus
4. Taustalla tapahtuva laskenta

Nuo on kaikki tehtävissä eri kielillä.

Tässä yksi millä voit tehdä käyttöliittymän, C#:a: https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

Anonyymi kirjoitti:

Sellainen juttu tuli mieleen, että käyttöliittymän voi tehdä eri kielellä kuin muun osan pelistä. Voi siis valita eri tilanteissa sopivimman kielen.

Voit käytännössä jakaa sen pelin arkkitehtuurin näin:

1. Käyttöliittymän näkymä, tapahtumat ja käyttöliittymän tilanmuutokset
2. Edustalla tapahtuva laskenta (käännät moduuleja joita voit kutsua käyttöliittymästä)
3. Persistoidun datan ja taustalaskennan ohjaus
4. Taustalla tapahtuva laskenta

Nuo on kaikki tehtävissä eri kielillä.

Tässä yksi millä voit tehdä käyttöliittymän, C#:a: https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

Lue lisää

Juu, teen tietysti M-V-VM-periaatteella tuon, että käyttöliittymän ja grafiikkojen muokkaus ja parantelu onnistuu mahdollisimman kivuttomasti myöhemmin.

Koko tämä ajatus lähti oikeastaan siitä, että haluaisin käyttää WPF:ää ja C#:ia käyttöliittymäpuoleen (ja ainakin demossa grafiikat muutenkin hoituu kokonaan siinä sivussa) ja muuhun taustallaolevaan Pythonia, mutta noiden yhdistämisen opettelu tuntuu vaivalloisemmalta kuin kumpikaan vaihtoehdoista, eli koko homman hoitaminen C#:lla tai koko homman hoitaminen Pythonilla (sisältäen WPF:n korvikkeeseen perehtymisen).

JavaScriptiä ja sen kavereita minä käytän ainoastaan jos jotain täytyy saada näkyviin netissä, koska siihen ne toimivat kohtuullisesti (ja siihenhän ne on alunperin tarkoitettu).
Kaikessa muussa ohjelmoinnista niiden käyttö tuntuu siltä kun yrittäisi kuoria appelsiinia vasaralla. Kyllähän se onnistuu, mutta ei se kivaa ole eikä lopputulos ole kovin siisti. Ja kyllä tiedostan myös, että se tuntuisi paljon vähemmän hirveältä jos tekisin sitä useammin.

Säikeistystä käytetään peleissä minun mielestäni aivan liian vähän. Kaikissa nykykoneissa on useampia ytimiä ja vielä useampia säikeitä, joista kaikki paitsi yksi odottelevat tyhjän panttina hoitamassa kaikkea taustalla pyörivää sillä välin kun yksi ydin pyörittää koko peliä.
Tietenkään missään räiskintäpeleissä yms. sillä ei ole juurikaan väliä, kun käytännössä aina kapasiteetti loppuu ensin näytönohjaimesta, mutta hölmöltä se silti tuntuu, ja etenkin strategiapeleissä jouduttaisiin tekemään paljon vähemmän huonoja kompromisseja jos pelinkehittäjät viitsisivät käyttää säikeistystä.

Anonyymi kirjoitti:

Juu, teen tietysti M-V-VM-periaatteella tuon, että käyttöliittymän ja grafiikkojen muokkaus ja parantelu onnistuu mahdollisimman kivuttomasti myöhemmin.

Koko tämä ajatus lähti oikeastaan siitä, että haluaisin käyttää WPF:ää ja C#:ia käyttöliittymäpuoleen (ja ainakin demossa grafiikat muutenkin hoituu kokonaan siinä sivussa) ja muuhun taustallaolevaan Pythonia, mutta noiden yhdistämisen opettelu tuntuu vaivalloisemmalta kuin kumpikaan vaihtoehdoista, eli koko homman hoitaminen C#:lla tai koko homman hoitaminen Pythonilla (sisältäen WPF:n korvikkeeseen perehtymisen).

JavaScriptiä ja sen kavereita minä käytän ainoastaan jos jotain täytyy saada näkyviin netissä, koska siihen ne toimivat kohtuullisesti (ja siihenhän ne on alunperin tarkoitettu).
Kaikessa muussa ohjelmoinnista niiden käyttö tuntuu siltä kun yrittäisi kuoria appelsiinia vasaralla. Kyllähän se onnistuu, mutta ei se kivaa ole eikä lopputulos ole kovin siisti. Ja kyllä tiedostan myös, että se tuntuisi paljon vähemmän hirveältä jos tekisin sitä useammin.

Säikeistystä käytetään peleissä minun mielestäni aivan liian vähän. Kaikissa nykykoneissa on useampia ytimiä ja vielä useampia säikeitä, joista kaikki paitsi yksi odottelevat tyhjän panttina hoitamassa kaikkea taustalla pyörivää sillä välin kun yksi ydin pyörittää koko peliä.
Tietenkään missään räiskintäpeleissä yms. sillä ei ole juurikaan väliä, kun käytännössä aina kapasiteetti loppuu ensin näytönohjaimesta, mutta hölmöltä se silti tuntuu, ja etenkin strategiapeleissä jouduttaisiin tekemään paljon vähemmän huonoja kompromisseja jos pelinkehittäjät viitsisivät käyttää säikeistystä.

Lue lisää

"mutta noiden yhdistämisen opettelu tuntuu vaivalloisemmalta kuin kumpikaan vaihtoehdoista"

HTTP REST API toimii peleissä siinä missä muissakin ohjelmissa.

Ei sillä ole väliä tekeekö sen API kyselyn millä kielellä tehdystä sovelluksesta, ja HTTP protokolla on tilaton. Tämä tarkoittaa sitä, että jokainen API kysely taustalla toimivaan koodiin saadaan rinnakkaistumaan hyvin helposti. Ja jos siellä on API joka ei hoida datan persistointia ja hakua vaan vaikka laskentaa niin sinne saa helposti workereita niin paljon kuin ytimiä riittää. Tarvitsee olla jokin kommunikaatiokanava millä toimivat. Jos ei muuta niin vaikka stdin/sdout

Käyttöliittymä sitten menee niinikään yhdellä säikeellä mutta jos edustalla jotain laskentaa niin voi kääntää komponentteja eri kielellä. Tarvitsee vain sinnekin yhtenäisen kommunikaatiokanavan millä ajetaan koodia. Tuossa lähinnä ratkotaan se, että millä tavalla päätät eri kielillä kirjoitettujen komponenttien välisen yhteyden suorittaa.

"JavaScriptiä ja sen kavereita minä käytän ainoastaan jos jotain täytyy saada näkyviin netissä, koska siihen ne toimivat kohtuullisesti (ja siihenhän ne on alunperin tarkoitettu)."

Javascript on käytännössä assembler. Vähän niinkuin vaikka .NET:n CIL. Tai vaikka JVM:n tavukoodi. Tai Python kun kääntelee .pyc tiedostoja. Ei sillä mitään kirjoiteta. Voit siis kääntää vaikka C#:a tai Pythonia Javascriptiksi jos niin haluat tai vaikka C :aa.

Käytännössä sinun tarvitsee miettiä se edustapuolella toimivan koodin arkkitehtuuri, että voit käytellä eri työkaluja ja käännellä komponentteja mitkä toimivat keskenään. Nykyään selain on tässä standardi tapa kun se on ihan joka paikassa. Koodia ei tarvitse kääntää Javascriptiksi vaan voi kääntää myös Webassemblyksi. Toiminnallisesti näissä ei ole mitään eroa. Webassemblyllä vaan saadaan lisää suorituskykyä ja mutta kaikilla kielillä ei vielä ole työkaluketjua siihen, että saisi käännettyä Webassemblyksi. Tässä näköjään on kerätty vähän listaa: https://github.com/appcypher/awesome-wasm-langs

Eli jos ei Webassemblyksi käänny niin aina voi käänellä Javascriptiksi, tai sitten rakentaa työkalut niin että kääntää jonkun toisen kielen kautta. Esimerkiksi voit kirjoittaa koodin vaikka Vala -kielellä, kääntää sen C:ksi ja C:stä sitten Webassemblyksi.

Kun käyttää käyttöliittymäpuolella selainta ajoympäristönä, saa sitten sen DOM:n ja taittomoottorin käyttöliittymiä varten ja siinä on toistaiseksi rajoite, että siellä toimiva koodi pitää kääntää Javascriptille.

Webassemblyllä toimiessa taas voi tehdä myös niin, että liipaisee Webassembly hiekkalaatikon käyntiin niin sinne voi käännellä objektifilet vaikka LLVM:llä ja käytellä niitä miten tykkää ristiin ja linkittää sitten valmiiksi käännökseksi. Emscriptenissä kun on SDL hinkattu kuntoon niin mikä tahansa SDL:n varassa toimiva GUI kirjasto toimii toki.

Se ajoympäristö tässä on käytännössä alustan valinta kysymys. Selain toimii joka paikassa, CIL tavukoodia ajava frontti on Windowsille, ja sitten on vielä vaikka Unity tai joku muu peleihin tehty alusta.

"Säikeistystä käytetään peleissä minun mielestäni aivan liian vähän. Kaikissa nykykoneissa on useampia ytimiä ja vielä useampia säikeitä, joista kaikki paitsi yksi odottelevat tyhjän panttina hoitamassa kaikkea taustalla pyörivää sillä välin kun yksi ydin pyörittää koko peliä."

Edustapuolella säikeistyksellä tulee helposti rajoja vastaan. Jokainen käyttöliittymä toimii käytännössä yhdessä prosessissa. Säikeiden lisääminen niin, että toimii järkevästi edellyttää käytännössä asynkronisuutta tai hyvin raskaasti laskettavia asioita kun uusien säikeiden luonti on hidasta.

Eli sitä voi siis vaikka jakaa ohjelman niin että on käyttöliittymä, reaaliajassa edustalla toimiva pelimaailma, joku säie hoitelee kommunikointia taustajärjestelmän kanssa ja siirtelee dataa latailemalla pelimaailmaa ja jne. Siinä säikeistämisellä on rajoitteita: https://en.wikipedia.org/wiki/Amdahl's_law

Jos sen edustapuolen koodin saa jaettua vaikka kahdeksaan säikeeseen niin se on jo aika hyvin. Taustalaskentaa ja pitkäkestoisia ajoja voi jakaa sitten mielin määrin workereilla.

Eli, sillä kielellä ei oikeasti ole väliä. Voi käännellä millä huvittaa. Valitulla teknologialla on väliä millä yhdistelet komponentit on väliä tai onko siinä työkalussa ns. ekosysteemiä tehdä haluttuja asioita. Käyttöliittymissä React, Flutter ja vaikka se XAML ovat niitä millä tehdään paljon. Tai jotain SDL/OpenGL virityksiä.

Tai kun on peli niin käyttää sitä Unityä, Unreal engineä, CryEngineä jne. ja antaa sen ratkoa se edustapuoli ja rakentaa sen varaan.

Tässä on yksi aika kova vaihtoehto myös: https://www.qt.io/qt-examples-for-webassembly

Qt:llä tekee kyllä niin natiiviksi kuin selaimeen, vähän kuten Unityllä.

Pääasiallinen ongelma tässä nyt se, että ei tiedetä vaatimusmäärittelyä.

Minusta on omituista miettiä jotain vähäpätöisiä asioita kuten ohjelmointikieltä. Ensiksi pitäisi tietää mitä halutaan saada aikaiseksi, sen mukaan valitaan työkalut. Työkaluissa on sellaisia ekosysteemejä mitkä toimivat keskenään yhteen.

"Ohjelmointikieli", "Käyttöliittymä", "säikeitä", "tiedostoja" ovat kaikki kaukana siitä varsinaisesta ongelmasta mitä halutaan saada aikaiseksi.

Voin kokemuksella sanoa, että käyttöliittymien teossa React komponentit, Typescript -kieli ja Redux tilan hallinta on ihan huippua ja olen tuolla yhdistelmällä tehnyt viimeiset 5v tehnyt lähes kaikki käyttöliittymät ja parempia ei ole vastaan tullut vaikka olen aktiivisesti etsinyt parempia. Tällä hetkellä teen käyttöliittymää Flutterilla, Dart kielellä. Ja se tuntuu tähän mennessä parhaalta natiivien Android iOS sovellusten käyttöliittymille. Miksi ei ole React native niin tarkoitus on hyödyntää mobiililaitteen natiiviominaisuuksia niin Flutter tuntuu tässä paremmalta.

Pelien käyttöliittymissä ei välttämättä ei ole kumpikaan. Siihen on syynsä miksi on noita pelimoottoreita yllin kyllin. Peleissä esimerkiksi tavallisesti haluttaan grafiikkapinta mihin piirrellään GPU:lla mielivaltaisia asioita niin joku taittomoottorilla toimiva UI ei välttämättä ole se mitä halutaan vaan halutaan vaikka jotain sellaista mikä piirtelee vaikka OpenGL:llä sen UI:n.

Tässä esimerkiksi yksi ja Python bindaukset löytyy mutta en ole itse käyttänyt: https://github.com/mitsuba-renderer/nanogui

Käytännön neuvo on se, että pitäisi tietää tarkemmin mitä halutaan, ennen kuin takertuu epäolennaisiin asioihin.

Itsellä on päinvastoin.

Hyvistä peli-ideoista on pulaa, tehdä jaksaisi kyllä sit.

Jotain ideoita on kyllä mutta ne ei ole niin hyviä että jaksaisi alkaa tekemään.