/agdg/ - Amateur Game Development General

>>946
Tested with a 22 x 22 x 22 grid of evenly spaced AABBs (total of 10648). I was a little worried at first when I saw 4.5-5 ms time to cull, but then I remembered I was building with debug flags and no optimization. Rebuilt with -O2 and got ~1000us. Culls 10648 down to about 1400-1500 visible by the way. Seems to work well enough for now. Time to actually get some complex terrain and entities in here.

>>943
From the looks of it, you gotta generate collision mesh either way. Or you can have "minimal" height, which probably look better. If player character Z position stays within minimal range, it doesnt visibly change. Ideally you will have torso stay within range, and legs will bend when needed. Not sure how it would look with small ramps tho, but you can figure it out. Also, benefit of collision mesh is loading what player will be able to see from it. 
Also, easier solution, is to not give small objects collision.

oct1.png
[Hide] (308.5KB, 1285x805)

oct2.png
[Hide] (89KB, 1284x805)

octree.webm
[Hide] (2MB, 1284x804, 00:17)

Octree implemented. Got to thinking and came to the conclusion that you can't really get around using one. Got the idea of how to implement properly from thinking about how I would bin each mesh triangle into its respective "chunk" without duplicates or gaps, when I split the zone terrain mesh(es) for rendering/loading. I start by loading all of the models/meshes/whatever. Then, I get an AABB that encompasses them all exactly, which is easy enough, you just find the smallest and largest mesh x point, smallest and largest mesh y point, etc. Then, if I'm encompassing more than 8 meshes in that AABB, I split that AABB into 8 dividing by the length, width, and height. That gives me 8 new AABBs, which I bin the meshes into according to their AABB center point (again, simple to calculate). Then, I recurse, which of course, means for each child AABB, I resize to properly enclose the mesh AABBs, then see how many their are, if more than 8... and so on. I use some flags to indicate empty/leaf node/etc. too. Memory management handled with shared_ptr, as in each Octree has "std::shared_ptr<Octree> nodes[8];" which are instantiated as needed. No malloc/realloc bullshit. 

The idea for mesh chunking is basically the same except splitting in on a regular 3-dimensional grid, then sorting and re-meshing the tris in each according to originating mesh/mesh material. Those smaller meshes, of which there may be thousands, can then be view culled with an octree. Next thing I have to think a

capsule_explained.png
[Hide] (104.2KB, 1200x900)

>>948
There is a collision mesh. Or do you mean a simplified, collision-only mesh? I have no plans for any kind of inverse kinematics and I don't really want the feet clipping into the ground any more than they do now (which I spent a long time getting right). I made this pic to show exactly what I'm dealing with. The top half shows some of the problems encountered with a "naive" capsule collider implementation. On flat ground it behaves ok. However, on stairs it's all sorts of fucked. You can get stuck in a floaty halfway-between-stairs state, plus you can't ever really approach the side of the step. On slopes too, you will always be floating a bit off of the ground and it gets worse as the angle increases. Not to mention the way you fly and bounce going down a slope. My approach is the bottom half. I use a capsule for normal wall/ceiling collision, and a ray for ground collision/detection. Raising the capsule lets you get right up to the edge of steps, then "pops" you up to the next one immediately with no "in-between" state - you're either on one step or the other. On slopes, too, it places your origin position exactly on the z-axis value of the slope at that point. I also use a longer ray when moving horizontally or downwards, to detect and "clamp" the player to the slope so you don't bounce down it. 

The only "bug" I've encountered so far has been falling down into small gaps that the player shouldn't normally 

octree2.webm
[Hide] (4.8MB, 1282x800, 00:21)

>>949
Thought it would be cool to show the frustum so I gave it a try.

Moved to progress thread >>749
Will lock this one and let it slide down the board for now. Let's keep these sorts of update posts to the progress thread. If someone wants to make a "showcase" thread for people to shill their completed projects, that would help. If not, I'll make one.

>>463 (OP) 
It looks a bit plain. The look could work with more detail (especially the background), maybe add some shading, round off the hard angles and perhaps add an outline to the character? You should show some other parts to give a more complete impression.

>>463 (OP) 
Looks like it's made in Scratch.

Screenshot_20230316_072502.png
[Hide] (8.1KB, 609x456)

Found the game, I don't think the guy who made the post actually made the game. still cool though. https://scratch.mit.edu/projects/792294181/

Screenshot_20230316_072502.png
[Hide] (8.1KB, 609x456)

If Anything The Creator Could've Leaked It To One Of Their Friends, since this image was before the game was made and also didn't have variables.

One suggestion I would give if this is the creator though is decorations in the background, since that could be accomplished in scratch.

>>434 (OP) 
game is now free

>>457
Please stay encouraged Anon. This kind of effort is always a process, be patient. Congrats on your game BTW, please keep working on it! Cheers. :^)

>>459
I'm clueless about programming and just happened to be wandering through here but will second this. Your enthusiasm is commendable, but it takes a lot of time and effort to hone your talents no matter what field you're working in. Keep pushing yourself further and don't give up what you're passionate about.  I wish you the best of luck.

Since you shared it for free now, I'll share some thoughts after my playthrough.

The game was very basic, this isn't an insult or complaint, just an observation. The ducking mechanic seemed mostly irrelevant except for a couple of levels.  As can be seen in the OP pic, those platforms to jump on/over do not provide cover from enemy fire. They probably should. The level in the enemy ship had platforms that were difficult to notice, blending in with the background. Maybe that was intentional, to suggest alien design the protagonist is unfamiliar with.

 Despite the special medial droid treatment received at the start of the game, there are no upgrades for weaponry or health. Also, only one level seemed to have a health top up. Perhaps at a certain point, after clearing the science lab, a choice ought to be offered upgrading health or weapon power. The virus in the computer level was very sensitive, adding difficulty in an awkward way. Just a slight tap on an arrow key could overshoot the target area quite easily. I'd suggest making the maze more complex instead, with a finer degree of control for the cursor. As for the thick health bar at the bottom, it looked odd. I would make it thinner and stick it in a corner. Probably give it a percentage too, or have it change color, starting green and turning red at the lower end.

The music was pretty good, gave an appropriate vibe. Story-wise, it was solid enough I suppose, considering the length of the game. These areas had the stron

>>461
>>459
>>460
If it helps, some of my future work is going to be history and aftermath. I might make some of these changes and introduce them in an update eventually. I dearly appriciate your feedback.

BTW the first few levels are meant to be way, way, too basic because it was meant to give you a feel for the controls.

Any progress? Can you opensource it on GitHub?

1669166482831026.png
[Hide] (1.1MB, 900x1440)

I am a decent programmer, I can write in Lua, C99, Common Lisp, Java and I have some expierence with C# in Unity and Python in Pygame too. I would like to help if the project is completely public domain, otherwise I would consider it unethical to contribute.

>>453
If you find this doesn't pan out, please come help us build robowaifus then, Anon.
https://alogs.space/robowaifu/

1669349891198917.jpg
[Hide] (392.3KB, 1220x2048)

>>454
Robowaifus sound awesome, thanks for giving me the link, I will look into it in my spare time and help you guys out - at the end a robowaifu is a great dream of mine too.

>>456
Y/w Anon. There's a large degree of crossover between vidya dev, and several of the sub-domains for robowaifu creation. Mechanics (as in the physics involved in bipedal humanoid motion & control), and character acting are a couple of good examples of this.

bump

Sorry it's nothing personal OP, but I didn't reply till now simply b/c I don't do Python. C++ is a much more common language for game dev AFAICT. Good luck with your quest though.

The documentation in Ren'Py regarding 'creator-defined displayable' is very straightforward to me. The creator-defined displayable is supposed to be a canvas to allow the programmer to draw anything. If you don't understand how to program your breakout game with Pygame, you absolutely will not do it in Ren'Py with the creator-defined displayable. If you don't understand the example in the documentation, you absolutely will not achieve your aim in Ren'Py.

I won't hold your hand in the details of getting this done. I will leave these hints to you:
1. Figure out how to draw a simple static (a non-moving, non-changing) colored square with the creator-defined displayable.
2. Figure out how to animate that square (move it, change size, change color, change opacity)
3. You should be able to draw multiple objects onto your displayable
4. Program a breakout game with Pygame, not Ren'Py. This is so that you understand the principles of programming and drawing a game to a screen
5. You should be able to port that logic of the breakout game onto Ren'Py's creator-defined displayable.

>>299 (OP) 
There is an engine called ursina, m8

>>436
Thanks!

>>437 (OP) 
gimp

This is good stuff.

BO, I think you really should pin this thread tbh.

Highly soy tbh.

>>23 (OP) 
Only massive faggots make pixelshit.

>>428
>Implying animation principles only apply to pixel art
>Nodevs in charge of not being a retard