Game Creation/Design Catch All

This may be of interest to some of you. Brian Karis, one of the lead developers of Unreal Engine 5, does a deep dive into the details of how the new "Nanite" rendering engine gives UE5 its incredible performance, smoothly rendering meshes with billions of triangles in real time on consumer grade hardware. Be warned that this is a highly technical discussion; you will need to be familiar with a lot of the principles of 3D graphics programming to understand it. But if you are, it's a fascinating look at the gory details of the most advanced rendering engine currently in existence.

It turns out there isn't a single huge quantum jump breakthrough concept that suddenly made everything orders of magnitude faster. It's actually a fairly conventional rendering pipeline, at least when seen at a high level. It's so much more efficient than others mainly because they put a lot of effort into optimising the shizzle out of every step in the pipeline.

One of the biggest improvements, though, was one of the simplest: pure GPU rendering. Most rendering pipelines, when you look at the whole "mesh stored in memory => pixels on the screen" process, split work between GPU and CPU, making the channel between the two a bottleneck. Nanite finally manages to put everything on the GPU, eliminating a significant source of delay in traditional rendering pipelines.

He's also quite honest about the areas where it still needs work (though this merely means "only works as well as anyone else's engine"), mainly in dynamic geometry (especially skeletal animation with skin deformation) and geometry with a lot of holes in it (e.g. grass and leaves). They're working on these and expect further improvements.

Thanks for posting the video, I love learning about these details with graphics and rendering! I attended siggraph this year but missed this session and never went back to it. I'll definitely be watching it now.

I forgot this idea completely but was describing my current game I’ve been working on with friends and they asked me to explain it in a way they could relate. I chose chess which helped a bunch. This old idea came back to me.

Anyway the idea is to imagine chess not as a grid of squares but as boxes. The boxes are stacked 8 high and 8 across. Moving up is the same as moving forward on the board. Moving down is the same as moving back. At every level pieces can move back or forward as normal. Though I think I opted for piece promotion to require the upper/lower starting squares. Though thinking about being able to zip across on any level to promote a pawn could make for a real crazy game.

One side of pieces starts on the bottom board and the other starts opposite on top board.

So like a pawn could move across as normal but now could also move up one or attack up left/right. I recall there being an issue with queen/bishops being able to capture from the get go diagonally up/down. So I added more pawns on the upper/lower rows for a total of 24 pawns.

My dad had a chess book that had a Japanese version of chess with samurai type pieces that moved way different. I think they also got promoted when they passed the middle of the board. They were going to be my other options if the extra pawns didn’t work.

I made a physical board way back in the day and it was ridiculous how tall it was. You had to have room to reach in with your hand to grab and move pieces. So it was like 4 inches between layers, so just shy of 3 feet.

Anyway I sat on this for some 20+ years now and can’t believe I forgot it. So just posting it out there for whoever thinks they can run with it. I should probably google and see if some has done it already?

Seems some have gotten close.

Oh it was done in 1851… Nevermind lol!

Got some placeholder sound effects and music going. Over halfway through the backgrounds for the first world (6/10). Quickly approaching a release of a public demo.

Programming when tired is a bad idea. I have spent hours trying to figure out a way to scale the damage an object does based on it's size so that at 2x the size it does 1/2 the damage and at 1/2 the size it does 2x the damage. The formula is base damage divided by current size.


Just my approach, but when I'm having trouble making two things relate the way I want, I often find there's a third implied value that I'm not stating.

E.g. here, if the idea is that dangerous enemies are both smaller and more damaging, one approach would be to give each enemy a "dangerousness" value, and then set damage = X * dangerousness, and size = Y / dangerousness.

This was more of a lesson to myself not to try going home and programming after a 12 hour work day.

It is an energy wave weapon for the player that starts out scaled down to a size of .5 (about 8 pixels across) and expands as it travels to a max of about 4x thus becoming more diffuse and doing less damage but over a wider area. The idea reminded me of the inverse square law (which I remember from my days as a photographer) so that sent me down a couple of calculus rabbit holes that were close but not quite right. The inverse square function itself provides the correct answer for some values (.5 and 1), which I think caused the idea that it needed to be a more complex math function to get stuck in my brain.

After a good period of no progress at all, I finally sat down this morning to work on my turn-based beach soccer game, and I am happy to report that I made some good progress on the game's camera! I have been able to build a test scene where it's possible to rotate, zoom, and translate the camera (although the translation still needs to be tested), using a controller, all in isometric glory.

I'm done for today, and tomorrow I will incorporate this new camera into the actual soccer pitch scene I built last fall. If all goes well, I think I can get player movement done this week.

My current plan is to build a game that has maybe two matches, with some narrative scenes between them, and release that on for a dollar or two within the next six months (although if I do find a job those estimates will move around).

^Nice work! I've dug back in this year as well, hacking away at an RPG tutorial, trying to make things a daily habit again. It's been really fun to get back into this.


I like the new perspective, but this highlights 3 issues:

  • I will need to have sprites facing in diagonal directions. For characters that appear outside of matches, I will have to do 8 directions for the idle and walking animations.
  • The stats window needs to be on the side
  • I have an idea of what I want the matches to look like, and I will need to learn Blender properly to get the result that I want.

Adding the ability to move a player around the pitch is my goal for this week, and make sure the player can zoom and rotate the camera. At the moment, it's just a looped animation where the focus moves from one player to the next, ignoring user input.

If this goes well, I may have time to rework my locker room scene to use the same camera and overhead perspective this week as well.

Next week, I think I will want to have a basic concept drawing of what I want the matches to look like, come up with a list of all the animations I will need for the players while they're on the field, and maybe create a template in Aseprite that I can use for each different sprite.

Go go go bobbywatson!
You definitely have something unique going on. You never know where it might lead...

Quick progress update:

  • It is now possible to set the destination target of a playable character. This turned out to be much easier than I thought it was, it turns out Godot has some some simple ways of accomplishing this
  • Calculating the distance between the player and the target was also pretty easy, thanks to some methods on the Vector3 class
  • Made the stats screen vertical and moved it to the left of the screen. I still need to figure out how the containers work, because each time I play with them, I manage to f*ck everything up somehow
  • Ran into some issues with my collision shapes that made some areas of the soccer field unreachable, which I managed to fix relatively quickly.

The goal for tomorrow is to clamp the distance to the playable character's range, and the move the character to the destination. I also need to test to make sure it is still possible to rotate and zoom the camera, but only when the player is in control.

Just wanted to chime in and say Shmup Creator has finally been released! I have been waiting for this for probably over a year.
It does not disappoint so far. I think the only feature I don't see is Point Click movement. (which sucks because that is what I planned to use for several ideas, since twin stick is too twitchy for my plans)
But it has all sorts of presets for bullet hell and player weapons and particle effects. (physics too)
It had both 2D and 3D and has horizontal or vertical scrolling camera presets. (almost 100% you can do camera follows player as well)

The tutorials are smart and get you up to speed quickly by giving you only what you need to know and then letting you experiment.

So I am really hopeful and can't wait to play with this some more!
It is trigger based so no coding:

Unreal 5.0 released

Way too cool: Making your own procedural primitives with blueprints in UE5:

Humble Bundle with UE5 + blueprints training:

More UE5.
You can now model like minecraft in UE5:

Meanwhile, over in the Unity camp, some bad news: Unity have just announced several hundred layoffs, mostly from their development staff. This came despite CEO John Riccitiello assuring everyone only two weeks ago that no layoffs were planned. That would be the same John Riccitiello who was CEO of Electronic Arts when it was voted Worst Company in America two years running.

Report from Kotaku

Report from Gamefromscratch

Yeah, I may have picked a good time to start learning Unreal Engine.

Why anyone would hire any ex EA CEO let alone Riccitiello is bonkers.

And why did Unity IPO? I mean sure it looked like it made some people a lot of money a couple of times over the last 2 years but how many billions does Epic have without one?

And then buying WETA and Parsec? How idiotic. There is no way you are going to catch Unreal for virtual set creation. (especially with UE 5) And the only reason to buy Parsec seems like you want to make a stadia clone? Really?

I'm doing some first post cleanup, in case you all see the notifications

Lists cleaned up. Removed some dead links, at least one problematic link, updated some of the descriptions.

Unity IPOed because the investors wanted an exit. Unity has apparently made a loss every year of its existence. When they took VC money the play was to continue growing revenue until they could pivot to profitability. They have finally hit that number.

Unreal is different because the games they work on and release pay for the engine development and the licensing fees from third parties are all just gravy. It’s why Unreal is so cheap and it undermines Unity’s business.

If Unity charged what it cost to develop the engine, they would lose share to Unreal,Godot and writing your own engine. So all the acquisitions have been about trying to have an ecosystem of services around the engine they can charge for.


fangblackbone wrote:


Generally if the VC aren’t seeing the numbers get good enough fast enough they will bring in an outside CEO to juice the numbers. John Riccitiello is an understandable choice in that context. He’s got lots of financial connections with investment funds willing to invest in games companies. There aren’t many people with his statue with feet in both video game and Wall Street worlds. Not who you’d choose for a long term sustainable company but if Unity wanted that they wouldn’t have been running at a loss all these years.

For a moment I was about to say it's weird that a development tool could be so popular and still not make money, and then I started thinking about Flash.

Flash didn't make money? Wow!

Do you mind elaborating? I always assumed Flash was a foundational technology for the Dreamweaver and other Macromedia (and then Adobe) products? I don’t think the browser plug-in was super expensive to develop and everything that could officially produce SWF files was so expensive.

Ah, I don't know all the details and there were probably some periods where Flash was paying for itself, especially early on. But basically, (a) the authoring tool was hugely pirated, and (b) the browser plugin was waay more expensive than you might think. The player ran on literally hundreds of different platforms, and it ran pretty much identically on all of them because there was a massive amount of conformance testing and QA behind the scenes. Plus the core engineering, all the security work, all the sales and bizdev people who got it onto hundreds of platforms in the first place, etc.

Makes sense. Dreamweaver seemed to be everywhere in like 2002, and then Web2.0 happened and every corporate/enterprise company moved on to Rails or Django or whatever Javascript flavour of the month. I assumed that those huge enterprise license fees were what paid for flash.