What are you working on? (Game Making Thread)

[Nathaniel3W]

Collision detection considered low level? Jesus Christ...

We don't all spend our free time writing ray tracers for 20-year-old hardware. To me, anything that isn't gameplay is low-level. That includes physics, which includes collision.

So the lines that you project the collision polygons onto, are they just parallel to the X and Y axes, or do you figure out what's occupied on a line perpendicular to the movement? Is calculating occupied space along an arbitrary line more computationally expensive than checking along the line X=1? Either way, do you have to see what's occupied along the entire line, or do you just look at what's ahead of the movement? I guess you haven't optimized yet, so what are you planning on doing?

I have zero experience in RPGM. I don't suppose you could just let the events move as physics dictate, and then try to return to the path?

 

[Nathaniel3W]

Aaaaand I just wrote a hacky fix that I'm a little ashamed of, but I still need to tell people who would understand.

When loading a saved game (using interpreted UnrealScript that builds in just seconds), the army and inventory would get loaded twice. Instead of finding out why, I just put in a variable to see if an object has already been loaded, and if so, move on. I suppose I could have put in a breakpoint, checked the call stack, and found out what calls what that loads the army. But this was faster, and it works, and besides, my last build was a release build for Steam testers, which means my breakpoints don't work anyway, and I don't feel like wasting the half hour to compile a test build, spend who-knows-how-long fixing this correctly, and then spend another hour or so compiling another release build.

I wonder how much of the software we use is the result of similar cheats.

 

[Ellie]

Probably a good amount of the original rpgm code and user scripts are based on that kind of workaround.

 

[Xilef]

We don't all spend our free time writing ray tracers for 20-year-old hardware. To me, anything that isn't gameplay is low-level. That includes physics, which includes collision.

So the lines that you project the collision polygons onto, are they just parallel to the X and Y axes, or do you figure out what's occupied on a line perpendicular to the movement? Is calculating occupied space along an arbitrary line more computationally expensive than checking along the line X=1? Either way, do you have to see what's occupied along the entire line, or do you just look at what's ahead of the movement? I guess you haven't optimized yet, so what are you planning on doing?

I have zero experience in RPGM. I don't suppose you could just let the events move as physics dictate, and then try to return to the path?

The need to write the basics out is still there in the right circumstances. The alternative I could have taken is use Box2D, however that would involve abstracting away a lot of what's happening and adding a thick layer of translation between Box2D and MV. Performance isn't the worry, the worry is that other people will be reading this code and making improvements or extending to suit their game's need, and needing them to know how the magical Box2D works underneath is more to ask than to simply let them read the basic mathematics behind 2D collision detection.

Not to mention, Box2D is a little over-kill. There's other collision libraries that are less physics oriented but then you're at the point of "why involve a 3rd party library when it takes just as long to write it myself?" and with MV I believe it's important to have the entire Plugin in one file, rather than split across library dependencies.


If I was making a game, rather than a Plugin, then I'd just use a third-party library to do this. My game projects I have planned will certainly use libraries.


The lines I project onto are perpendicular to the polygon lines, essentially the surface normal, but for the case of circles there a fast-path check for the line between the circle's centre and the nearest vertex of the testing polygon. Basically project polygon B onto the normals of polygon A, then do the same of A onto B's normals, if there's any gaps then there's no collision.

I don't check along the entire line, that would be more computationally expensive. The solution for checking along the line would be to see if the movement vector crosses the polygon edges at any point, which involves a line-intersection test. As long as one of the two polygons being tested is thicker than the step-size they won't be able to move through each other. The map lines, however, have a thickness of zero; so if the polygon moving towards it is smaller than the step-size it will pass over easy. MV doesn't have movement interpolation (locked to frame-rate) so this behaviour is consistent and isn't surprising.


There is a middle-ground; if the polygon is thinner than step-size in the direction of motion, then do a line-intersection test. I think this isn't necessary for RPG Maker and would end up adding bloat to the Plugin's code, which needs to be readable and simple.

If I was making a Doom-style FPS, then I'd use 2D line-intersection because of the variable frame-rate issue.


The most optimisation I'll probably do for now is a bounding volume hierarchy for the map's collision mesh. My original plan was to dynamically generate the mesh around the player as they move, however the maps in MV are static, so I can actually spend some load-time computing a collision mesh for the map (which I will likely cache to disk as further optimisation).


There is an intensive search and filter for finding all the characters that are potentially colliding (get all characters near bounding-box of motion); this is an area I'll optimise at a later date. It's fine as is, but won't scale when there's lots of events. I've looked at several techniques for updating bounding-box trees for when a single-node moves, just need to find one that fits MV's situation of having either a handful of events or a hundred events.

 

[Nathaniel3W]

Hey Xilef, I thought it might be better to discuss your Sonic Mania CRT shader here and let the others continue discussing how much they missed or did not miss Hybrida and Mega Flare.

Is that Chrono Trigger? I played it years ago, but I don't think I ever finished it. I think I played Chrono Cross first and then went and looked for Chrono Trigger.

So back to the shader. It looks very retro, but I'm not sure I'm catching everything, and not sure what's from the game and what's from your shader. I see pixellated images, with strong horizontal banding, and maybe the screen-door effect between pixels? Are you inserting a darkened or fully black row of pixels every several rows?

 

[BizarreMonkey]

Meanwhile in Bizland Fantasia progress is slowly but surely coming along.

Here's two awesome themes by my composer for the game.
http://www.youtube.com/watch?v=xW2Khw50n08http://www.youtube.com/watch?v=-yAHbjmjWaU


I'll also be posting screenshots in the apropos thread.

 

[LaDestitute]

I've been working on cleaning up and optimizing the codebase of my A-RPG Gamekit just a bit since the middle of August or something, after months of avoiding that task.

I've cleaned up a majority of the eventsheets used for the kit, so the following changes:
Removed/optimized a lot of either unnecessary or rough stuff, made the savedata management less of a hell to manage from an end-user standpoint (if developing a game), implemented a new A* pathfinding based patrol/wandering AI and moved all global variables into a hashtable.

 

[Xilef]

Hey Xilef, I thought it might be better to discuss your Sonic Mania CRT shader here and let the others continue discussing how much they missed or did not miss Hybrida and Mega Flare.

Is that Chrono Trigger? I played it years ago, but I don't think I ever finished it. I think I played Chrono Cross first and then went and looked for Chrono Trigger.

So back to the shader. It looks very retro, but I'm not sure I'm catching everything, and not sure what's from the game and what's from your shader. I see pixellated images, with strong horizontal banding, and maybe the screen-door effect between pixels? Are you inserting a darkened or fully black row of pixels every several rows?

Yes it is Chrono Trigger.

The pixelated base image is from the output of the snes9x emulator; that is the game as normal (although stretched from the SNES's frame-buffer 8:9 aspect ratio to a 90s TV's 4:3 aspect ratio).

A good CRT shader should simulate the RGB phosphors on a CRT display, which includes the horizontal scan-lines (horizontal banding) and screen-door effect.

The idiot's approach would be to slap a 2x picture atop the image that darkens or blackens every 2nd pixel. The basic approach in a shader is to darken the pixels between each horizontal colour change (so going downwards, 4 red pixels followed by 4 white pixels would be turned into 1 black pixel, 3 red pixels, 1 black pixel, 3 white pixels). What the Sonic Mania shader does here is actually simulate the gap-itself between the pixels, rather than the colour of the gap. That might stretch the brain a bit, but it basically says "If this image was X size, the gap would be Y sized". This is combined with the phosphor simulation, which comes next:

The Sonic Mania RGB phosphors are arranged in a PC CRT formation, rather than a TV CRT. This formation is basically groups of 3 components, RGB, but arranged in a triangle (red, green at the top, blue at the bottom). A 2x2 arrangement of these makes up a single pixel. The shader accounts for the base image and the luminosity of the components, so the red component will take on shades of green if the underlying SNES pixel is supposed to be green.

This also affects the scan-lines; the phosphors in this arrangement do not have a perfect horizontal line between them, so the scan-line will take a shade of red, green or blue depending on what phosphor is supposed to be 'hanging' near the line.

This isn't the best representation of a CRT display, but I think it is a good middle-ground. By doing this, you get a cool moiré effect if you resize the window to not be of integer size (see the pink banding):

This kind of thing is exactly what you'd expect to see from a CRT display shown on an LCD.

If the shader is below 2x window size, it turns itself off. At 2x size, it's so accurate with blending that you get the equivalent of every-other-pixel being darkened, which I think is excellent. Same deal with exactly 3x, you get every 3rd pixel darkened, which I think is great. Higher than 3x you'll start to see the phosphor effect. 4k and higher would probably look amazing.

 

[Nathaniel3W]

Hey Xilef! I picked up XCOM Enemy Unknown again recently. I noticed the CRT shader they use on all of their holographic displays and could appreciate what they were doing. Have you played that game? If not, you might want to take a look at it if only to see how they did their loading screen.

In other news, I made this shader to let you see your character behind buildings. But more importantly, it makes the camera flying inside of buildings not so annoying any more.

I also improved the timing during combat and added some of the particle effects I've been working on.

 

[Xilef]

That's starting to look complete! You've done a really good job.

 

[Nathaniel3W]

Thanks Xilef! I'm getting there.

So for my outline shader, I started off with a plain thick line. That looked a bit amateurish. I moved to a thinner line that used the scene's shadow color, which meant purple during the day, red at sunrise and sunset, and dark blue at night. I was never totally satisfied with how that looked. Now I think I have something I like a little more.

I take the pixel color, normalize it (so if you think of the RGB channels as a 3D vector, make that vector length 1, so you have the same color, but total brightness is 1), multiply the original pixel color by the normalized color, and you end up with a saturated version of the original color. Now multiply by the shadow color, and you don't just have a purple line over everything, but you have a darker, more saturated color of the pixel, that's pushed toward the color of the scene's shadows the same way everything else is: by multiplying the color.

 

[Nathaniel3W]

First look at the new desert-themed assets:

These models and most of the textures started life at the Unity Asset Store. I put them into Blender, redid a bunch of bad UVs, made custom collision meshes, vertex painted them, then made custom materials in the engine. In addition to my usual shader that changes color with time of day, I added wind direction, and the fabric and branches move in waves with the wind, going up and down and stretching slightly in the XY plane in the direction of wind. The red vertex color, multiplied by wind strength, tells the mesh how far to move. The blue vertex color tells the mesh if it has to stop moving downward at a certain point, so the fabric meshes don't drop below the wooden frames. It looks really good in close-up, like it's a physics simulation and not just the shader.

I also made some desert mesas that you can see the foot of in the background. I think I also need to make the scene more colorful overall. I should take a look at other games that have good desert scenes and see what they did to make everything not the same color.

 

[aphadeon]

Spoiler: today's work: event rendering comparison

 

[Nathaniel3W]

Do they look different when you actually play the game?

 

[aphadeon]

Do they look different when you actually play the game?

Not at all. Just working on the editor atm.

 

[Jason]

First look at the new desert-themed assets:

These models and most of the textures started life at the Unity Asset Store. I put them into Blender, redid a bunch of bad UVs, made custom collision meshes, vertex painted them, then made custom materials in the engine. In addition to my usual shader that changes color with time of day, I added wind direction, and the fabric and branches move in waves with the wind, going up and down and stretching slightly in the XY plane in the direction of wind. The red vertex color, multiplied by wind strength, tells the mesh how far to move. The blue vertex color tells the mesh if it has to stop moving downward at a certain point, so the fabric meshes don't drop below the wooden frames. It looks really good in close-up, like it's a physics simulation and not just the shader.

I also made some desert mesas that you can see the foot of in the background. I think I also need to make the scene more colorful overall. I should take a look at other games that have good desert scenes and see what they did to make everything not the same color.

It's always great seeing new stuff from your game man, I'll admit it's one of the reasons I still lurk around here. When I saw this .gif I straight up thought of Runescape, in fact that's what I think whenever I see just general screenshots of your game, or walking around in towns, and I mean that in a very high regard, since Runescape is still one of my favourite MMO's to play, lol.

Speaking of Runescape, with the latest graphical overhaul, I'm always very impressed with the graphics, and I spend a lot of time walking around and exploring just because in my opinion it looks so good for what it is... maybe you could take a few ideas from it? They do their desert areas very well in terms of colourful scenes.

 

[Nathaniel3W]

Thanks Jason. That means a lot. The internet can be a pretty tough critic sometimes. It's good to have some reassurance. Eventually I'll come back and ask everyone to pick the game apart and tell me everything that's wrong with it. But for now, it's good to know I'm on the right track.

I'll go take a look at Runescape. I have to admit I've never played it.

 

[aphadeon]

First look at the new desert-themed assets:

These models and most of the textures started life at the Unity Asset Store. I put them into Blender, redid a bunch of bad UVs, made custom collision meshes, vertex painted them, then made custom materials in the engine. In addition to my usual shader that changes color with time of day, I added wind direction, and the fabric and branches move in waves with the wind, going up and down and stretching slightly in the XY plane in the direction of wind. The red vertex color, multiplied by wind strength, tells the mesh how far to move. The blue vertex color tells the mesh if it has to stop moving downward at a certain point, so the fabric meshes don't drop below the wooden frames. It looks really good in close-up, like it's a physics simulation and not just the shader.

I also made some desert mesas that you can see the foot of in the background. I think I also need to make the scene more colorful overall. I should take a look at other games that have good desert scenes and see what they did to make everything not the same color.

I love the look of this, I really do.

This is not so much a direct suggestion as merely an idea: Have you considered doing toon-style outlines? Considering that the sprites have outlines of a sort, might work nicely. Just a trick I'm using for another project of mine - shader-based outlines generally don't create a desireable result for me. I get the impression you are able to edit the meshes. A neat trick is to clone the part of the geometry to be outlined (could be simply the entire mesh) - then invert all the faces and scale it up slightly (amount depending on desired thickness). If you want black outlines, remove the texture and assign it a black material - but you also have the option of using a second, darker texture for a "darkened" outline, or even inverted to create a magical outline (Blizzard used this trick a lot in the Legion expansion for WoW). You can fade lines or use thinner/thicker ones by playing with the upscaling amount at different points.

Edit: I kind of feel like you're using something for outlines already, but I can't be sure at the resolution of the image. So I was just sharing a less-used approach on how to accomplish it if it does interest you. Specifically I'm very, very slowly using it to make a toon overhaul of Skyrim, which I'll probably never finish because I'm too slow at the general texturing. An upside of this approach, and the reason I'm using it, is because you get to pick and choose what gets outlined, and what would be better off with textured outlines (generally cloth and such).

Just an idea to play with, but either way I will buy your game.

 

[Nathaniel3W]

Hey aphadeon, thanks for the suggestion. I have a toon outline shader, but like you say it is a little hard to see at that resolution. It's most obvious around the cloths when the camera zooms out at the end. It's a postprocess screen-space shader. I didn't know about the inverted normals technique. That's an interesting approach. I'm going to see if I can find some examples of how that looks.

 

[BizarreMonkey]

That's coming along nicely, Nat.

On November 2nd I resumed working on Fantasia. The first day I organized the music folder and OST listing for what is likely it's final set.

Currently 17 of these a produced, the rest are placeholders.

The next day I organized my file structure for the characters folder and did a lot of merging to cease file overload.

Much neater.

On that same day I also finally mapped the Backyard for the house, and implemented some new tilesets that I bought recently.

Today I finished up the Backyard, and also mapped The Undercroft (secret basement laboratry under the house) as well as a new mysterious area connected to it.
http://www.youtube.com/watch?v=5thkrt4k0dwhttp://www.youtube.com/watch?v=CoZA5z3Ak7U
As you may see, very atmospheric.

And also today, I added in the beginnings of an event, which is the final event of Day 1. The Barbecue!

Yes, Hello! Why yes, I am in fact Mr Productivity.

Happy with just how much I've gotten done in three days.