Good vs. Evil
- Thread starter Randomguy404
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
56 what about an editor that is also basically your browser's dev tools? http://brackets.io/
it may not work as well if you for example need to use php to generate html. But assuming it works with react and other JS frameworks correctly it is defiantly faster to work with than with "normal" editors.
Only reason I am not using it yet is because last time it had some bugs that prevented it from actually being useful and since then I never bothered to try it again. I probably should one time though, as that was a while ago.
59 My teacher has many.....insights to many things related to Africa. I'll leave it at that. But he's cool tho.
64 the database table layout of my RP_tracker project. Well, the main database of that project (yes, there are 2 databases.No, I haven't gone mad.)
It is expected to grow though, as I am also planning to add default stats/actions as well. (I am in the process of redoing the stat system, so it becomes fully modular)
Everything is slowly coming together though
. Only a "few" more things are needed and then it should be able to handle EVERY battle system that exists or will exists. (hooray for making it basically a glorified turn based game engine).I'm still not sure what language to use for scripting actions though (thus, attacks/abilities/other stuff that comes up). I'm guessing Lua-script is a good choice as it is easy but I don't expect people to have much experience with it and perhaps a fullblown programming language is a bit overkill.....
There are other "languages" as well like the stuff http://anydice.com/ uses or maybe something like https://rolz.org/ . Which are probably easier to work with for GM's but as they are also more limited I fear that it may end up lacking features thus making some combat systems harder to re-create. Which would mean that RP_Tracker fails at its job.....
I'm also not a fan of working with 2 script languages, nor a fan of creating a drag/drop based one.... (actually, that last one suddenly popped into my head and I think it requires exploring...)
Would something like that work?
Program runs from left to right.
Each square is 1 command.
Lines between commands are called data-lines and contain the output of one command which you can drag to input for other commands.
66 and that is the reason I don't like using lua in this case.65 This is all very interesting stuff, if only I could understand it
Basically what I need is a programming language that I as developer can use but also people that have never programmed before. Or in that case at least looks easy and inviting enough for people that never programmed before to try and learn it.
And yes, I am aware that Lua was designed to be easy to learn and it does a pretty good job at it. But, if you never programmed before and want to start to GM a nice and fantastic RP. Do you really want to get into learning Lua? Nope.
Of course, that is true for every language which is why there will be default battle systems, but unless I allow people to easily create new systems by themselves its impossible for me to add all systems that people might use.
67. I don't know the full limitations and design spec of the project, but I'd suggest having two methods, one being an easy "language" that you either create or adapt that parses the instructions into prewritten systems, as well as a full on programming interface like lua to allow more complicated systems when wanted, but not required for many of the more common and simple actions that a GM may wish to do.
68 I guess 2 systems may work. Though, I would like it to be able to run both systems on the server and the client, for security and for performance.
client -> when its the GM that does stuff/the player is playing around with the system and isn't actually saving any results of the rolls
server->when the player lets his character do actions that have been scripted. (like doing a basic attack).
But.... that means that I either need to rely on WASM to be able to run it both on the server and the client (which means I need to write the parser in C/C++/Rust. At best I need to figure out how to have JS talk to Lua through wasm and add lua as a dependencies for the server)
or I need to write the parser 2 times (one in PHP for the server and the other in JS for the browser)
I guess I could also add nodejs as a dependency and write the parser in a way that both php can make use it through nodejs and the browser can make use of it. But....this just seems like a bad option due to the need for more dependencies.
However, I think the graphical language would work nicely. I already have an idea for how the internal structure of the "compiled" code could look like (hooray for having made an overcomplicated brainfuck interpreter before).
If I then add lua as a dependency I may be able to also run this on the client relatively easily and later on "expose" lua if the graphical language isn't fast enough/powerful enough.
client -> when its the GM that does stuff/the player is playing around with the system and isn't actually saving any results of the rolls
server->when the player lets his character do actions that have been scripted. (like doing a basic attack).
But.... that means that I either need to rely on WASM to be able to run it both on the server and the client (which means I need to write the parser in C/C++/Rust. At best I need to figure out how to have JS talk to Lua through wasm and add lua as a dependencies for the server)
or I need to write the parser 2 times (one in PHP for the server and the other in JS for the browser)
I guess I could also add nodejs as a dependency and write the parser in a way that both php can make use it through nodejs and the browser can make use of it. But....this just seems like a bad option due to the need for more dependencies.
However, I think the graphical language would work nicely. I already have an idea for how the internal structure of the "compiled" code could look like (hooray for having made an overcomplicated brainfuck interpreter before).
If I then add lua as a dependency I may be able to also run this on the client relatively easily and later on "expose" lua if the graphical language isn't fast enough/powerful enough.