/games/ - Games

>>40774
>you're going to use a preexisting graphics engine instead of developing one yourself because that would be pointless
I shouldn't even say that, you could possibly develop some performance saving tricks with enough ingenuity, but these are all incremental changes, upon the work everyone else already deved for you.

>>40774
>It's a lot of advanced trigonometry,
But you're going to have to start understanding trigonometry if you want to program anything in 3D space. Vector math baby.

>This is thread is only for people who have deved something. Don't post in this thread if you're just an idea bro who has never deved anything in their life.
<I'd ammend the statement to say that inquiries into gamedev are fine. No one wants to hear your ideas though unless you are determined to invest the time and effort into making them a reality
Ok so I'm going to put my money where my mouth is.
This is some preliminary work I did years ago in effort to make an action shooter like RE4 and 5 and etc. Only really similar thing is the camera motion for aiming. I have it that you are in a parallel chase cam by default, then when you aim, the camera flies over the right shoulder to give you an aim view which is still 3rd person. Also when you enter aim mode, it cancels sprint mode and the most you can do is fast walk.

I created multiple walk modes. Default walk, jog speed, then sprint speed. When you double tap shift you get sprint speed. How much different speeds deplete your stamina, which is the second bar from the top which fills out on both sides, is dependent on the angle you are walking. On a perfectly horizontal plane, walking refills your stamina, jogging keeps your stamina constant, neither refilling or depleting it, and sprinting depletes your stamina. All of these numbers are multipled or divided by the angle you are going. If you are going uphill it is multipled, so even jogging depletes your stamina, if you're going downhill, even sprinting can keep your stamina constant.

I also programmed in fall damage but no point in showing that. Every game has that.

So yeah this is all mechanics I programmed from scratch in a couple days. It's not too hard at all. It's just basic logic. I did this all in blueprints./

>>40777
That blue debug sphere shows the characters center of gravity. I did that by getting all the joint locations, then averaging between each joint to get the center of each limb, then I looked up the mass ratios for limbs, then I weighted each location by the mass ratio and found a dynamic center of gravity for no matter what pose the skeleton is in.

Past that I didn't do anything with it, but I have some ideas.

>>40778
I mean like each section of limbs etc. Divided out into torso, pelvis, upper arm, lower arm, head, upper leg, lower leg, etc.

Also I programmed it so the camera is locked to a front facing 180 semi-circle( a little over) to represent the range of motion of the head. I was working on making the head move in alignment with the camera. I can't remember if I programmed that you transition to aim mode by how off center the camera is from your view point.

Oops forgot to say as well. You have tank controls(the mouse moves only the camera and you keep running in the direction you are running while pressing the forward button unless you press left or right in the left hand, A and D) when you're in run mode, then transition to regular forward backward strafe(in the left hand, A and D) controls while aiming.

I remember making a way to double tap the sprint than backwards to do a quick 180, but it doesn't seem to be working.

What kind of topology works best for a character that has full human range of motion and would be very active, doing the typical sort of moves you'd find in action games like, climbing, jumping tumbling, etc?

Currently using vidrel as reference for main face loops on the body (will be adding addition ones around joints for more accurate/efficient deformation there.

>>40789
Woo you picked a hard topic. Just reminded me I was working on a universal base mesh. It depends how high poly you want to go. All the advice I've seen is don't worry about polycounts so much. I'm not done with it yet. I just got down to starting to work on the feet and there's a lot of shit I should probably fix.

Basically the ideal is to keep everything a square grid, because that's how things divide. But you're going to need to create intersections where five squares meet sometimes. This is how edge loops are formed. Edge loops are nice to separate different areas on the mesh for sculpting as well.

So where do we need polygons? We need them in areas that deform especially like you said. But we also need them in an area that is going to be highly curved as well. You can use normal mapping to make the blocky polygons look rounded as they're supposed to from head on, think of normal maps like a hologram, but from silouhette, you need the polys unless you want a blocky curve.

This shit looks really high poly but it's only 27k tris right now. That's still pretty low.

No one really suggested this to me, so this may be a dumb idea, I'm trying out tris so I can split an edge into another edge loop so I can add more polys in places where I need it like da booba. I'm planning on using this as a universal base mesh so I definitely wanted more polys to be able to handle even large booba than this.

The part that just fucking pissed the hell out of me is doing the retopo on the under armpits. Also I don't know if my technique is good, but I'm using Houdini for this retopo and they have a smooth tool, and that's kind off how I've been informing my choices is, draw some polygons, hit smooth, see where they go, add more polys until they stay in regions where I need them. The armpits are fucking bastard. In general you want circular edge loops around circular areas, and you can see in that video, that's how he did the booba, but I was finding with my smoothing that was making everything concentrate to the center of the booba. so I instead went with the grid approach. I think that will work better for deformations as well.

You can see with the face and the mouth I went with a circular edge loop around the mouth and eyes.

>>40789
>>40792
Alternatively you could just buy someone elses base mesh and then just wrap it to your sculpt. You're going to be sculpting then wrapping to your universal base mesh. That's how all the AAA studios do it these days. So you might as well just use someone else's topology even.

>>40793
And the number of reasons you want one single base:
>Better for performance
the game only has to load the polys once.
>the rigging and everything is saved between them
>This is how all character customizers work
Is that there is one basemesh, and then their are different deformers you can blend between. You can checkout Daz3D to get more of an idea how that works. You'll see that people sell all kinds of "characters" so to say, but these are all just deformers for the like handful of Daz basemeshes, Genesis3 etc.

>>40778
>That blue debug sphere shows the characters center of gravity. I did that by getting all the joint locations, then averaging between each joint to get the center of each limb, then I looked up the mass ratios for limbs, then I weighted each location by the mass ratio and found a dynamic center of gravity for no matter what pose the skeleton is in.
I know programmers are going to laugh at my spaghetti insanity. And the code is so simple too.

Since this thread is up, I might aswell post some tips given that I actually do have some experience in game development

First off, if you’re going to code movement, never lock the any actions to a specific key or even worse—the frame rate. It’s so easy for developers to attach movement to the game’s updates accidentally instead of an interval and they end up paying the price for it. Even AAA studios fuck up movement by keeping movement actions attached to the frame rate.

To address the “don’t attach movement actions to specific keys” thing is fairly easy. Create a class, array, or a matrix that stores all the potential actions (personally I like to keep the actions stored as Booleans or functions) a character can have. Then whenever the player presses a combination of keys or a key while another action is playing, the game’s avatar will respond by allowing multiple of these actions update and express themselves simultaneously.

In application, movement matrices allow players to move diagonally, have inertia, move while interacting with the game’s menus, and perform complex actions like strafing, reloading with a gun while sprinting, or riding vehicles.

I’ll also throw in this idea. You know how in online games where if your ping is garbage you’ll frequently find yourself “teleporting?” The thing that causes this effect is the game’s tick rate being responsible for the physics instead of the frame rate. This means that if your game is experiencing lag or if your frame rate tanks, you can expect that your character will still move around the way they should if your game was running normally.

In fact, teleportation during moments of lag in gaming is a sign that the game is running properly.

>>40807
The second and last thing I’ll post about is fall prevention.

In games, falling is generally obnoxious and is a common problem in nearly all indie games I’ve found. I think it’s inappropriate in games not explicitly designed for platforming. If you’re designing any game with a jump mechanic or some form of platforming, make sure that you put up guard rails and that you walk off cliffs.

For additional interventions in designing your levels, make sure that any flat inclines are turned into staircases so that if your character ragdolls or runs too fast that they won’t like fall off the terrain awkwardly.

>pic rel

>>40807
>Then whenever the player presses a combination of keys or a key while another action is playing, the game’s avatar will respond by allowing multiple of these actions update and express themselves simultaneously.
I don't follow what you're saying. I don't see how that has anything to do with input actions. Yes you don't hard tie inputs to specific keys because you want them to be reprogrammable.

>(personally I like to keep the actions stored as Booleans or functions)
Input action functions are dependant on the kind of input action. For example, a joystick will update every tick for the value it's being held to, whereas buttons fire once per press. Mouse axis input fires every time the mouse data is updated, dependent on the hertz rate on your mouse.

>In application, movement matrices allow players to move diagonally, have inertia, move while interacting with the game’s menus, and perform complex actions like strafing, reloading with a gun while sprinting, or riding vehicles.
For movement you want a 3dvector for 3d movement or a 2d vector for 2d movement, then the rest of that are just variables. They're not all in an array together.

>First off, if you’re going to code movement, never lock the any actions to a specific key or even worse—the frame rate. It’s so easy for developers to attach movement to the game’s updates accidentally instead of an interval and they end up paying the price for it. Even AAA studios fuck up movement by keeping movement actions attached to the frame rate.
The tick is the framerate.

<"Ticking" refers to running a piece of code or Blueprint script on an actor or component at regular intervals, usually once per frame. Understanding the order in which your game's actors and components tick relative to each other and other per-frame tasks performed by the engine is essential to avoid off-by-one frame issues, as well as to ensure consistency in the way your game runs. Actors and components can be set up to tick each frame, at set minimum time intervals, or not at all. In addition, they can be grouped together at different phases in the engine's per-frame update loop, and can be individually instructed to wait for specific ticks to complete before beginning.

The way Unreal and Unity handle variable frame rates is they have a float variable that updates with each tick that tells you what the frame rate is, then you multiply your variables that you're firing on the tick based on that. So if you want the velocity to be 5 meters a second, at 60 fps, that's .083 meters a second. If the frame rate drops to 30 fps, it will increase the value to .16.

This coding plugin I'm using has an even better method called steady tick.
https://turbanov.ru/wiki/en/toolworks/docs/apparatus/steady-tick

>I’ll also throw in this idea. You know how in online games where if your ping is garbage you’ll frequently find yourself “teleporting?” The thing that causes this effect is the game’s tick rate being responsible for the physics instead of the frame rate. This means that if your game is experiencing lag or if your frame rate tanks, you can expect that your character will still move around the way they should if your game was running normally.
This is about whether movement updates happen client side or server side. It's good too because it prevents cheating. I'll let the AI go more into pros and cons.

>>40811
>In games, falling is generally obnoxious and is a common problem in nearly all indie games I’ve found. I think it’s inappropriate in games not explicitly designed for platforming. If you’re designing any game with a jump mechanic or some form of platforming, make sure that you put up guard rails and that you walk off cliffs.
Unreal has a function in their default character movement component that can prevent you from walking off an object. It flat out detects any ledge, so you have no need to put up invisible walls. It's also dependent on the the height of the ledge so it won't prevent you from walking off a curb for example.

>For additional interventions in designing your levels, make sure that any flat inclines are turned into staircases so that if your character ragdolls or runs too fast that they won’t like fall off the terrain awkwardly.
You can easily program the ragdoll. You can have a physics simulation and control it at the same time. For example if you think the body is falling to far, you can just tell it to apply more friction or even stop all movement of the capsule, which is the actual thing that's moving, it's not running a true sim, it's just simulating the joints.

Another piece of advice about ragdoll, is you can make the joints as stiff or soft as you like, no reason to have the arms and legs flying all over the place at silly angles. Also you can combine ragdoll with animation. For example, you can have a character playing a punch animation, then have his head or arm for that matter react to a blow with ragdoll, while the animation is still playing, and even on the bone that is ragdolling, you can have it blend at any percentage with it's animation, 10% ragdoll reaction 90% animation, or 90% ragdoll 10% animation. Hope that makes sense. I'll post some stuff later. It's a pretty awesome technique that can get you some very realistic results.

>>40815
And like I said in the OP unreal is open source. You can take a look under the hood and see exactly how all these functions are written in C++. Could give you ideas how to implement it in your games in Godot or whatever even.

A piece of advice that a lot of pro games have gotten wrong, is put a fucking max turn speed from mouse input. You don't want people to turn around at whatever speed their DPI on their mouse is.

A question to gamedevs who work with tile or voxel-based games: What data structures do you use for maps? Common practice seems to be a fixed array for terrain and a list or sparse array for everything else. Starcraft famously maintained multiple linked lists for objects relevant to their function, leading to a plethora of bugs. Have any notable advances been made since then aside from better libraries?

>>40792
>>40793
>>40794
I'm doing my own topo because I want to have full control over it and as a learning exercise. I was already doing a single humanoid base mesh that can be modified with shape keys and bone scaling. The examples given are probably a bit too high poly for what I'm going for (I want anything I'm making to run on a toaster). I will probably do like a LOD -1 version of the mesh that has one or two subdivisions on it for any time something is up really close to camera (particularly hands or face) but I'm doing the topology as simply as I can first while preserving the contours I want.

>>40815
Far cry 3 also had a slide mechanic that kept the player grounded if they were moving down inclines. You would slide instead of fall if you were sprinting near an incline which kept the movement much more grounded. Crazy to omagine that that shit is rare to find even in modern shooters.

Also far cry 3 also brought a mechanic from far cry 2 too. The game kept people from falling off stairs when sprinting by locking the movement speed whenever the player’s avatar triggered a staircase’s collision. Such old games but they had such good designs.

Wish I could see that level of expertise in modern games more

>>40820
There's a lot of low polly examples out there. My recommendation is just look up each up the areas, and look up the kind of edgeloops suggested.
>head
http://wiki.polycount.com/wiki/FaceTopology
>breasts
>shoulders,
http://wiki.polycount.com/wiki/ShoulderTopology
>elbows, knees
http://wiki.polycount.com/wiki/Limb_Topology
>hands
>feet
everything else between those areas can be straight forward for the most part.

Got a basic solar system and day/night cycle set up and working together. It uses two separate 3D spaces, one for the main game world and one for space. This was not as complicated as it first seemed. Pics and vids related (time sped way up for demo purposes)

Godot lets almost all of it be handled with node structure and updating rotations of "orbit" nodes that contain the celestial bodies. As for synchronizing the directional "sun" light (and any lights for moons) in the main game world, this is as simple as finding the position of the light source in local space of the cosmos camera (placed on the planet's surface) and having a directional light in the game world point in the opposite direction (the direction the light travels), which is as simple as light.lookat(-sun_position) - at first I tried solving by converting the relative position to a rotation with vector math but then I realized there was already a function for this.

There's a little extra work to do to include things like a sky dome and adjust the visuals according to the angle in the sky, but they're not that complex to work out. It'll probably need a custom shader to look a little better but for a prototype it's pretty satisfactory imo. I also should move a lot of variables and code to a global script so they're easier to access (especially so they can be tied to things like a calendar system and time-based game mechanics).

>>40774
>Unreal
>Unity
>Godot
>Cocos
>etc.
Game Builder Garage on Switch allows me to click together polygonal worlds and it's flexible enough for puzzlers, platformers, racers, whatever. In terms of graphics and sound customizing it got very few choices though. I'm making a 3D-platformer level with N64 complexity.

The software doesn't directly provide higher concepts like pathfinding, but my level's architecture is mostly static, so putting some invisible sensors and triggers into the environment works well enough. Sadly there seems to be no special view mode for revealing invisible sensor stuff while playtesting, instead I have to go into edit mode and manually turn a sensor's visibility on or off.

There is a big tutorial that suggests setting sensors to react to the player character, and that's what I got atm; but I'm thinking about making the sensors instead react to an invisible object around the player that gets bigger when you do noisy actions.

I initially thought it would be elegant to have some logical if-then relations realized directly through physics… But object interactions play out differently on repeated runs (and no, it's not due to variability in user input, I have made sure of that). The physics are so jank that I don't even trust the physics to implement the physics :/ Now I have to use logical fallback solutions to potential physics fuckups: If I wish a big rolling ball to stop in some place after X seconds, I will make sure of that by deleting the ball wherever it may be and teleporting instantly a replica ball into that place.

>>40777
>All of these numbers are multipled or divided by the angle you are going. If you are going uphill it is multipled, so even jogging depletes your stamina, if you're going downhill, even sprinting can keep your stamina constant.
I can see downhill means less stamina lost per meter than running uphill, but that's not the same as less stamina lost per second.