Oppure

Loading
15/02/16 11:31
Thejuster
Ragazzi volevo mostravi un'altro passo importante effettuato al mio progetto MMORpgmaker.

Si tratta di una sorta di FlowChart ma implementato in modo tale da rendere la programmazione a nodi una realtà.

Se qualcuno non lo sà, MMORpgmaker utilizza come motore di scripting il LUA.
Essendo un linguaggio di scripting molto pratico, esteso e funzionale,
Esiste un alta percentuale di utenza che vorrebbe realizzare un gioco ma senza programmare.

Allora ho seguito questo concetto realizzando il FlowCode.

Vi mostro una screen fatta da cellulare velocemente

s14.postimg.org/b2gz59e7l/…

Il contenitore principale si basa su un rendering in GDI
L'ambiente è navigabile ed'è possibile zoomare gli elementi contuni, spostarli e linkare eventuali parametri ad altri moduli.

Ogni modulo ha un DataType particolare.
Così come le linee di collegamento identificano il tipo di dato che il modulo può inviare al fratello.

Nell'esempio:
Il link giallo equivale ad una stringa
Il link blu è un booleano True
Il link rosso è un booleano false
Il link viola è un gestore di eventi.

Potete notare anche il Condition Frok con varie verifiche.

A = B -> Link True
A != B -> Link False

Ogni modulo ha un suo codice sorgente che genererà il codice lua.

Nell'esempio mostrato, Il contenitore principale genera una funzione di avvio

function Event_001() 

end


Successivamente, recupera tutti i moduli e ricrea altre funzioni.
Esempio il blocco Frok non è un operatore o un assegnatore di valori o variabili ma è una funzione che verifica alcuni dati
prima di attivare i sui figli.

In questo caso l'editor genera una funzione al controllo e ne crea il codice del tipo

function Event_001()

IFStr1()

end

function IFStr1()
local varA = Value_A
local varB = Value_B

if varA == varB then
 call(true())
else
 call(false())
end

end



Vi piace l'idea?
per ora è tutto funzionale tranne qualche bug per la generazione del codice
ma spero di risolvere i vari conflitti.
Non è una passeggiata ma sarebbe un ottima cosa per gli utenti che non conoscono la programmazione
in modo tale da poter creare script senza mettere mano al codice lua.
mire.forumfree.it/ - Mire Engine
C# UI Designer
15/02/16 14:53
GN
Complimenti, il tuo sì che è un vero progetto che continua ad evolversi :k:
Se non ti dispiace potresti togliermi una curiosità? Volevo chiederti come viene gestito il caricamento di un flowchart nell'editor. Mi spiego meglio: viene salvato tutto in Lua e per ricaricare lo script nell'editor visuale c'è un parser che riconosce nel codice Lua le strutture dei blocchi (chiedo perchè questa soluzione mi sembra molto difficile da implementare), oppure salvi serializzando (magari in XML, non so) un'oggetto di una classe apposita in cui sono definite le strutture dati per i vari blocchi, in modo da poterlo ricaricare facilmente, e poi generi lo script Lua come output "compilato" da cui non si può più risalire al Flow Chart che lo ha generato? Grazie e complimenti ancora
aaa
15/02/16 21:18
Thejuster
Ciao GN grazie a te per i complimenti fà sempre piacere riceverne :)

dunque per la prima domanda, si. L'evento viene serializzato in un file xml dove successivamente
posso risalire alla configurazione che l'utente ha creato.

Il LUA parse esiste,
Se hai dato un occhiata alla screen, avrai notato che su ogni modulo è presente un segnale di colore verde.
Ogni modulo prima di essere correttamente processato, viene testato dall'interprete lua.
Se non presenta problemi, il modulo si accende di colore verde.
Altrimenti si accende con il colore rosso.

Normalmente il componente grafico principale, ovvero la picturebox su cui viene gestita la scena
ha un comportamento un pò particolare.

Esso determina tutti i tipi di moduli che sono presenti.
Alcuni hanno bisogno di essere chiamati tramite una funzione apposita altri servono solo per inviare parametri.

Un esempio è il blocco "Invia Stringa"

Ti spiego meglio lasciandoti queste due screen

Screen 1
s27.postimg.org/asfshln03/…

Da come puoi vedere da questa screen, C'è il primo modulo chiamato Avvio
Questo modulo può solo attivare un controllo che successivamente farà altro.

Ora con tutti i componenti scollegati il codice sorgente è questo

s11.postimg.org/rvo4havnn/…

da come puoi notare, l'itero progetto dello script è chiamato Event_001()
(nota in basso il messaggio di errore)


Ora selezionando il blocco Invia Stringa gli assegno un valore da inviare ad un qualsiasi modulo.
In questo caso gli faccio inviare al modulo Mostra Dialogo -> Ciao GN

s18.postimg.org/oysywt4ih/…

Successivamente collego Invia stringa al modulo Mostra dialogo al blocco (Ricevi Valore)
quindi il dialogo ora riceverà "Ciao GN"
e per finire dico al modulo principale "Avvio" di attivare (chiamare) il modulo Mostra dialogo.

Alla fine il risultato del sorgente sarà questo

s12.postimg.org/6tglur8r1/…

E' molto pratico come sistema di scripting.
Permette all'utente di divertirsi con i vari moduli senza provocare errori ed
evitare di bruciare uno script con chiamate invalide.

Il Sistema fà tutto da solo.
Ne calcola la validità del codice e ne genera un output in LUA

Nota:
Appare Event_001 perché si presume che sia un NPC che al tocco del personaggio giocabile
richiami questo determinato script.



mire.forumfree.it/ - Mire Engine
C# UI Designer
15/02/16 22:30
Template
Bellissimo progetto :k:

Non posso dare un giudizio tecnico, perchè si tratta di un progetto evidentemente al di là delle mie competenze... ma, mettendomi "dalla parte dell'utente", non posso che apprezzare la tua scelta di avvalerti di un sistema di nodi simile a quello di certi motori di rendering CGI (penso, per esempio, a Cycles o al famosissimo Mental Ray), che di fatto aliena completamente l'utente dalle incombenze legate allo scripting vero e proprio ;)


Se posso darti un consiglio per gli sviluppi successivi, io includerei... un modulo di scripting "esplicito" :D
Ti consiglio questo perchè, se da un lato molti utenti saranno assolutamente soddisfatti del sistema dei nodi (quanti utenti precisamente, dipenderà dalla varietà e dalla versatilità dei nodi che il tuo programma potrà proporgli), dall'altro ci saranno utenti - più capaci o solamente più curiosi - che sentiranno senz'altro il bisogno di "metterci del loro"... e sarebbe un peccato limitare la loro creatività ;)
Ultima modifica effettuata da Template 15/02/16 22:32
aaa
15/02/16 23:27
TheDarkJuster
I miei più sentiti complimenti!
Io non sono un amante degli rpg, ne dei game makers, ma stimo comunque moltissimo progetti degni di nota, e ovviamente i loro creatori, specialmente se armeggiano con il 3D!
aaa
17/02/16 7:57
Thejuster
Grazie a tutti per i complimenti.
L'unico problema che ora ho, e quello di pensare a ristrutturare completamente l'engine.
Il progetto era partito circa 7 o 8 anni fà.

da allora ci siamo evoluti di un bel pò.
Passando dal desktop al mobile.

Sto pensando un modo per generare giochi in html5 o webgl.
visto che ormai i giochi per desktop sono praticamente rari.

E chi ci gioca è solo un fan dei videogames.
Quindi sto puntando a questo.

Sono riuscito a costruire un generatore di APK con alcuni strumenti e funzioni create in C#.
Con vari esperimenti, sono riuscito ad ottenere un apk per sistemi android ed anche per iOS.
Ovviamente per iOS serve un mac. Ma il problema sarà il mono.
Al momento non sò se XNA gira su mono e non posso testarlo non avendo un mac.

Ma principalmente sono contro la Apple e tutto quello che è Closed Source.
Io ho sempre optato per l'open ed MMORpgmaker è openSource.
Chiunque può scaricarlo, vederne i sorgenti ed imparare qualcosa.

Quindi punterò per l'APK.

Il sistema che ho scelto è l'NDK di android ed altri plugin vari.

Ora mi tocca riscrivere un engine in html5 o webgl.

Saranno due progetti completamente diversi.
Per il desktop, l'output sarà un exe pre-compilato in XNA.
L'utente dovrà solo giocarci ed il programmatore volendo, può implementare codice in lua
o creare eventi (pre - programmati) con il FlowCode.

Mentre per la versione mobile, opterò come valido strumento il javascript.

Condivido questo progetto con pierotofy e con voi da tantissimo tempo ormai.
Per questo ogni vostro consiglio è sempre un punto di riferimento per me.

Grazie ancora a tutti vi terrò aggiornati in caso di nuovità

Questo è un vecchio video che mostra molte funzionalità
e con il vecchio editor di eventi

youtube.com/…

L'engine crea anche delle mappe normali.
per applicare lo shader Deferred 2D Lighting tramite le Normal Map.
Le luci generano le Shadow Map.
Che poi viene applicato a come shader.

E molte altre cose ancora, non spiego altrimenti il topic sarebbe lungo 3 metri eheh
Ultima modifica effettuata da Thejuster 17/02/16 8:09
mire.forumfree.it/ - Mire Engine
C# UI Designer
17/02/16 9:19
GN
Al momento non sò se XNA gira su mono


Forse lo conoscerai già, comunque siccome non ne hai parlato, te lo indico - potrebbe interessarti il progetto MonoGame: monogame.net/. Se ho capito bene e una sorta di remake open source di XNA ma cross-platform (come del resto lo è Mono per .NET), e dovrebbe (ancora, se ho capito bene) essere compatibile con XNA nel senso che i namespace, le classi e i relativi metodi, proprietà, eccetera hanno gli stessi nomi, per cui dovrebbe essere (almento in teoria) portare del codice scritto per XNA a MonoGame. Di documentazione purtroppo mi sembra non ce ne sia molto (in ogni caso, se ti interessa, qui sono elencati un po' di tutorial monogame.net/documentation/), però se guardi un po' sul sito e su GitHub sembra sia molto orientato a targettare piattaforme mobili come Android e iOS.
aaa
17/02/16 13:06
TheDarkJuster
NDK non c'entra nulla con html, javascript e webgl.

NDK sta per Native Development Kit e serve per integrare nelle applicazione android parti scritte in C/C++.

Scrivere due volte un engine? Accidenti, è un lavoraccio e una pessima idea! Molto probabilemente avrai problemi seri di compatibilità fra i due: bug presenti su uno e non sull'altro, features implementate su uno e non sull'altro, ecc.....

No, decisamente NON è una buona soluzione.
Vuoi un cross platform elegante? webgl.
Vuoi un vero cross platform? opengl es (è disponibile anche su PC non solo su mobile: nvidia, AMD, Intel.... Tutte le GPU non antiche di questi produttori supportano OpenGL ES, e ci sono librerie cross platform che supportano anche android e iOS per le questioni legate al S.O. vedi glfw per la gestione di finestre/schermi).

In entrambi i casi ci sarebbe il problema di riscrivere tutto dagli algoritmi, quindi non so se la strada sia percorribile.......

usare monogame significa sostanzialmente legarsi a mono e xamarin (commerciale) per il mobile..... Anche qui non so se la strada sia percorribile, nel senso di costi.
aaa