Janino is a pretty good java compiler. No generics or annotations, but beyond that, it's very nice. I tried Groovy first - it wasn't a good experience, and the Eclipse plugin for it was lacking. I forget the details - it was a while ago - but basically, couldn't do the things I wanted to do. Mostly it was the poor IDE support, though. If auto-complete (or whatever you call what happens when you ctrl-space in Eclipse) doesn't work well, I'm pretty much done with it.

Now, I've got a setup where I'm writing the scripts in Eclipse, and Eclipse compiles everything (for compile-time error-checking, auto-complete, refactoring, etc), but the game doesn't use those class files and compiles them on startup with Janino instead. Using a custom ClassLoader (really, a thin wrapper) to filter out some undesired classes from being loaded, though reconsidering that - may switch to a SecurityManager instead, or just let go of the paranoia about letting scripts use java.io.

Having some stuff in scripts is useful for making the game mod-friendly. Other than that, I'm not sure why you'd bother. Unless, maybe, the core game took ages to compile, and you wanted to avoid that? Non-issue for Java, though.

I have heard instanceof is surprisingly slow and it's one those things that has a bad code smell. However, its a safe, well supported feature, so it won't hurt anything if used in exceptional cases. And you could mimic it with a variable like ra4king suggested if it becomes a bottleneck. In your case, I would not dwell on instanceof since it seems like you can confine it to that one method and eliminate extra executions of instanceof.

This used to be the case in an older version of Java - 1.5, iirc. Java 6 and on, it's not a concern performance-wise.

Hmm. I always thought it was more of a "3DS Max for everyone", and people want to share their creations, and so it spreads.

Reminds me of this silly marketing question - is it better to have people say your company is awesome, or that your product is awesome? The answer (of course) is that it's a trick question, and it's better to have people say they are awesome. Minecraft nailed that.

When you get to know the ins and outs of publishing games you'll eventually realise it is not at all surprising. We didn't even want to offer it on Desura in the first place because we already knew it was going to be a waste of our time, but we humoured them.

I still want to make it clear though - maybe when they're 10x bigger, it's going to be worth it. But right now, they are not.

Cas

The reason it was surprising to me is they seem fairly popular, at least as far as getting press. But I guess the (alleged) 30% of the market Steam doesn't have gets split many, many ways. I mean, I didn't expect it to huge, but less than a tenth of direct sales is just... ow.

However. All of the features he mentions sounds like a TON of work. When do you think you will have a beta ready (feature complete)?

Tough question, really hard to say. Late this year, perhaps? A lot of stuff is already done - ship refitting + hull mods, damageable weapons/engines, fleet/cargo/crew management, a star system with rudimentary navigation - it just needs a few weeks worth of polish/cleanup/being made into a game before the next alpha release.

Of course, there's a lot that hasn't even been touched yet - a functioning economy and other such sector-wide high level systems, character advancement (actually shouldn't be too bad, that one - lots of hooks are already in place), officers, and outposts.

I think what's going to be the hardest is creating a good system for the economy/faction relations/etc, and then tweaking all those large-scale interactions until they work well. The other stuff is... well, lots of work, but it's self contained work and most of it you can just plow through.

I do worry that I may be underestimating the effort, but then, looking back at what's already done gives me hope.

Just updated and played again. I forgot to say its quite polished for a alpha and I found the controls a bit better from last time. However in auto pilot mode my ship flies into asteroids. Will there be any multilayer support? Right the now the game has a lot of promise, but the current crop of missions are not really doing it for me. I just end up flying around a lot and blowing up any baddies, rather than using fleet points and getting strategic.

Thanks!

No multiplayer - not to mention the extra work, the design goals for SP and MP tend to be incompatible.

Working on the campaign layer of the game now - the next release will have a basic version of that, the ability to refit your ships, and weapon/engine damage & repair in combat. Should add quite a bit of meat to the game.

Oh, as far as the asteroids, if it's small enough compared to the ship, the AI won't bother avoiding it - the consequences of trying are worse than the piddling damage the ship may take.

As for dual monitor. In linux at least there may be no fix in many cases, since the drivers are reporting that there is just a single wide monitor. Its up to the user to config there xorg to report things properly i think (some setups this will not be possible). Nvidia has quite a bit on it. Long story short, you need to add extra mode lines to the xorg.conf. Otherwise there is talk of adding this more directly to lwjgl, but even then i think the sea of different xorg config options, it will be hit and miss. You could tell users to config their machines properly

if its any consolation, the vast majority of games and even many apps, don't play nice on many monitor system under linux at least. As long as you support a windowed mode, your gold really.

Thanks - yeah, someone posted instructions for that on our forum a little while ago, seems pretty hairy, but like you say, also pretty clearly a configuration issue.

More of a pain than just highlighting it w/ "mark occurrences" toggled on, imo. If you have to do this for every field when coming back to some old code, ugh. But clearly, it works for you - it just wouldn't for me.

I think blaming access modifiers for wasted time is a stretch. They're just a tool - useful sometimes, not useful other times. Also a matter of style and taste. I don't buy that when someone spends too much time deciding which ones to use, it's the access modifiers' fault. That problem is between the chair and the computer

You could even arch an eyebrow at the mere use of the word "best" in the phrase "best practises".

Best for who or what exactly? And says who? And proved how? And when? Has the landscape, perhaps, changed rather significantly in the last 20 years?

Cas

I think the main change is in the quality of IDEs. Standard "best practices" are largely about future-proofing of some sort - maintenance, adding new features, writing more robust code, etc. Given how easy code navigation, debugging, and refactoring are now, most of that is completely moot.

That's net lines though, not gross. So if you spend January writing a new system that's 2k lines big, then a few months fixing bugs and adding features you might still only be on 2k lines for the whole year. Remove a subsystem and replace it with something new and you might have 'written' negative lines of code.

If that's indeed what the 3500 represents, then it's an apples and oranges comparison. "Hey, if you're not writing new code, you add less lines of code!" ...

I'm having a hard time with the 3500 lines of code/year example, though. Sure, you need to be 10x more efficient than that, but most of it comes from simply not having burdensome process, the reduced communication overhead that comes with a small team, and increased motivation. In other words, things not directly related to the code. It's hardly plausible that the 3500 line corporate figure arises simply from gratuitous over-engineering

Only just had a chance to follow up. This is exactly what I'd tried out in Praxis without problem - just checking there wasn't anything more complicated involved. As mentioned, I'm using 2.5.16 and the ClassBodyEvaluator. Which of those helps I don't know.

I think the SimpleCompiler superclass of ClassBodyEvaluator can compile full Java classes too (personally I prefer using class bodies for user scripts) which might also work OK.

Just to make sure - are you using the same instance of ClassBodyEvaluator to compile both snippets? You have to be using the same instance of JavaSourceClassLoader for the problem to show up.

We should have online sessions where java game programmers can "learn" how to write bad code, and get their game running asap.

Who will volunteer?

I don't think anything but bitter experience can teach that. If you like programming, it's tough to really internalize that nobody cares about your code. I think we all like to take pride in our work - and this is good! - but the mental shift happens when you stop seeing it as "programming" and start looking at it as "making <something>".

I'd obviously do all the compiling in the map editor using JavaCompiler. No need to manually compile scripts. I'll then have a play button that compiles all the scripts and fires up the game with the map, and also an export function that saves a playable map from a map project with all the scripts compiled so that it can be opened by the game without the need for a JDK. The only thing that the actual modder/maker is exposed to when it comes to compiling is having to download the JDK.

Ah, my apologies, that wasn't obvious to me From what Mads said, it seemed like modders would have to know about "compiling", which in this case they don't. They just have to install the JDK, as you said, and the rest just magically works. My mind just didn't conflate "modding" with "map editor".

I'm curious; why might you possibly need this? Players who want to mess with scripting, should not have a problem compiling.

I know that wasn't directed at me but... compiling is a huge pain for a lay modder. If you don't have to compile, the barrier of entry is really low - a text editor and the willingness to experiment. Once you make them run javac with a classpath set properly and all that, I'd think you're weeding out the vast majority of people who might otherwise be interested.

What's wrong with "Please download the Official Java JDK from Java.com to be able to run this game."? You could even have the game download it for you from Java.com?

Call me crazy, but I prefer to have the players run the game using the same JRE that it's been tested against. Besides, stuff should "just work" as much as possible - a manual step like that means someone will inevitably screw it up and need help, or get mad because the JDK installer installed crapware on their computer (which it does). Everyone is happier when the player doesn't need to do anything special to get the game running

You may not need the whole JDK. If JSR199 is available as a redistributable download, the eclipse compiler implements the javax.tools.Compiler interface too, and that's bound to have less bugs than Janino.

Actually, you should not use display lists because their implementation is not consistent on some recent hardware, it is a waste of time. Rather use static VBOs even though they can be a bit slower with very small datasets.

Do you have any specifics? What hardware, any particular uses that trigger it, etc? I'd really appreciate any info you might share. I'm using display lists them and haven't had any problems (or had any problems reported).

... Just create two java files, with the first one containing a method with a while(true)-loop with a break; to exit it. Then load both of them with a JavaSourceClassLoader (the while-break one first) and bam! JaninoRuntimeException!

Yep, that's all it takes. Kind of surprised it took this long for someone to run into that, tbh.

I started out using Groovy for scripting in Starfarer and had all sorts of trouble, from compilation speed to code compiling and then dying at runtime. It was all resolvable, more or less, but added up to being a huge pain. Janino, on the other hand, worked very smoothly.

As an added bonus, you can use your Java IDE of choice for the scripts. I've set up my projects like this: a core project, an api project, and a scripts project. Both core and scripts depend on api, but core does not depend on scripts. That way, you get all the compile-as-you-type support from the IDE - but at runtime, since core doesn't depend on the scripts project, it doesn't see the IDE-compiled class files and can use Janino to compile them on startup. Works like a charm, and forces a clean separation of what's accessible to scripts vs not.

Sorry to hijack the thread a bit... I've been using Janino for a while, and ran into an odd bug - it seems to not be able to handle break/continue inside a loop. It will compile that code fine, but then dies on the next compilation unit with this stack trace:

You don't happen to have more info on that, do you? The exact issue is that the combined resolution of the two monitors (say, 2560x1024) comes back as the only result from a org.lwjgl.opengl.Display.getAvailableDisplayModes() call.

Right. For me it's not really about the loading speed, though that's a concern if it's heinously slow, but about the speed and convenience of entering the data by hand.

XStream looks good - very good, actually. I'm just not a huge fan of using reflection to fill in bean classes. It's too easy to break by doing a refactor of a variable name, and the IDE won't warn you about it.

I suppose that's where aliases come in, but if you're going to do that, that's roughly the amount of code needed to read the data in with a regular API and doing the mapping yourself - while doing some other nice things like specifying defaults etc, mapping from strings to enums, etc.

This seems like a bad idea. The java snippet would probably be faster to write than the text because of IDE support, anyway.

Supposing you're using the generated classes from some other code, you'd need to compile against the generated classes anyway, which you couldn't do if you only turned the generated code into classes at runtime.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org