u/deftware

I knew a guy named Michael Moore.

The famous Michael Moore guy was more famous 20 years ago, back in the Fahrenheit 9/11 days.

Acquisition of new gear and learning how to use it is the way, if the goal is eliminating a skill tree and leveling system in favor of organic dynamic skill progression. You also would want to allow carrying only so much gear - so if you ditch your crossbow for a longbow then you will have to learn how to use the longbow and no longer can just bust out your crossbow that you've practiced so heavily. The mechanics of using things in the game would need to be different and more complex than just pushing a button, which on a keyboard/mouse or gamepad usually ends up devolving into the player pushing some combination of buttons and drawing shapes and things, like the button combo moves in a 1v1 fighting game.

The hard part is designing and implementing all of the things that a player can discover and use, and creating the mechanics of using the things they find/earn/craft/trade/etc.

Just because you have a lockpick set doesn't make you able to pick a lock. Just because you have a gun doesn't mean you know how to shoot it - or shoot it without hurting yourself. Having a bunch of gold means you're not sprinting around so much anymore, and are a target for being robbed.

Mechanics will have to go much deeper than what conventional games typically go for (which is why they're all so boring most of the time nowadays). What you're talking about is something more like a simulation. VR lends itself well to creating games that require actually becoming good at specific skills inside of simulations, because it's hard to create more involved skills for players to learn that don't end up just being button presses and whirling the thumbstick or mouse around in different patterns. It's totally doable to make a bunch of minigames/mechanics for everything, it's just hard because of the sheer volume of designwork entailed. It requires creativity, and persistence/commitment.

Good luck!

Naive children hating their own country that they take for granted - even though people the world over are literally dying to get in.

That is doable, I just don't have a simple way handy for coding up the math and then getting an image as output. That would be a nice tool to create - maybe something I should have claude slop up as a webGL/JS thing?

EDIT: So, yeah, I draw up the concepts in GIMP because they parallel what can be coded - GIMP's various features/functions are just code operations on pixel data too, at the end of the day... so it makes a great way to convey graphics coding concepts via illustration.

You can just make images like that in any competent image editor. I used GIMP to make the ones I put on imgur there.

Ah, so probably the easiest thing to do is use voronoi noise where the cells of the voronoi exactly map to the world cells, and then pile on the fractal noise on top of that. You can then modify the heightmap of the cells that are neighbored by flat cells to blend into the flatness of the cell.

So basically, to do the voronoi noise, you would pick a random point offset from the center of the cell using polar coordinates. That is the peak of your mountain shape. Then subdivide quadtree style, and pick random points inside each child cell, those are sub-peaks, and subdivide down however many levels you want. What you're doing is summing up the proximity to these points, scaled by which subdivision level you're at. So at the mountain peak cell-wide scale you pick a point and its height contribution is 0.5, where all of the pixels in the heightmap are set to a height between 0.5 and 0.0 depending on their distance from the peak. Then for the four subdivided child cells each sub-peak's contributing to the heightmap is scaled to 0.25. You keep subdividing down, halving the height contribution the peaks have. That's essentially a fractal noise. This will give you the mountainous look you're going for. (edit: I forgot to mention here that you should also halve the radius of a point's influence on the heightmap, so where the peak's point has a radius of influence equal to the width of the cell, the sub-peak points have a radius of influence that's half the width of the cell, etc... just subdividing the radius of influence and the heightmap contribution it adds each level you subdivide down, quad-tree style)

For neighboring mountain cells you'll want to keep track of the points that were used to generate their heightmaps, so that they can bleed into eachother - this means that when generating a heightmap use a pseudorandom number generator that's seeded with a global world seed and then add the cell coordinates to randomize it some based on each cell. This will allow you to re-create the 8 neighboring cells' points' contribution to the current cell's heightmap and have it all line up nice. When you're generating a heightmap, you're really generating points for a 3x3 grid of 9 cells, only calculating how all of the points contribute to the center cell's heightmap.

Then for flat cell neighbors you just modulate down the heightmap with a gradient on the edges shared with flat neighbors - when a cell changes from a flat cell to a mountain cell you just recalculate the heightmap for the whole 3x3 area surrounding the cell.

This is all simple easy stuff - you're just using simple geometry and calculating pixel values based on some rules. If you've never done anything like it before you should check out shadertoy and get crazy with it. You can prototype all kinds of stuff on there and learn a lot of tricks for things.

Also, check out iquilezles.org for some more computational graphics programming inspiration. Cheers! :]

Regular old fashioned fractal noise does just fine.

There are other fun things you can do as well if you want to go for a more nuanced aesthetic: https://youtu.be/gsJHzBTPG0Y

Are you talking about determining which cells should be mountain vs which cells should be flat? Or are you talking about generating the actual heightmap inside the mountain cells?

That's super simple. Just generate some fractal noise, blur it, and then threshold it.

You can also manipulate the levels a bit to get more concentric patterns, like that ringed area in there, by passing the blurred noise through a sin(), or abs(2v-1)

Here, I fiddled around in GIMP to show you the concept: https://imgur.com/a/Vf1xAPP

Feel free to share any questions you might have :]

Download Godot and look up some Godot tutorials. It's going to be the most straightforward and least fussy premade game-making-kit style engine you'll find.

Otherwise, download TIC80 and start making little 8-bit games on there - learn about logic concepts like variables, loops, conditional logic, etc, then go back to something like Godot if you want to break out of the 8-bit console style stuff. At the end of the day, much of the concepts you'll learn on an old-fashioned thing like TIC80 still apply today, at the heart of everything.

Game engines are designed to be able to do a lot of different things, and most games only use a small fraction of all of the capabilities of an engine. A small platformer is going to use ~5% of what Godot can do, and it's perfectly up to the task.

Not relying on the government to sustain their existence or give them a reason for existing.

Duke Nukem 3D, in particular, because of its Build engine's map editor. Then I got into modding Quake, everything that could be changed was something I learned how to change, 25+ years ago. Doom was a bit trickier because only graphics/maps were external to the game binary itself, which contained hard-coded entity types and their logic/behavior. Quake made all of that fully exposed so you could just go in and mess with all of it, which was super innovative and forward-thinking.

I started coding in qbasic when I was single-digit years old, making little games with that back in the mid-90s.

Yeah, combat over an unpredictable network is going to be the most challenging to engineer. At the heart of the issue is that you have multiple systems attempting to show one consistent simulation or game state, but the reality is that there is an unavoidable delay in transmission of state between systems, so everyone is always seeing what was happening instead of what is happening. Any player inputs either directly impact game state and those changes are broadcast to other players (i.e. directly in a p2p fashion, or relayed via a central server). Elsewise, you have player inputs being transmitted to a single authoritative simulation - which means delay in the effect those impart on the game state, and then the delay of the game state being transmitted to other players.

The simplest thing to do is have player inputs directly affect the local simulation, but the inbound state received from the game server overrides it - which is tricky because the server is always sending what is old state for the client.

Aside from dealing with all of the lag mitigation stuff, you also have optimization of the data actually being transmitted. TCP is basically never to be used for any kind of real time combat game. What you want is to separate continuous game state where it's tolerable for data to get lost in transmission, as long as the latest state arrives often enough for the smooth evolution of the game state. Then you want reliable transmission of discrete events (i.e. creation/destruction of things, messages, sound playing events, etc). Quake3 had a great approach for this. Basically, you just send out UDP packets at regular intervals (i.e. 60hz) that contain two sections of data: reliably-transmitted state and unreliably continuous state. The reliable section contains all of the unacknowledged discrete events, where each event that's included in an outgoing packet gets an ID number and the receiving end sends back packets that include the last received inbound event ID, an acknowledgement of event receipt (aka an "ack"). This does mean that the receiving end will receive duplicate events, but it will know to ignore ones it has already seen because their ID is less than or equal to the newest one it's seen, and the mechanism ensures that events make it across the network. The unreliable section of the packet just contains things like player button states, and whatever entity state that is constantly changing, like position/velocity/orientation/etc. This is the stuff that just gets encoded into the packet and can get lost here and there, because all we want is the most recent data.

Then you have encoding continuous state, such as position/velocity/orientation. The more entity state that one packet must convey, the more important it is to pack things down as hard as you can. An orientation, for example, can be halved in size by bit-packing 32-bit floating point values into 16-bits each, but you'll want to make sure that the quantization doesn't adversely affect the simulation occuring on the receiving end.

Lastly, there's compressing the packet as a whole. A lot of engines used static Huffman encoding for a long time but I had heard of Asymmetric Numeral Systems back in 2014 and implemented my own finite state entropy encoder using dude's original paper. It achieves the compression of arithmetic/range encoding, with static Huffman speed. The trick, however, is getting a good accurate sample of real network data from your game and using that to build your symbol frequency table.

Anyway, hopefully I'm not telling you a bunch of stuff you already know. My apologies if I have! Hopefully there was at least something in there worthwhile for you :]

Multiplayer is just more involved on the whole, there is a lot more going on - particularly in competitive games where authority and ordering of events is more sensitive (i.e. dying from being shot after taking cover vs your shots not landing and having any effect just because someone ran behind cover after shooting them, AKA "favor-the-shooter vs favor-the-target").

Things like client-side prediction, interpolation, and lag-compensation techniques (game state rewinding/replaying) are only warranted for certain types of gameplay, but they can be a real engineering challenge.

The only reason I can imagine anyone would say to avoid PvP as an indie dev is just because it involves quite a bit more engineering than SP gamedev does. Not only must your game's networking be functional, but it also must be decent enough to not ruin the gameplay.

Multiplayer is basically a project unto itself. It's doable, just not for the feint of heart. I would recommend against tackling it for a first game project, without having any existing experience making games. Make some stuff and then start investigating what actually goes into multiplayer games and decide for yourself if it's something you feel capable of.

At the end of the day, if your game is fun and popular, it's going to get hacked and people will cheat. While that will ruin the game for your honest players, it can be taken as a compliment that someone felt like your game was fun enough that they wanted to take the time to develop the means of having an unfair advantage.

Anyway, that's my two cents. Good luck! :]

If you click where it says "44% Memory" you can sort all of the processes by how much RAM they're using, and see what's actually using RAM. If none of the visible processes are accounting for 11GB missing then you could have a more serious issue involving malware.

Or, you have a CPU/GPU that are sharing RAM, and the GPU's share is being counted against your total RAM usage, rather than as its own share (i.e. 8GB CPU RAM + 8GB GPU RAM, or 12GB CPU + 4GB GPU, etc)

A popular YouTube channel by the name of Brackeys has made a zillion Unity tutorials, then he "retired".

After the Unity greed debacle, he came out of retirement, to make Godot tutorials.

That should be all you need to know about which engine to use.

Godot is on an exponentially increasing usage curve, because it's so easy and intuitive to use, and has amassed tons of great features and functionality over the last few years that should cover what 95% of devs want to be able to use.

It's not bloated and slow like the ancient engines, and there are templates for releasing on all kinds of platforms, including HTML.

The choice is clear, if you ask me. The only people who argue against it are ingrained in Unity and are biased. I have been a hobby gamedev programming everything from scratch for 25+ years, and I went out and surveyed all of the available engines myself. Unreal was HUGE and alienating, it has a pretty gnarly learning curve as well. Unity was more friendly, but the bloat was real. Godot I was just able to hit the ground running, everything just made sense, it didn't feel like a bunch of afterthoughts hacked together into a layercake (which is also the problem with webstack dev these days).

Yeah, if I was starting from zero and just wanted to start making things, I would use Godot. It's compact, lightweight, efficient, capable, and FOSS - you can actively participate in its development. If there's an issue or a bug, go post it on the project's github repo, and someone will likely get to it if it's something that others are also seeing and that shouldn't be happening.

Anyway, that's my two cents. Watch out for the Godot-haters that have never used anything but Unity/Unreal!

Can I ask when the last time was that you personally looked at Godot for yourself, and actually did something with it?

Anyone else have their ticker watchlist widget suddenly stop working in the middle of the market taking a dump?

Make a simulation of some kind. You'll learn math, optimization, DSA, etc... Can't go wrong!

What would be really cool is a new platform for distributed compute, something like folding@home or SETI@home, or Electric Sheep, but that's designed for general purpose compute. Back it with whatever hardware the user has, and have a server where compute projects can be registered, audited, and have compute contributed to their cause.

Cheers! :]

I used CodeBlocks for the last decade or so, and just switched to Zed. I wish I had Zed 20 years ago. It has some newer AI capabilities and stuff that you can shut off, or use an AI-free version that someone released, I forget what that project is called though.

You'll have to learn how to manage your projects without a "project" like the IDEs have for you (cmake, etc).

Yeah, they need to get on the instancing, get off the deferred rendering and onto good old fashioned forward rendering, and optimize their geometry a bit - at least have a slider for users or a high/low geometry mode. Tons of opportunities to optimize things. They could probably tighten up their shaders too, and instead of having one shader per material re-use the same shader across many materials where the only different is what textures they're using. A lot of these prefabbed game engines default to creating a new shader program per material, and it's horrifying. Switching shader pipeline isn't nearly as expensive as it used to be but it's not free - and it results in modern games having shader compilation stutters out the wazoo when there are a lot of materials.

Cheers! :]

The doctor is in. :]

A game like this should be forward-rendered unless you have an explicit need for deferred lighting (many objects, many lights, not much blended geometry, and large scene depth variance like a perspective-projected first-person game). Because you're using deferred rendering/lighting you're drawing each object three times right now: a depth pre-pass, a normals pass, and then a diffuse pass. This wouldn't be a huge problem for such a game except that...

I'm not seeing that you're leveraging instanced rendering anywhere at all, even though you're drawing the same geometry multiple times - just at a different position with different materials applied - that's a perfect use case for instanced rendering. All draws that are of the same geometry should be aggregated into a single draw call each, with information about each instance stored in a buffer that gets updated as needed.

And then for what your draws actually entail they have WAY more geometry than they actually need. 600 vertices for a single card? Have you tried getting that down at all? If that's because of some 3D geometry on the back of the cards then only draw that when the back of the card is actually visible, not while the card is face-up and not doing anything. When it's face-up draw a single quad. Looking at the normals pass they look like flat rectangles, which should be doable with two triangles, not hundreds. Do a geometry decimation pass over all of your assets because they have way too many triangles and vertices for what they actually are. A lot of the little icons and decorative elements could just be normal-mapped quads with alpha-tested cutouts rather than dozens or hundreds of vertices each and bunches of triangles, and it could all be drawn using instancing - meaning one draw call for all of them. Anything that has the same triangles and vertices as something else should be drawn using instancing, using the instance ID to retrieve per-object input like transform/material/etc from a buffer you update as-needed.

One idea is to cache the static parts of the scene: draw everything in all its glory to depth/normals/diffuse and as long as nothing moves just re-use that to refresh the frame. Draw all of your lighting and particles on top of that until something actually moves. You can break this up into cached groups and composite them together, re-drawing only the individual group when something in it moves. The whole desk/table scene could just be a static depth/normals/diffuse set of images as long as it doesn't move, and you just draw that over the whole framebuffer, one quad to replace all of those little individual draw calls.

You can also combine all of the background/scene geometry into a single mesh, anything that doesn't move on its own should be merged into the other geometry there. The table and all of the other trinkets and things everywhere - that should all be one single draw call for the whole model, not many individual models. They also could stand to see a decimation pass themselves.

Forward rendering will instantly divide your vertex throughput by 3. Instanced rendering looks like it will give you an average of ~75% fewer draw calls on the whole. Then draw all of your opaque geometry in near-to-far order with depth-testing enabled, and then all of your transparent/particle effects on top in far-to-near order. You should see a huge performance jump.

Don't hesitate to ask any questions you may have, and good luck! :]

I don't think it's a shortage so much as it's going out of business and not restocking, or the manager isn't restocking, there's a number of things that could prevent restocking that aren't the result of a shortage :P

Anyway, thanks for thinking to share here :D

Pay someone to market all of my skills and projects for me.