The first thing you need to ask is what are you modding. There is a big difference between changing a game's executable, changing its data files, or working from originals. Here's somewhat of a basic overview.
As far as modern engines go...
Unreal Engine 4 uses its Blueprints visual scripting system in-engine, which can be expanded at a lower level using C++.
Unity uses C# for its scripting. It also allows plugins written in C, C++, Objective C, etc., which can be called using C#.
CryEngine uses Lua and C# for scripting, and C++ for lower-level stuff.
Older games, especially from the '90s, are much more likely to have been built in a proprietary engine, which can vary heavily from game to game, particularly by genre, and typically not as publicly available as the popular engines today. Realistically, the best choice for modding will depend on the particular game, and whether it can be decompiled, but the best things you can learn are C, C++, and x86 assembly (the latter of which basically demands a decent understanding of computer science).
If you want an easy language that can interact with files or memory but don't necessarily need to directly change existing software, you might consider Python. It's powerful, extensible, reasonably fast, and all-around a good first choice for beginner programmers.
And Node and Electron and React? I can't strongly enough recommend avoiding them, unless you really want to make a career out of bloated webapps (or worse, bloated webapps as desktop apps). They don't integrate nicely into OS native look and feel UIs, they have really poor performance, and their growing popularity is a pox on the tech industry.
For now, I was hoping there would be basic classes to teach universal programming language.There is no such thing as "universal programming language". Most older games like this would've been programmed in C or C++, but once assembled, there is no access to that C++ code directly to change it, so everything would need to be done in x86 assembly, which requires quite low level understanding of computers and the game being modded.
To this day, people keep repeating the lie that it's faster than other languages. It just isn't. They all end up as assembly and all modern languages have optimization.Well... (Warning: the following is generally true, but rather oversimplified.)
Yes, I'm aware of intermediate languages. As far as I'm concerned, though compiling to an IL or bytecode that then still needs to be interpreted still qualifies as an interpreted language, for the sake of a performance comparison to languages that compile straight to machine code.[/spoiler]
(And btw, DLPB, they don't end up as assembly. They end up as machine code.
I don't think it's a good language for any user. It baffles me why it's so popular. Not to mention all the different compilers with their different quirks. The language doesn't promote good efficient coding. It's an annoyance.
To this day, people keep repeating the lie that it's faster than other languages. It just isn't. They all end up as assembly and all modern languages have optimization. The differences you will see at that level are not perceptible.
https://aplawrence.com/Unixart/C_is_for_Crap.html
https://www.radford.edu/ibarland/Manifestoes/whyC++isBad-printable.shtml
The only reason Delphi died (although it hasn't) is because of poor decision making by Borland in their hay-day, coupled with the fact they were competing with the might of Microsoft (who also ship the libraries and even freeware compilers) meaning many gravitated towards C over Delphi. Also, I hear, MS bought out loads of Borland's team.
As a language, Pascal is superior imho. It was, after all, made to create good programming practices:
https://en.wikipedia.org/wiki/Pascal_(programming_language) (https://en.wikipedia.org/wiki/Pascal_(programming_language))
And came after C.
I think C is a terrible language and this becomes more apparent when you see mediocre code that will then not compile properly on another compiler.
If you want to create a portable, self sustained program that will work almost universally when you ship the source to another person, then Delphi - or any other high level language - is the way to go. I don't need to mess about with memory management, crazy syntax, and other annoyances.
Of course, no-one is going to agree on this - but I'll dance the day that C dies. ;D ;D ;D
The trouble we've been having with Aali's source would never ever have happened with Delphi - the language simply doesn't allow for it.
There's a reason why [C] remains the only choice for real-time (deterministic) programming tasks, or embedded systems programming.
However C does not force you to rely on higher level "safety" features present in most other compiled language which means it does allow you to write much faster code than in most other languages.
static int podhd_try_init(struct usb_interface *interface,
struct usb_line6_podhd *podhd)
{
int err;
struct usb_line6 *line6 = &podhd->line6;
if ((interface == NULL) || (podhd == NULL))
return -ENODEV;
....
}
Not true. Lots of scientific simulation and maths code is still written in Fortran. And safety-critical embedded systems are often written in Ada - I have a friend who was writing new Ada code for satellite systems as recently as three years ago.
Yeah, maybe, but it is also almost impossible for 99% of human beings to write large applications in C that are totally secure, unless you've got some kind of cybernetic implants in your brain. For instance - quick q, what's wrong with this snippet?
That second null check won't do what you think it will, at least at first glance.
Of course, fiendishness like this is exactly why I think C is rewarding to learn. But actually using it is a different story!
This is a very common C gotcha (attempting to dereference podhd via &(podhd->line6) is undefined behavior if podhd is NULL. The check for NULL belongs before the attempt at dereferencing podhd and really any C programmer will know that. There's nothing wrong with the "second check" except that it's misplaced, and most good compiler's (gcc, for example) will optimize it away as the attempt to dereference podhd in the previous line will let the compiler know (mistakenly) that podhd cannot be NULL.
Simple solution, check for NULL before you dereference pointers. These sorts of things are more of a hassle when you're learning than later on when you've developed good habits w.r.t NULL handling (responsible for about 90% of C's "gotchas"). Being able to propogate constraints like this and letting the compiler (or instructing it with __builtin_unreachable) optimize away unnecessary works/checks is another factor that contributes to the performance advantage well written C code enjoys over most other compiled languages.
Do the editor programs for FF7 use "Java"?I have not encountered any that do, but there's no reason it couldn't be done. Several of the programs I use at the office are Java-based, but they're not the kinds of things you're likely to see on an end-user's desktop.
I have not encountered any that do, but there's no reason it couldn't be done. Several of the programs I use at the office are Java-based, but they're not the kinds of things you're likely to see on an end-user's desktop.
Do you know what programming language they use?Probably C++ or C#, maybe .NET. Just ask the authors ;)
Do the editor programs for FF7 use "Java"?IDK that any use Java I know these are used: C , C++ , C# , VB.Net, Delphi , Python by various ff7 tools.