(April 2018) Monthly WIP & Screenshot thread

[themiddleman]

For some odd reason this reminds me of the Doom/id tech 1 style of maps

[MoffKalast]

Can confirm, reminds me as well. I think it’s the octagon rooms and the 2D layout.

[pspeed]

To get an idea of level size, I plotted out a route through one of the large maps and recorded it:

sb scale flythrough test

…complete with ~80s style music to complete the Doom theme.

Note: I’ve just temporarily blocked some of the openings with junction panels. There will be real walls and stuff later… especially for the rooms.

[FrozenShade]

Nothing special, just a lurking spider…

[grizeldi]

That spider be like

[pspeed]

Spamming the thread again…

I have a navigation graph implemented with a nice debug view state:

I created a smaller random map for testing:

…proving that it can be done.

Edit: now to do the harder part: actual steering and navigation.

[iamcreasy]

What kind of navigation graph you are implementing?

[pspeed]

@iamcreasy

What kind of navigation graph you are implementing?

I’m not sure how to answer that question. “The kind you use to navigate.” doesn’t seem helpful but I’m not sure what the real question is otherwise.

[Benoit_Dubreuil]

@pspeed

@iamcreasy

What kind of navigation graph you are implementing?

I’m not sure how to answer that question. “The kind you use to navigate.” doesn’t seem helpful but I’m not sure what the real question is otherwise.

I think @iamcreasy meant whether you use a navigation mesh or waypoints. Both of them are the most conventional graphs as far as I know.

Just by looking at the image, it looks like a waypoint graph but there’s no guarantee that the visual representation of your graph is the same as the actual graph. The reason behind this is that we tested debugging a navigation mesh with its actual mesh and it’s kinda messy. We could spend more time perfecting it but I think the best way to show a quick debug view of a navigation mesh is its dual : the waypoint graph.

Anyway, thanks for the media, it gave us ideas

[MoffKalast]

@Benoit_Dubreuil

whether you use a navigation mesh or waypoints

@Robbi_Blechdose

Would you use your own solution for pathfinding or use JME3-AI?

Since the latter is working quite well from my experience, you’d just have to generate a NavMesh from your level, I’m not sure how difficult that is.

@pspeed

I’m going to use my own solution. In my opinion there is no reason to generate a navmesh for the whole level as all of the parts are the same. The ‘portals’ between parts can act as waypoints and there will be general avoidance steering beyond that.

A few posts up.

[ia97lies]

I made some progress with my laser cannon which sends out a endless laser beam as long there is nothing in the way

And here if it hits something

[asser_fahrenholz]

I implemented an auto-tiling system based on Wang Blobs, to edit the map directly in game

Subspace: Infinity - Autotiling in-game

Edit: And yes, I load a module called ‘wangTester’

[pspeed]

@asser_fahrenholz

Edit: And yes, I load a module called ‘wangTester’

And if you ever need to know the time elapsed in the wang tiling will you call it wangSecs?

Well… that’s numberwang. (Also made me think of this…)

Numberwang Episode 1

[thecyberbob]

Missed a serious opportunity to use this song as the background of your video there:

Wang Chung - Everybody Have Fun Tonight

[danielp]

Over the last few years I’ve been (slowly!) working on an MMO platform. Most of that time has gone into designing (and re-designing, and re-designing again) backend systems and a new ES. Over the weekend I finally had a chance to do a major code haul and managed to get enough pieces playing together nicely to stream entity/asset data and have things actually show up on screen. The following is my test account’s (not exactly PBR ) avatar:

[Album] New ES working

Yeah, I realize that rendering an unshaded plane is about 5 lines of code in good ol’ stock JME, but this is going through a few more steps (~10k-ish lines of code, probably most of which are necessary for this to run) . After the user logs in, the server fetches the entity data for the user’s avatar, adds it into the server’s ES, and caches (assets are permanently stored en masse in a mirrored backend cluster) any assets referenced by that entity (in this case, a planar mesh). After the login process is complete, the server starts streaming entity data to the client, which is also running its own ES locally (non-authoritative duplicate of the server’s ES). The client also has a local asset cache, and as entity data comes in it loads or downloads assets on demand.

I’ve been focused largely on the server/asset system/ES up to now, so the client is really needing some love. My next projects are probably adding some developer tool and inventory UIs to the client.

This is the first screenshot I’ve posted since virtually all of my work has been backend/server stuff, but from now on I’m going to try to have some at least marginally interesting screenshots to show off each month.

Fun fact: If the upper-left textfield is empty, the button right below it is an insta-crash button!

[Benoit_Dubreuil]

Even though I actually did this a month ago (shhhhh…) I finally made a video about it : unit vision with cones and ray casting!

Unit Vision

[asser_fahrenholz]

Is this opensource?

[danielp]

Eventually I do plan to release it as open source, but I’m keeping initial development closed. The codebase is too unstable right now, and I’d like to finalize a strong and unified initial design before trying to bring other developers on board.

[Pesegato]

I’ve finally decoupled the dyn4 collisions from the sprite batching!

Also, the dyn4 debug is a separate appstate with its own viewport (the code I wrote 3 years ago was really handy!)

[ia97lies]

Finally I made it yay! That laser makes those easy target explode like popcorn