Kicking off this month’s thread with a screenshot of a new game I’m working on:
Alright, then I’ll continue with my spaceship collection, all built using the app:
The right one is not finished yet and some got deleted because development but yeah, the app works quite fine now
I’m an old java application developer trying some game/3d code for the first time. Put together this random/infinite Martian terrain with physics balls type thing over the weekend. Mostly combined and refactored tutorial code. Had a blast creating it. Spent an inordinate amount of time tweaking the character movement to get it feeling natural. (no cliff climbing or trick-jumping into the ionosphere) . Next weekend I plan to add some random rocks and if I’m feeling adventurous, some kind of shadows (dust storm would be great!). Kudos to the JME devs for allowing me to have some fun with my primary language
Feeling a little left out again for not having anything fun to show like you guys.
I’ve been working on Lemur over this long weekend adding basic key/joystick navigation.
I’ve labeled the various graphs and added a graph that shows average message size over time, specifically synced with the time drift. If it proves useful I may add some indicator to the top timing graphs showing average message size. The theory being that message throughput may correlate to drops and you might like to see that.
While I was playing in the app, I’m starting to try to ‘finish’ it so that I could potentially fork it into another project to make it ES based and with more ‘game-like’ elements… one final thing was to add an in-game help menu:
…which nicely only took about 30 minutes including formatting tweaks and a midway redesign. Sometimes it’s nice when things work like they are supposed to.
Edit: incidentally, the reason the “Done” button is bright green is because that’s the default indicator that the button has the current focus… meaning I can now hit the space bar to toggle the button just like clicking on it.
Nice progress. Lemur looks more and more tasty to me. If you could somehow join code with Tryder and BigBanana that would look even more tasty. Key/Joypad navigation is a musthave. Android and iOS would be cool too.
Problem: Q and Z works nice for Qwerty keyboards. Mine is a Quertz (German keyboard). A problem I don’t know yet how to solve with my own game. Also getting some nice names for keys (like [Q] and [Z] and [Ö] and [ß] and [´]) will be quite a challenge. Maybe do it like in the TestBitmapText and take the letter produced by the key event - but that won’t really work either (it’s modified via SHIFT key and sometimes represents a two-key-after-each-other sequence). Get a Key-to-NameOfKey-map somewhere perhaps.
I currently allow the user to edit the text-based configuration. The sample application for BigBanana will have that. Maybe in future there will be a BananaPadConf appstate?
Achievement unlocked: your lib is mentioned on another thread, by another user
Well… I was more specifically meaning that the keys Z and Y are switched on my machine. So I receive a KEY_Z when the Y key is pressed and a KEY_Y when the Z key is pressed. Same with many other keys.
Schrecklich, überall diese Deutschen
(Who made this emoji: :chimpanzee_hitler:)
Well I think we have this problem in many programs so I got used to it.
And well yes, you should let the user configure the keys.
I use my flycam with Q and Z (Z between T and U)
if you would get a KEY_Z with your Y you would have to use the Y (next to X), where the english Z is
Weird. Here we also use qwertz keyboards (but no, I’m not German) and when I press Z I get KEY_Z event. Same as @MegaWolf posted in last post.
But yeah it’s annoying and I usually remap the up and down keys to space and shift (too used to Minecraft ).
Ah. yes, only the keys are switched. Causes so much confusion that I give a wrong explanation. ^^
Problem remains with all the fancy keys like [Ö] and [ß] and the like - which are missing on English keyboards.
And then there is Switzer-german keyboard layout which is different to the German-german one.
It’s a total mess…
Well I have those: čžš on my keyboard which I also can’t use
Maybe using a raw input listener?
Why would you ever use keys like ß in a game anyways?
I would not. But for example a user might add another up/down/left/right cross with [Ü]/[Ä]/[Ö]/[#].
Then the game would tell the user: “Now press [Ü] to move your fancy Über-Kamera a little bit up!”
(or show the correct key name in a help screen like the one that @pspeed posted)
If I remember correctly I also have the y-z problem, but I didn’t have that all the time. Could that be lwjgl dependant?
How do other people manage that? On the other hand it should be “trivial” to have the Z key return KEY_Z on every system.
The help screen could have been generated from Lemur’s input mapper (though it wasn’t for time reasons and because I didn’t think of it).
Lemur’s InputMapper was precisely written for the reason that being able to remap things should be easy and ‘reflective’. I have not written a UI screen for configuring these yet but the calls to InputMapper to switch keys or add new mappings is really simple.
You can see how the movement defaults are setup here (which was cut-and-pasted from Lemur’s camera movement example, actually):
…though lately I’ve taken to checking to see if the mapping exists before setting up a default so apps have more flexibility of when they override them.
As of this weekend’s commits, Lemur has that. It will be in the next release in some form.
Bunch of stuff related to that pending in the next release:
But as it stands, I can navigate the SimEthereal example with tab/shift-tab, cursor, joypad, etc… I think I specifically mentioned it in the post above.
It’s tough and I don’t think we easily have the APIs we’d need to query this.
My take is that some folks considered the keycode to be a location on the keyboard itself and the labels we give them are just more convenient than “2426”. So some keyboard moves the keycaps around but still reports the same key codes for the location. Keyboard mapping is a mess.
For a proper app, you’d let the user remap these things by entering the key they want to map. At that time you could capture the key code and the actual typed character as per the OS. I don’t know of a way to query this off the top of my head… but I will look.
Seems like JME has a KeyNames class. Going to try it out. All of the other approaches I saw were AWT specific.
So me and @empires just returned from PAX West. To refresh your memory, we were presenting Lightspeed Frontier in the Minibooth section of Indie Megabooth on Friday and Saturday. Standing around for 2 days is really damn tiring, but totaly worth it imho. We also gave away like 10kg of buttons
Our tiny booth.
Despite its tinyness we dragged in quite a large amount of intersted people and did about 10 interviews with various media people. The overall impression was that they liked it a lot and were interested in seeing more
We made sure to tell anyone that was remotely intersted about the backend that the game is made in Java and in our beloved Monkey engine. Surprisingly enough, a decent amount of people actually knew about the engine. I hope this gets the forums some new people
Their first guess was always Unity though
Also, the PAX Demo build is now released as v0.05 and you can get the changelog here and there’s also the download link in the bottom if you guys want to try it out again. It contains just about everything I’ve showcased in the August thread and before that.
Last but not least, PAX gave our Kickstarter a decent boost so it’s now only about $130 away from its goal. There’s only a few hours left though so I’d really really appreciate if any of you shared the campaign around.
…also a shame that it doesn’t show the mouse and joystick bindings yet… but then the screen is improperly named in that case.
Here is some code to dump all of InputMapper’s input mappings:
I hope to make converting a mapping to a visible string a little easier in the future inside InputMapper’s code. But it’s not too onerous even now.
Edit: when I post the next release, those of you with non-standard keyboard setups can tell me if the text is still accurate… since I’m relying on some other code to do it and it may or may not be that smart.