Відео

Indeed!

I appreciate the feedback. I hear you. I should name it "Arena Shmup Demo", since the name "MonoGame Tutorial" is misleading to viewers -- though it is technically correct: the video really did come from a tutorial I gave two engineers in real-time on how to create a simple MonoGame game framework. (The object pool code is actually not even finished and would be embarrassing to share in its given state -- and you're right, it's difficult to even show off what it accomplishes over not having it.) Nonetheless, I made a decision to upload anything I work on. I have certainly thought about make true tutorials, since I give them ad-hoc all of the time anyway -- and even sharing them with the MonoGame developers for their own website. But it is a non-trivial undertaking to do it "officially" and professionally. However, I think a 30 minute video chat in real-time, that is recorded as-is, may work.

Yup, that was a pretty close one!

Hey, I would love to see the output of your algorithm. Yeah -- I have a bunch of videos where the input image are existing textures, and in this case, characters! It's fun to see. So -- the socket technique you refer to -- I presume you mean the connection allowance logic. I didn't make anything custom; the logic for this is extracted from the input image itself!

@@JDoucette Ah, yea i could imagine that making indiviudal socket IDs for every pixel would probs be quite impossible. Tho with extracing the logic from the image itself, it does look hella funny. its as if an AI had alzheimers and were to draw bowser from memory lol. I also adore the visuals in your videos btw. My project is a procedual town/village generator. It uses all kinds of algorythms already, that being the good old perlin noise for town/village outlines, L-Systems to generate street networks (had to heavily modify that one as well to actually produce realistic looking networks) and plots (this is my own creation) to identify pieces of land, on which buildings can be placed. Now I'm using WFC to decide, what kind of buildings are supposed to be placed on the plots. For example, a school shouldnt be next to a factory. A market should only be placed on larger plots, a playground should be placed next to housing-blocks, but if there is a playground nearby already, it shouldnt. A church should be placed somewhere near houses, but more than 1 church per town/village doesnt make any sense. So yea.. thats why my plan is the WWFC-GC and now that i think about it, it also has local constraints, so the name should actually be WWFC-W-GALC (Weighted Wave Function Collapse with Global and Local Constraints) lol. I will defently show it off, once everything works :)

@@SchnurriTV Yeah -- exactly -- it seems like an AI is trying badly to remember what he looked like and is just coming up with some random stuff. I know this is not what WFC is supposed to be for, but once I saw the outcome and found it funny, I had to share.

@@SchnurriTV Your plotting algorithm is interesting. Long ago, I made a city plotting algorithm for a overhead view game where you could control cities and take over other cities -- kind of like Civilization, but more focused on numerous cities that already exist. I made local constraints (cities shouldn't be too close) and notice patterns -- the constraint cause strands or streams or lines of cities in various angles, since the constraint was too rigid. I had to explicitly code to avoid that (literally look for a pattern, and reject). This simple algorithm worked wonders. Why am I telling you this? I think because your WFC is overkill for what you need. While you limit 1 church per town, so you keep global constraints, the local constraints (playgrounds being close to X or not close to Y) can be solved with a less strict algorithm than WFC. WFC is so strict it causes problems, like the hand in Bowser wrecking havoc causing the images to be constrained to it. Without WFC, and with some less rigid constraint, you could get your plotting exactly how you want, but never too logically consistent from town to town -- the variance will be desirable.

@@JDoucette Oh what you are explaining is really interesestig and i can really imagine how it would look in my head. Especially with the cities being built in a line, due to the constraints sort of telling em to do exactly that. hmm yea, i already thought so that the algorythm i'd be working on would really just use WFC as a sort of inspiration, while in reality working qutie diffrently. The good part is, is that the shapes, distances and roadnetworks are made by the other algorythms i meantioned (perlin, L-systems, plots). Rn the towns and villages look as if you were looking at a town in google maps in street view, not sattlite view. those already have a lot of variance, so wfc shouldn't produce too predictable looking things, when it decides, what building should be placed. Tho I guess I'll only know once I've implemented it. I will def keep ya updated 👍 thanks for the heads up!

I was just watching "Ross's Game Dungeon: OutRun Clones" and they mentioned the same thing. While I've never thought about open world, since by its nature, these pseudo 3D engines are "pseudo" where you cannot wrap the turn back around on itself ever. However, I have thought about recreating the road portion of an open world -- meaning as long as you stay on the road, and its junctions, you can go anywhere. I believe this is fully possible.

Indeed it does! So I'm using the GPU here. The individual voxels are rendered with their own Z-value when sent to the GPU, and I have the Z-buffer on. Now the trick is the sorting of sprites -- I made my own pixel shader to not impact the Z-buffer when touching alpha=0 see-through pixels in the sprites, so I get an extra advantage of not worrying about sprite render order.

In full software, like my original VGA engine, I wouldn't have used a Z-buffer. I'd use what I did with my pseudo 3D scanline road engine did, except per column instead of per-screen: store the hill tops, and their Z. Now when I render a sprite, render columns, look at the hilltops of that column, decide which two the sprite is between, then assume that's the screen bottom. No Z-buffer checks per-pixel required; it's just a simple range check, then hammer out the sprite pixels. This, of course, requires rendering sprite back to front.

@@JDoucette Thanks for your answer. As I'm writing a software renderer, I already have some sort of 1D Y buffer for each column, because I draw from front to back to not have massive overdraw. So you would simply check the sprite height and Z against that Y buffer and it's Z value? You said rendering the sprites from back to front, without a per pixel Z buffer. Wouldn't this lead to overdraw when I render sprites above each other? I have to try this approach.

@@bubu5908 Your 1D Y buffer per column, front to back rendering, is how I handle it as well. In a pure software renderer, this has the natural ability to give you hill-tops. Every time you don't render a pixel, it's behind a hill top -- remember those, and their Z value. Each sprite should render column-wise, and pretend the next-closest hill top measured in Z compared to the sprite is the sprite's min Y render pixel -- it's just a range check before you plot the entire column of that sprite.

@@bubu5908 Without Z-buffer, you do back to front for sprites (front to back for terrain), over draw for sprite pixels, but never rendering "behind" already rendered terrain. So the terrain remains zero overdrawn. Sprites will have overdraw.

I have never tried to do water reflections, but I have thought about it since I made the original VGA Mode-X engine back in 1995/1996. I recall that Comanche did it in their second version of the engine. Off hand, y-shearing to fake up/down look shouldn't impact -- since even if the camera direction changes, the light arriving at it doesn't. You'd only want that effect in the case if desiring an effect even though in reality it doesn't occur (kind of like lens flare), which means you need to decide the effect that you want, and then code it. Get it right before shearing, then implement an adjustment with it to drive towards you desire.

These days, with faster CPU/GPU, we can do one better than Comanche -- reflection and refraction! So we'd need heights below the water, and the water height itself. That would be more complex -- a mixture of water color, the underwater terrain, and the sky!

@@JDoucette I think I've figured it out. The code was kind of correct, but the curvature caused problems. Y-shearing wasn't the issue, but when the horizon reached negative Y values, it exacerbated the problems. The column shearing to simulate the roll-axis wasn't helping either. I'm not completely sold on the effect yet, but I think it can work for now. They're not 'real' reflections, of course, since it's all software rendering. I'll just wait, hoping that someday someone who knows more than I do will make a tutorial on how to do it correctly.

@@adrikriptok7225 Looks like Comanche 2 simple reflected the sky. It would be more difficult to reflect the terrain, and refract the terrain (based on angle and depth of water), and also reflect the in-game object sprites. If you have an example of what you accomplished, I'd love to check it out. Maybe you can figure it out and make that tutorial yourself! :) One piece of advice is to ignore the shearing for fake rotation and camera pitch; just let that rendering whatever you have already calculated into your buffer. This will simplify things.

@@adrikriptok7225 Also, take a quick read of Shawn Hargreaves' article "MotoGP: road reflections" -- he accomplished reflection by taking the resultant image and just inverting the whole thing. It was a good enough approximation! You should feel free to make some hacks, since even the Y shearing is a hack for camera pitch and roll.

Yessssss! Let's do it! =)

Thank you. I like this video more than the future ones, since it has the element of random placement, without look so perfect. I removed that since I was making things more mathematical to test various perspectives, but for aesthetics, I need to bring this design back.

I developed this engine in 1995/96, once I got access to assembly language. I wanted to produce a rail shooter like Space Harrier with it. I figured the blocky artifacts of jumping from one voxel to another during motion, when up close, wouldn't work well with the clear distinction of depth & reality that a ray caster with walls gives you. The engines are similar in terms of casting, so someone had developed Doom + Voxel height in one engine in the mid 90's -- I cannot seem to find it now. There is disparity in the level of solidity, as I mentioned before. But yes -- it could've been the Far Cry of the early-to-mid 90s for sure. Another issue is that Doom's sectors/portals via doors allowed for optimization so you could limit what you need to draw far away. Voxel terrain also has this ability "if you're smart" -- but it is nuanced. If you're sitting in front of a mountain, chances are you cannot see the ocean behind it, so stop calculating it. But if you climb a large hill, near but not at the top, you can see large structures / trees that sit on the other side.

Thanks so much! It's funny how consistency actually helps quite a bit -- the UI is pretty basic, but I like it as well. I've been itching to get back to this but am working on another project right now. So... do you have a voxel algorithm already implemented? I'd love to see your progress!

Sprite locations: First, simplify your problem. Assume there is no Y (height). Then you have a flat plane. Now, assuming that your voxel ray caster is correct perspective (it should move faster on the edge columns than in the middle -- if you're not doing this, you have a distortion, which is fine, but only fine if you intended it & understand it, since your sprites have to match!), the sprite is just ahead of you (Z distance), and sideways in X (left/right). If this gets complicated, simplify again! Assume no camera rotation for now.

Now, that's a simple Inverse Z: The delta in X from center is just inverse Z. Same with Y in fact -- if you have a flat plane, make it constant. Once you go back to having voxel heights, and your sprites have Y, use the sprites' Y coordinate. Now when you rotate your camera, you just gotta rotate the sprites as well... as you know, the character doesn't turn -- the world turns around you! Aren't you special! ;) Hope this helps!

@@JDoucette Thank you so much for the info and taking the time to reply! My trig skills are that of a pre-schooler but I am going to tackle this slowly and make it work. Might need a few days. I actually have several versions, starting with a straight up copy/paste from s-macke to my much more inefficient, but my own, code. I generate a normal/slope map too, so I have running water. Which sounds neat but really isn't much of an improvement over your own or any other implementation. Once I've got the sprites cracked, I intend to create a basic moon-lander game or similar. It'll be in Javascript, web-based, so I could send you a link at some point. I'm pretty certain it won't be an improvement over your own implementation though :D Thanks again!

@@whoshotdk That, my friend, sounds like an awesome little game to showcase the terrain! I've always wanted to make a Lunar Lander game, and I actually did in GW-BASIC way back in the day, called "IO Lander", named after Jupiter's moon. I had never imagined using my voxel tech for a lander game! I wish you luck, and I sure hope to see it!

It sure did not! :) Random noise from the lack of mipmaps and all of that aliasing are hard to compress. I'd like to do 2 things: 1. record in 4K from now on, since even these pixelated graphics need some help with extra data. 2. more importantly: use mipmaps, but not the GPU generated mipmaps; I want to control the jump to the next mipmap level and draw that mipmap texture myself -- just like the old school Sega System 16 days where sprites could only scale 2x, therefore, by hardware requirement, everything that scaled had mipmaps.

Everything is both 2D and 3D. Sprites are 2D images, but they are processed in full 3D -- they have an X, Y, and Z component. The road is not so much 2D, since every single scan line (every row of pixels) is an individual object that has X, Y and Z -- which is why it's so smooth with the curves, hills, and bends. However, everything is really only 2D, with a scaling component. Just as the 2D sprites can only ever be viewed from the front (they cannot spin around, even if they go around a sharp turn), the scan lines also cannot "turn". They are always flat to the camera. You never see the road from the sideview, even if it appears that the road turns 90 degrees. Therefore, you're basically seeing a 3D image of something that is representation a 3D road. The output is true 3D, but the object you're seeing is a road that ONLY moves into the distance, and NEVER turns. The turns are fake: The road (and objects with it) are basically strafing (sliding left and right), doing so more extreme for tighter turns.

@@JDoucette Fascinating. Thank you for the detailed explanation. I absolutely love this.

@@TheProtectorate-yq7vi That's awesome to hear! :) I see your channel is about all kinds of retro goodness. My heart is still in these games and these retro style engines. I bounce around a lot, as you can see with my videos, but I've wanted to make a racer out of an engine like this since I saw Pole Position in the arcades and tried to make an engine like it (and eventually succeeded in GW BASIC!) Someday it will be a real game and not just a demo!

Figured so. It should have warned me that these would all appear in my feed. It doesn't make sense since they were publicly published a decade ago.

Ok, thanks for checking.

This would have been on a AMD 200 Hz but it would have run at a decent framerare on a 486. I don't recall how I recorded this. I should run it again on modern hardware with DOSBox and upscale it to 4K so that you can see more than a blur!

@@JDoucette I think they are asking because it's blurry. It shows up as being published 2 days ago, even though this is from over a decade ago.

@Xonatron Yes, I realized that after the fact. This is why I lost a couple of subscribers because it looks like I'm putting out low quality content. Like you said, it's a decade old, and in fact from mid 1990s. I should upload new quality versions. It wasn't my intention that these appear as published since I published them a long time ago. I changed to unlisted last year and just reverted it now.

Glad you liked! :)

I know -- we always thought this was such a great design. You need to have them move in quantum steps for this to happen, otherwise, you need many frames of animation.

Is mechsim a particular game that has abilities to be modded? I'd love to know more. You have me researching this now. In any case, I would love to finish even a simple game with this engine -- it's been a childhood dream of mine since I first saw Pole Position / Out Run / Rad Racer.

​@@JDoucettemost modern games are moddable, earlier ones may or may not be. Mechsims as in, Mechwarrior, Earthsiege and Starsiege, Heavy Gear, Titanfall, also Terra Nova: Strikeforce Centauri if you are willing to stretch it. Giant robots fighting each other and, possibly, other vehicles and infantry as well.

That's a wickedly nice comment. Thank you so much for sharing. Curious if you do any game/graphics/retro development yourself?

Ha, wow, amazing compliment!

I was thinking exactly the same thing. I just wanted the windows to disappear to show the isometric background, like I do every time, but there are too many for manual movement. I already have a window animation intro, and thought I should just make them disappear in some kind of cool exit pattern -- explosion, or sine wave, or something. This ended up being the first thing I tried. It showcases the "next effect" transition akin to so many demoscene demos. I just happened to find decent music to add.

@@JDoucette These patterns could be enemy patterns in a shmup game.

@@Xonatron Yeah, that's true. It some sense, it reminds me of the modern Galaga game, but I think that game failed since it didn't really give you a way to appreciate the patterns that they created. The original Galaga afforded a lot of appreciation in simply watching the waves form. There's a lot to be said of that design.

@@JDoucette Oh yeah, I forgot about that game. It was too pattern oriented. Not enough empowerment to the player. More strategy and the placement of your drones.

@@Xonatron I had forgotten about it too, until I started thinking about sin wave patterns of enemies. It was called Galaga Legions.

Yes, I've never seen this before. It may be interesting to show which ones are mirrors or copies or inversions of others, and eliminate them. Then eliminate ones that are not interesting and zoom in on the remaining.

You are too kind. Glad you enjoyed!

Amazing, isn't it?!

Thanks! I agree. Sometimes I think I made these videos too long, and I should have at least sped them up. But I think there's value in seeing how it works in a slow enough speed to witness how the collapsing actually works.

Sprites locations would be defined 1st: by the point on the Mode 7 plane that the sprite stands on, then 2nd: take into account the sprite size to match this position. Sprite size is simply scaled 1/2 size if 2x distance -- inverse proportion from camera. So the real trick is to find out where is the point? To do that: rotate the sprite (point) position so that it's relative to your camera. Now, it's simple 3D math -- the same you are using to compute your Mode 7 calculations!

In short: Xscreen = Xworld / Zworld Yscreen = Yworld / Zworld

@@JDoucettethx :) ua-cam.com/video/Boad3tioH3o/v-deo.html

Hey thanks! I missed your comment until just now. I've been "off the grid" for a bit, but I work on my engines/games/demos every day. I have also been prototyping some possible commercial products, so I haven't been able to showcase anything recently. I am trying to make more time for my own projects though. I usually want something substantial before I upload, but maybe should lower the bar a bit. :)

Yes, I have considered that. In fact, I have a non-real-time version of this engine that did exactly that. Search for "Xona eScape" for a link on my company (Xona Games) webpage for a preview. This was before the days of pixel shader GPUs, which would be awesome for real-time lighting. The height/color maps I am using have the lighting baked in, but I'd love to shade them in real-time. Not because I want the sun to move (as cool as that is), but to allow for real-time modification of the terrain! :)

I was thinking about how to visualize that in this demo. If you did it how it would physically work, it'd be like Manifold Garden where you see an infinite number of maze repeats... if you zoomed out enough to see. I plan on having such zooms, and this is information overload. It distracts from the simplicity of the maze.

An alternative is to only show one maze at a time... it seems to be the only logical solution to avoid all of the repetition noise. You could fade one out as the new one fades in. You could also handle the tunnel as it's own thing... sort of like Salt and Sanctuary, when you enter a house, the world fades out and the internals fade in. It is a very nice effect. Imagine the warp tunnel being that house.

You just made me consider a new idea... a one screen game typically requires the warps to have the same X or Y coordinate on both ends. But if they are unlinked, as in Downland, then you could have a warps that send you into another unaligned part. Or, perhaps as in Downland, it could just be another screen/maze.

@@JDoucette That could be phase two for this type of game, where you add exploration.

Thank you! Glad you enjoyed :)

Ha ha! I had to translate this. Looks like it's Javanese for "The game is messed up" :D :P

Thank you, my friend. This reminds me -- I have some neat updates for this that I've been meaning to toy around with and upload -- since it's so dynamic, you can really make it do some cool things by not letting it stay so stable.

@@JDoucette, I am trying to implement moving along 3D Catmull-Rom path as in the Rollercoaster, but hurt with quaternions :) Move Along and Rotate the box around this path and rotate the scene and camera position at the same time - it is very hard

@@insight8226 Ah yes, you're definitely looking for something like a spline, from which you can take the derivative of, to know the angle and direction for anything along that path. Catmull Rom are cubics, so this should be possible.

I was thinking about making some old TI-99/4A remakes for the Global Game Jam 2024 -- such as SuperChase, The Attack, Tombstone City, etc. I think all of these old games have an element of fun, even though they are simple -- because of their dynamic interactions. A lot of that was a novelty at the time; even seeing a maze.

Despite these things no longer being novelties... there's no reason you cannot use this as a base foundation upon which to build something more fun. It just has to have something new. I actually have a Game Design Document just on ideas for SuperChase, which is essentially a maze game (just not "find the goal"). Even a maze running game could have many environments (maze types), levels, progress items to help you achieve your goal.

I replay Plants vs. Zombies every now and again, and even though it's probably the best tower defense game as-is, the game still has many mini-games through the main play through, then 20 more as side-games you can play, another 20 more puzzles (mini-games), and an unlock system meta-game (basically RPG). It's designed very well. Let alone the character (literally the characters in the game) that it has.

@@JDoucette That would have been really cool. We should have Xona Engine ready to do that for next year.

@@Xonatron I could have used it in its state almost as-is. Simply starting a new project within it helps showcase what I demand for ease. I have found myself wanting a simple GameObject class, and even a 3D version of it -- which I had made before, called a Sprite. Ideally whatever you want quickly should be effortlessly available.

Yes! Please don't laugh too much. I never toyed with 3D with XNA or MonoGame before, and it's quite nice. You immediately get into ownership issues of CPU and GPU and updates. Quite amazing for something so simple.

Star Fox would be awesome. Silpheed would be more simple and easier, and possibly a better arcade game, though less impressive. But I do love that Tetris level... 😊

Heh. What you are seeing is my attempt to remove true perspective and add the false perspective of most racing and driving games of the pseudo 3D era... specifically Out Run. It is hard to model since it uses a basic look up table, though I approximated it. See the prior video. But it ruined the distortion for curves and hills! Now, I need a generic solution for all of this, which is much harder. Easier is to simply support one perspective style and ignore all others!

Thanks so much! That means a lot that you notice. I have to get some more videos made soon. I have more tech in the pipeline to show off. Then need to refocus onto some more simple game development to showcase the components made. One step at a time!

Thanks. That player would be me! Whenever my twin brother and I played we would always use the Fire and Spreader. We played with the game enough to see that the spreader had 10 shots maximum on screen and two players had 16 shots maximum. We figured out rapid fire Fire or the charge blast Fire were super powerful when used correctly. Also the Fire spray can hit enemies through walls!

No, it's just 2D Catmull-Rom, but 3D would be a neat idea! I'm making a "point cloud" engine for showing off fractals in 3D, and I'll have to keep this in mind.

Thanks for your interest Menko. Development is only paused while I work on the Xona System 8 engine -- which is a high level engine that will support what I call "sub-engines" such as my voxel terrain, 3D road, tiled side-scroller, raycaster, etc. I'm thinking about making it use the Voxel engine first... I have great interest, and have been creating a Game Design Document for a game that will use this voxel engine. I am getting there in baby steps as I find time.

@@JDoucette I'm just happy you're still alive! :D

@@JDoucette What are your opinions on zig/jai/odin/rust?

@@MenkoDany That is a very kind thought! Yes, still alive and I have high hopes for this engine. I didn't want to upload videos simply of new terrain without any new features, and I didn't want to program new features before the "sub-engine" was incorporated into my "Xona System 8" game dev engine.

@@MenkoDany Hmm. Well, I had to use ChatGPT to tell me what each of those are (except for Rust, so I presumed the rest were programming languages too), which is awesome, since it's just a single question, instead of multiple web searches. I have zero experience with all of them. I know of Jonathan Blow's language, and it gives me interest, but in realistic terms -- I am just a creator of mathematical/logical art, and computers and languages are just a tool. I love programming, I love math, both just for doing logic -- so I am not ignoring their intrinsic value. But for producing a product, you have to view them as tools, to make your own tools, to make your own products.

$25,000 you meant? So those are fines and I wonder who is paying the $150M?

@@Xonatron yes, $25k. I fixed it. The Wikipedia page on the accident has some details but not much. It links to references.

Thanks, Duality. A.I. is used really loosely here... basically it's the idea of the core concept of the algorithm itself, which is mimicking how a human would "design" something they are drawing or "rendering"... which is: If you were painting such a design, for a texture or a level design, or combination, you are using what's already drawn to better drive forward the design further. The stuff that naturally (is most easily added) is what you can do first -- in some sense, this is how a partial design can "design itself". The algorithm follows this. There is randomness for sure, just as in natural design, and there is inspiration from the seeded image, but the flow of creation is all about taking the part that is most "solid" (or least variable) given its possibilities, and it attacks and settles that part first. In this sense, given it is mimicking the way a human would do it, it's A.I. However, given people don't think calculators or chess engines are A.I. (at least not today), I doubt anyone would agree with me... even though this algorithm it is very human like. That's a long way of saying "it's not A.I.". Or maybe I should have said "the A.I. is in the algorithm". ;)

Once I have a few more components made in Xona System 8, I should be able to support the many "sub-engines" that we have made -- 3D raycast, Pseudo 3D road, 2D tile based parallax scrollers, voxel terrain -- and the "non-engine" (simply an arena). I was actually thinking about programming "The Attack" as a game module, to then be used by both the 2D tile and 3D raycast engine; it would be kind of neat to show off how the engine (and the game itself) can be used for two different renderers.

I was thinking the same re: 4K. I'll have to start using my 4K monitor to output from my laptop, just to upload in 4K. Some of my 1920x1080 uploads have never happened since I know the quality is just going to be bad with UA-cam compression (see the 3D Polygon engine for an exactly -- BTW, that's another "sub-engine" that could be supported).

I supposed I could upscale the recorded 1920x1080 videos -- I used OBS Studio & VirtualDub2 to do this with the Test Drive recordings, but it ruined the video & audio sync. I believe what I've noticed is that any large audio gap ends up being cut out -- which is just weird. I didn't notice until after the uploads. Every one of them has that problem.

@@JDoucette I have done it with recordings of Quake, and it maintained the pixels from the original recording (which is compressed) maintaining the pixels. I'll post a link next comment in case spam filter catches it.

Yeah, it reminds me of the old aqueduct systems!

Ha ha, I can hear the commercial now!! :D

Hey Eric. Thanks for taking a look. Once I understood the limitations of this algorithm, after testing many textures -- limitations due to the restrictions of the rules, in how it is never allowed to break them for even a single pixel (perhaps something that could be altered!) -- I started looking for NES game textures that would have a better chance at producing something nice -- figuring their limited color palette would give the algorithm freedom. Procedural texture generation was this project's original goal. That texture you like is from an NES game, Darkman.

Level design is one of WFC's ideal usages... and it doesn't even have to be that complicated. You can make the input texture a few colors, and then let it spit something out, then you can do a 2nd pass yourself to turn the result into the level you want. In other words, let the algorithm do the high level design, and then handle the details (or even fix-ups) yourself! I wish you luck on your game... if you make any progress on it, I'd love to see it.

Certainly! They are all from the original Nova Logic games that used their VoxelSpace algorithm. So that's a good term to search for others doing similar work. Some of the maps are available from the page: s-macke VoxelSpace.

Please let me know what you end up with. I'd love to see your progress.

I think I understand -- so the void filling in your case may just be forest and trees, but not roads. Where it is filling the emptiness of an image that is mostly filled with pre-drawn roads.

The main reason I programmed this was I thought it could provide me a way to generate tiled textures that wrap correctly -- not just one texture to itself, but to various texture tiles. If you see my platformer game videos, some of the newer art has multiple square textures drawn at random, and they all match each other, regardless of how they are placed. This is quite a limitation. I had to do that by hand... so I wanted an algorithm to help me. While I never got that far, the idea was to seed it with the edges, and let it fill the insides.

Oh wow. Interesting thought! If we split up music into separate tracks, and deal with each one individually (just for simplicity), then we have a 1D Wave Function Collapse, which is essentially just what note can follow others. But the 1D pattern to match can be large -- just like the 2x2 or 3x3 or 4x4 patterns I showcase -- so it can enforce several prior notes enforce a limit of what can follow. Maybe this is enough to possibly compose a decent riff?

If we added the other tracks, with additional rules, we'll have 2D Wave Function Collapse. This can enforce the various tracks are still in sync. Maybe this second dimension has to be less like space, and more like multi-dimensional -- since you sort of want every track to be aware of every other one... I guess that could be done with simple 2D, as long as the pattern is enough to cover all -- but you may want those track interactions to be less dependent on each other.

Thanks for the kind words. Because these are pixel fonts, they are stored as basic PNG files, which are non-lossy (exactly / accurately stored). The visible pixels are RGBA = 255, 255,255,255 and the empty pixels are 0,0,0,0. This way I can load them directly in my texture system in my engine (Xona System 8, which is based on the MonoGame framework, based on XNA), and render them exactly as is. This also allows me to make anti-aliased fonts simply by drawing see-through pixels, like RGBA = 255,255,255,127, for 50% alpha (127/255).

This spawned from me being annoyed at a single pixel spacing of my smaller fonts, such as "LY" not fitting together, and some numbers like "17". Now, it works for all of the nice expected things as you mentioned -- italics, serif, and even exotic mixtures of symbols and letters.

I immediately ran into problems -- symbols creeping too far in (like a period hiding completely under "T.". So I disallow any character from being 100% enclosed in another; it will always peak out at least 1 pixel. Further, I look 2 characters behind, to make sure T Period Quote --> T." don't overlap, where the period isn't large enough to separate the T and the quote.

You are correct - the algorithm is basically NxN compares, and it ensures whatever pokes into another character has no overlap, and no pixels touching, as it protrude inward. Since my fonts are PNG format, I could use an unseeable color like RGBA = 1,1,1,1 (out of 0..255) for the "do not enter", but I've found this unnecessary. However, I do notice that the kerning is aggressive in minimizing space. This is fine for small pixel fonts, but once they get larger, I feel it's too aggressive at times.

P.s. I would love to see your collection. Anywhere you have it on display? I've been trying to think how I can showcase my fonts. Blog? Instagram? Maybe a custom channel just for fonts? I have about 50 made. I'd say most are amateur. None get into any exotic. Simplicity and readability for retro style games are my thing.

​@@JDoucette You've got a nice selection and artistic style. I've read that some of the fonts you didn't make yourself. I can recognize the Heretic/Hexen font, maybe a few others I can't remember what game they were taken from. Whether they are amateurish or not also depends on the character repertoire. If you decide to include upper and lower case letters, ligatures and diacritics, support ISO, VGA or some other codepage that is a superset to ASCII, this can put your fonts to another level.