I am currently writing a very simple 2.5D game engine in java and game. This is basically just a fun project I am working on so the amount of time it will take to implement features is no problem, as I can always put it aside and work on it whenever. With that said, I was planning on implementing a custom sort of scripting system. Basically the engine would be a shell of a 2.5D game, which can be modified and extended through simple scripts. So far I have the following ideas of how to go about this but I am unsure of what is practical or not.
Write a very simplistic scripting language and a simplistic parser that checks a folder for the scripts and runs them.
Make a java library/API that allows you to modify parts of the game on client and server via just plain old java
Use an already created language that is very simple such as lua for extendable parts of the game
I really thought about option 1 as being what I wanted to do, however I have never really done such a thing, I was wondering if someone could recommend what I should do here. If I do go with writing a simplistic language, I am just looking for some material or documentation on such topics, would I just look at how people wrote basic compilers/interpreters?
The short answer would be 2, go with the API. It's the easiest way to add or change features to your game engine.
Creating your own scripting language and parser is tempting for every developer. It's a great learning experience, but it's also a downside. When you start to write the scripts and the result isn't what you expected, you don't know if the bug is in your script or in the parser. You will need some debugging info from the parser maybe some stacktrace, even a very simple scripting language may start to take over your project. When you start to write your scripts you will probably feel limited by the features missing, the ones you are used to from writing java code and maybe start to expand the scripting language.
Some of the downsides with creating your own language is also true for allready existing languages. If you really need a very free way to extend your game engine you can choose that road, but I would not recommend it. You would still risk shifting your focus from your game engine to the scripting implementation.
One way to think about it is also from the writer of the mods point of view. Would they want to write in a new script language, in a existing script language or in java? The answer will most likely be java and probably not a new language.
Related
Recently I've been exploring the world of smalltalk dialects and am very impressed (from here on in understand that when I write 'smalltalk' I'm referencing any of the modern smalltalk dialects - squeak/pharo/etc). I like the small footprint of the VM and the language itself.
As grad student and often need to write tools that support my research. Typically I use Java because I can easily deploy a tool to my colleagues without worrying too much about what their computer setup is or how tech savvy they are. It's pretty easy to whip up a GUI interface and all the end user has to do is double click on an executable JAR and they are gtg. The problem is that Java has all sorts of security issues and doesn't always run in the same way on every platform. Smalltalk, therefore, is starting to look pretty attractive.
I know that it's possible to create a smalltalk program that fires up with one double click of an icon. What I'm wondering about is whether or not I can create a sandboxed smalltalk world such that the only thing the user sees and is able to interact with is my application. I don't want them to see any aspect of the smalltalk world. This way, users can't accidentally muck things up or get confused because they have access to a plethora of options that aren't directly relevant to use of the program. Is this possible, and if so, how do I do it?
Apologies - I should've done a better job of RTFM prior to posting this question. It is apparently possible to do this via Lockdown:
http://map.squeak.org/sm/packagebyname/lockdown
Also helpful:
http://wiki.squeak.org/squeak/3563
In Pharo, you can send openWorldWithSpec to your UI so that it is full screen. An example of this is the Pharo Launcher: https://ci.inria.fr/pharo-contribution/job/PharoLauncher. When you launch this image, you can't access the rest of Pharo (at least, not easily).
I know this question is vague, but I'll try to make myself clear.
I am starting a Java project involving a Swing GUI. I want to follow the MVC pattern, and could use some help from a framework to organize the project's architecture. I was thinking of using Griffon, though I suppose others might do the trick.
So, is it a good idea to use a framework in terms of:
Programming efficiency: Of course, it will be improved... most of the time. More precisely, what if the project is a small one? Or a large one? What if I'm already very familiar with Java and Swing? What if I'm not? What if the project has to be maintained by someone who knows nothing about the framework I used?
Learning value: Will I merely "learn how to use the framework", instead of learning more about Java and Swing in a different environment?
Professional value: Would companies prefer a developer who knows "more" frameworks (even if they might not be the ones they intend to use) to a developer who knows the "traditional" approach better?
I found little information elsewhere, which is surprising, considering how big this question is. It might seem trivial, but I'm actually wondering about it.
Of course I'm biased when it comes to Griffon however I'll try to be as objective as possible:
Griffon is an MVC framework/platform for the JVM. It's true that the programming language of choice is Groovy, however many others can be used too, see this example from the Guide http://griffon.codehaus.org/guide/latest/guide/tips.html#nonGroovyArtifacts where it shows how a pure Java application can be written. Other options are possible if you install a specific plugin http://artifacts.griffon-framework.org/tags/plugin/polyglot
Griffon's philosophy is one of keeping your choices open. It's true that sometimes the framework will steer you to follow particular path however it has provides plenty of leg room, that is, you make it dance to your own tune. For example, writing Views is usually done following the Groovy SwingBuilder DSL (a subtle abstraction layer on to of Swing), but you can drop down to the Java layer and write in plain Java/Swing if you want; or pick NetBeans Matisse, Abeille Froms Designer, or any other Visual tool that supports Swing.
Plugins are key to Griffon's success. As you can see at http://artifacts.griffon-framework.org/category/all/plugins there are currently 211 plugins, and more are coming.
But in the end there's only one opinion that matters: yours. I'd recommend you to spend a few hours with Griffon, if you don't see the value added by it by then ... I'm afraid we'll have to work harder to make it better.
Cheers
As we know, Griffon is based on Groovy and Groovy has a beautiful Java style, probably you will avoid lots of code line, but always we need to consider some aspects like knowledge and schedule.
Knowledge: Your productivity is related with what you know and how to use what you know, if you feel confortble in Java, use the Java, because, seems that your goal is to use MVC and as Juned said, we can do this with Swing, too.
Schedule : If you have time to study and really want to learn a new framework now, this is the time, but you must to follow your schedule, don't forget that you need to finish this project in the time.
So, consider to use what you know, and study new things to another projects.
Avoid diving in the dark without your flashlight.
I was evaluating Griffon as a framework. I got the impression that this project is slowly dieing. IMHO Groovy is not a mainstream anymore (I wonder if it ever was a mainstream?). Now everybody fancies Scala.
Now back to your question:
Most frameworks expect that you follow the standard development path. Any changes / customizations will most probably introduce difficult to maintain solutions (they will call it architecture afterwards). Choose a framework that allows you to do 95% of the things you plan to do. And yeah, choose a mainstream framework.
Griffon is based on Groovy, so you have to master Groovy first. Ok, Groovy is a JVM language and if you're OK with Java it will greatly help, but still all those DSLs will require some time to settle in your head.
If you know any mainstream framework - this is a valuable asset. The sad fact is that frameworks tend to fade / die and you have to constantly look for new buzz things. You never stop learning (although key principles cannot be changed and remain constant from framework to framework)
Implementing the MVC pattern for an environment should be easy if you understand it. First a note on it: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
Now coming to your environment which is Swing based, you can implement your code by dividing it Model-View-Controller. Views are your Swing classes where are you are actually creating the user interface. In such classes, you should simply capture the user actions through different listeners but should not implement any business logic.Controller should be doing the business logic and may use Model whenever desired.
For example, you are creating a Swing GUI for login. Create a LoginView class where you will create the frame, textfields, buttons etc. And also attach the listeners to different controls as desired. Now whenever a user submits the login, you should call controller to do the credentials validation. Credentials may be stored in a DB, which should be loaded and stored in Model(DAOs). Controller should get the user input from View, correct credentials from Model, and the compare logic should be implemented in Controller.
Hope it helps!
I'm planning to create a simple Visual Novel game engine out of Java. I've developed for Java before but I have experience with other languages. What I would like to do, is to create my own scripting language that people can use with the engine to make the complete game out of a script, since Visual Novels are simple enough to do it, I think.
What I don't know is, is Java suitable for making such a scripting language? The way I imagine it is, the engine reads a script file in the game folder, and takes in the input and executes each command linking up to a certain function or something like that. I'm not sure how difficult theoretically that would be to pull off.
As you can probably tell I'm a newbie when it comes to this.
Thanks.
It sounds like you need a domain-specific-language (DSL). Here's an article on DSLs within Java
DSLs are small, expressive programming languages custom designed for
specific tasks. In this four-part series, Venkat Subramaniam
introduces the concept of DSLs and eventually shows you how to build
them using Java
and there's a related question on SO.
You can use Scala to write DSLs and run them on the JVM. However I would warn you that without Scala knowledge it's a (IMO) non-trivial task to do this.
Alternatively you can use a Java implementation of a scripting language together with the Java Scripting API. This will allow you to use an existing language and have it compiled into bytecode. The advantag eis that you're using an existing language. The disadvantage is that it's not specific to your particular needs.
Don't do it. Writing a new language is surprisingly complex. Designing grammar, parsing, error reporting, performance.
It's already there: Creating meta language with Java
Consider groovy, lua or jruby first. People will love you for using familiar syntax.
While it's technically possible to do this, I don't know if Java would be your best bet. While I don't know the scope or purpose of your project, I'd recommend PyGame as a game/scripting language. (You said that you have experience with other languages, so I assume that switching to Python is ok)
I think the above answers give nice directions.
I would like to offer some more ideas:
A. Provide a java "GAME API", which can be exposed via REST/SOAP web services and can have client classes generated from (for example, take a WSDL, and generate client classes from it).
B. Provide the API as a jar file, and have you game implement a File class loader that will load external jars, and use the classes developers will develop using the API.
Here is an example of how to implement such a class loader.
C. Use the ScriptEngine provided by java, to invoke scripts.
See here an example of how to invoke a JavaScript script from within java.
This question is old and i am a bit late for the party (though this question is not answered yet), but it is possible. From what i understand, this sounds like a job for Just Another Framework. Full disclosure: I am the developer of the Framework i am describing. I had a similar problem and wrote this framework to reuse this system, which worked for this kind of issue.
TL;DR
Do not use JAF, if you want your own, fully functional, perfect language.
Use JAF, if you just want to create a simple scripting part, that decouples parts of your code or if you want to evaluate "user input" scripts at Runtime (like in the topic of this question).
What I don't know is, is Java suitable for making such a scripting language?
You can do it with nearly every programming language. You should consider to use Javascript or Lua or [...] and put those into a file instead of creating a custom scripting language. Java has a place for those languages. You should also consider to maybe read .java or .class files from a folder and take those into your "Game-Engine". If you however want to provide your own language and no one can change your mind about it (that was my issue), JAF can help you with that.
JAF is a framework, which allows you to define custom scripting languages within Java, that may be evaluated and executed at Runtime. You give the Parser some Functions, Rules as well as the raw script and the result is a fixed set of instructions (in the form of consumers), that can be executed as many times as you like.
This is by no means another language build on top of java! It is meant to be a foundation for your language. It is only meant for creating small parts though. An example would be some sort of logic that should be interchangeable without stopping the application. This logic should be executed via small scripts and provided via a Database or (like in your case) from files located in a folder.
You can use a Parser, to parse "raw-scripts" that are created by the users. This parser takes Functions and Rules in the form of a Strategy-/Command-Pattern, which basically define your language. After parsing, a "Script"-Object is returned, that can be executed as many times as you want. You can also set values of the Script and therefor connect this Script to your real and running java-code.
The real thing i loved about this however is, that you can provide custom script elements through Rules and Functions, which basically directly connect to java. Just an example would be the printline function. This calls System.out.println();. As i said, just an example, but you can imagine that you can call any existing code from your Functions and Rules.
A (very) simple example of how to use this would look like this:
String rawScript = ... //your users script here
Parser parser = Parser.create(); // used to parse the script
parser.add(IOModule.getPackage()); // add packages of Functions and Rules
Script script;
try {
script = parser.parse(rawScript); // Create the Script
} catch (ParsingFailedException e) {
// Handle an error while parsing the script
// Do not continue, there is no script!
}
script.setValue("yourKey", /* Whatever should be available in your script */); // Inject outside variables for your Rules/Functions
try {
script.run(); // Execute the script
} catch (ExecutionFailedException e) {
// Handle an error at the scripts execution
}
I do not want to write a book about how to use this framework. Take a look at the wiki, it is better explained there.
The advantage of this is, that you can simply define your own language, by providing simple commands that parse specific pieces of the raw script. They are just "applied"; All the magic is hidden within the framework. It's explained a bit within the frameworks-wiki, but i am bad at explaining. So you can create your own little scripting language by providing the building-blocks of your language without requiring deeper knowledge of theoretical computer science.
It has some issues though. It is currently not compatibly with the JSR 223. Also, it is (of course) slower than playn java.
I'm a big fan of functional programming languages (namely Standard ML and its dialects), mainly because of their expressiveness which allows for very consise, clean code. I can solve many problems dramatically faster with ML than with say Java.
However, Java is really great when it comes to programming GUIs (->SWT). I would definitely not wanna do that in a functional language.
This brings us to my actual question: Is there a good way to write a program in ML and then wrap it with a GUI written in Java?
What I have come up with so far is the following:
Compile the ML programm (e.g. with MLton or Poly ML) and execute the binary as
an external program from Java
(http://www.rgagnon.com/javadetails/java-0014.html).
Problem: The only way the Frontend/Backend can communicate is via Strings. This might require tons of (difficult) encoding/decoding.
Use JNI/JNA. From what I read, this will allow you to transfer Integers, Arrays etc. I think the external programms have to be written in C/C++ for this to work. With MLton's Foreign Function Interface I can write an Interface to my functional program in C and statically link the whole thing.
Problem: Apparantly, this only works with dynamic libraries, that is dlls in Windows. However, MLton will only let me compile the ML/C Programm to an executable. When trying to create a dll, I get a whole bunch of errors.
Does anyone have experience with this? Is there a better way to do this?
Thanks in advance! -Steffen
EDIT: I know about Scala which tries to bring concepts from functional programming to Java. I have tried it but I dont think it can compete with an actual functional programming language (in terms of expressivness)
That's not quite the exact answer but there is a functional language which is very ml-orientated for the JVM: Yeti
So if you like coding in ML than that's probably currently the closes you can get on the JVM and it integrates of course very well with all the Java APIs.
Is there a good way to write a program in ML and then wrap it with a GUI written in Java?
I don't know if this is a good way for small applications, but it is definitely a way, one that works for big IDE style stuff: Isabelle/ML vs. Isabelle/Scala/JVM. This is an application of interactive theorem proving, but plain SML programming is a trivial instance of that, in a sense.
So you can write basic Isabelle/ML code that emits some messages in the manner of the old-fashioned REPL, but the output can be interpreted by GUI components on the JVM side. Isabelle/jEdit does that routinely for pretty-printing of colored text, with a tiny little bit of rich text (sub/superscripts and bold).
Concerning explicit recoding of functional values over pipes/sockets as strings: that turns out quite simple in Isabelle/ML/Scala, due to some imitation of the way SML would represent typed values in untyped memory, but using untyped XML trees here instead of bits. The XML transfer syntax is specific to keep things simple: YXML instead of official quasi-human-readable XML. All of that fits into approx. 8000 bytes of SML source -- I am tempted to post the sources here, but better search the web for "Isabelle YXML" or "YXML PIDE".
Since Scala/JVM alone has been mentioned as standalone alternative: it definitely works, Scala is also very powerful and flexibile in imitating many programming styles (higher-order functional-object oriented), but for sophisticated symbolic applications like theorem proving, it just won't reach the purity and stability of SML. (Note that the underlying SML platform here is Poly/ML.)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I currently have a C++ backend that I need to connect with a GUI, and since I've never built a GUI before, I was confused on where to start.
I'm comfortable writing code in C++ and Java, so I'd prefer my GUI to be in one of those languages. Also, the GUI has to be reasonably OS independent over Windows and Linux (and hopefully, hence Macs).
Now I understand that if I use Java to do it, I'll need some wrappers to do it - but I've also heard (strictly second hand) that writing a GUI in C++ is a pain.
I don't want to rewrite too much of my backend code in Java (who does??) and I was hoping for input on:
Does either language offer serious advantages/disadvantages compared to the other?
How serious is the wrapping issue, and how much rewriting would come in if I used Java.
Are there any specific resources I should look at that people think would be relevant?
Thanks and Cheers All :)
Have a look at Qt.
In my experience communicating between two different language runtimes is always challenging. If you have a non-trivial application to build the following often pose challenges:-
Error Handling.
Memory Management.
Multithreading and Synchronization
Semantics.
Apart from increasing one level of indirection due to wrappers, it requires a lot of thinking like circumstances where you need to pass data structures across GUI and backend etc.
For example:- Consider passing a Java String from GUI to backend C++.
Essentially, we have to extract the characters from a Java String object and make them available to the C++ developer without leaking the memory which holds them. This is an example of a basic problem (there are other aspects too like the encoding in which the characters are to be returned).
You say you already know C++ and Java, and that you never did a GUI before. That means:
no matter if you go for a Java GUI or a C++ GUI, you will need to learn how to handle the GUI framework
if you chose Java, you also need to learn how to interface between the two languages
So staying in C++ saves you one thing to learn. Well, it's always a good idea to learn something, but might be a bad idea to learn two new concepts at the same time. Anyway, the learning might be the smaller burden, I guess there is a lot of actual work involed, even when you use tools like SWIG.
You might want to know if writing a GUI in Java or doing it in C++ is easier. It depends on the chosen Framework. For Java, you have AWT and Swing which are part of the default Java distribution, and then there is SWT which is used by Eclipse, for example. For C++, there are many toolkits, with Qt, GTK and wxWidgets being the most popular ones, and all three support every major platform. Most of those "C++" GUI toolkits also have a Java binding or even a Java port, so you could use them with Java as well.
So far I've used Swing, Qt and a few others which don't help in your situation (The UI thingy that came with Borland C++ Builder and WinForms on .NET). Basically, the concepts are the same for all those frameworks, and I found none of them being harder or easier than the other. The only exception maybe Java, because I never got those LayoutManagers to work, even though the other toolkits have equivalents to LayoutManagers that are easy to master. But maybe thats just me.
People also will tell you that Java GUIs are always ugly and don't fit the host system. Well, most Java GUIs really are, but IMHO thats not because of Java, but because of bad programming. It takes two lines of code to let a Swing app adapt to the look and feel of the OS, and most programmers simply don't put enough effort into their Java GUIs to copy and paste those two lines... you can imagine how much they care about the rest of their GUI design.
For your current situation, I would recommend a C++ GUI, but if you know how your future plans look like, and if you know you will doing Java GUIs for the rest of your life, then it's probably ok to start that now and take the extra effort of .
And if you chose C++ for the GUI, people will tell you all kind of things to pull you in any direction. All of the three big portable frameworks have their pros and their cons, but I don't believe there is any single best or worst one among them. I'd recommend Qt simply because I already used it - but if I'd happten to have used GTK or wxWidgets instead, I'd probably suggest that.
Depending on your needs, a simple web interface might be the simplest when you have no existing frontend code. Embed a tiny web server in your application and open a browser on "http://localhost:12345" (or what port you end up using).
I can't say much about coupling Java and C++, but I suggest you have a look at Qt.
It's a C++ library for a lot of things, like file and network access, but it's most famous for GUI development. It also has a nice IDE were you can build your GUI with drag-and-drop.
I would also say that Qt is as OS-agnostic as it gets for GUI libraries.
Writing a GUI in C++ is no more of a pain than doing it in Java.
There are numerous cross-platform GUI libraries. GTK, gtk--, FoX, WX, etc. I would not recommend Qt since it's not really C++ (uses an extended version of the language requiring a special preprocessor before compilation). Plus it costs a fortune if you don't want to give away your product.
BTW, that's not how the word "hence" is used.
You did not mention the richness of the interaction between front and back ends, which would weight the importance of the existing language in your decision.
I've worked with Qt, Swing and SWT, and typically used both C++ and Java code with all of these toolkits. The interaction between languages can add additional cost/risk. However, sometimes that cost is warranted given other benefits.
If for any reason you choose a Java front end, look at JNA and SWIG.
Let's all be honest here. C++ just ain't on the map when it comes to portable GUIs.
Java has a consistent, portable, widely used, thoroughly documented, mature GUI toolkit. C++ has a bunch of half-assed OSS libraries that barely work, none are truly portable, plus some expensive commercial libraries that don't work on all targets they claim to, work spotty on the remaining targets, and invert control so that you are stuck in their weird framework.
Unless you need C++ for other reasons (of which there are plenty), choose Java for the GUI. The cross-over coding is trivial for someone who knows both languages, but it can get messy to manage, so you'll want to minimize the native interface as best you can. My advice here is to make a pact with your team that you will never attempt to hold pointers (or references) across the interface. It just gets messier if you do, and no debugger can save you when the lines get tangled. Instead, use integer or string keys and pass them across the native interface.
How about eclipse? Looks good and performs well on all platforms. My guess is most of eclipse is Java.
Why you don't you learn native C++ GUI like WINAPI or X11? Then you can make console software to compatible one of them like winehq, cygwin or other open sources compatibility or emulated software, since you never developed GUI on C++. Don't go for Java because it uses much more RAM. Of course, unless you have lots of RAM. For example, Eclipse (which is coded in Java) can use 500mb of RAM when running with no project opened.
Wrapping is not rewriting, it's just an adapter to make both languages meet. It is straight-forward
As you don't seem to be fixed on a language, I would choose a .NET Gui (With C++ CLR) you'll have a GUI that is machine independent and you can easily communicate with your existing code.
For beginners WinForms is maybe easier, but try to use WPF, it's the most modern variant for GUI development in the .NET world.
Personnally I would use C#/.NET for the GUI and use a C++ CLR wrapper DLL. But it is not the only solution.
Under Linux, the best .NET implementation is MONO. For all WinForms apps I have developped (they are not the craziest ones), they ran without change. With C++/Qt you will have to recompile for each target OS.
Do not use Java for creating GUIs unless platform independence is a must. The user experience will be sluggish and interoperability to C++ will be a pain.
For creating native GUI in C++, you can either use GTKmm along with a library like Boost or QT. Additionally, these libraries are available for most platforms (GNU/Linux, Windows, OS X) so your application can be recompiled anywhere.
edit: use GLADE for quickly creating GUI and fill in the signal slots with C++ code in GTKmm.