/agdg/ - Amateur Game Development General

>>942
Great post, weird it's not getting a lot more response. Answer the man, ya faggots.

>What were you trying to accomplish?
My situation was a little different. I wanted to create more engagement with the board and tried to draw lurkers out and get them dev'ing. I made the little platformer with luigi and the frog enemy and shit to show people that a beginner could, in fact, make a little game in a month if they just put their mind to it, with the help of a cool library (raylib) that handles the lowest level window-creation/rendering/input handling/etc. code, while still leaving it up to you to implement all of the "game" code - state machines, collisions, character controller, level format, enemy "AI", game state handling, etc. etc. Some fag in the planning thread called me lazy like I had it done already and just rehashed it or something for the jam but the truth is my experience with both raylib and C++ were extremely limited, and work on the platformer demo started after announcing the jam - I had never done platformer development before. Another goal was, of course, to learn just like everyone else - what I ended up making was actually my most "complete" game I've made up until now. I am by no means a professional dev or anything but I do believe in leading by example. So if I'm gonna be the BO of this board, I don't want to be the faggot that says "come on you guys, just li

ClipboardImage.png
[Hide] (16.9KB, 791x441)

>>951
>Seems strange to me. What sets the Y velocity? Is it fixed?
Yep, there's a JUMP_SPEED constant that the player shape's Y velocity is set to on jump. Each frame gravity is added to give the jump its arc. By modifying the Y velocity on release (x0.5 in this case but you could go lower for snappier control or higher for less control) you give the impression of "hold to jump higher" without the fiddly logic or extra velocities. Here's a snip for the entire bit.

>How did you come up with that solution?
I'm sure I saw it somewhere before but I don't recall now. There was some frog platformer I took a lot of inspiration from years ago that had wall jumping that felt good, I might've gotten it from that.

>>942
>What were you trying to accomplish?
A teeth gnashing platformer. I didn't have a strong idea in my head after I shelved the tower survival idea so I ended up just throwing some different mechanics together and tried to make them work.

>Where did you hit or miss your objectives?
I probably over succeeded in the teeth gnashing aspect. While some anons were kind and commented they liked the level design, that was the most rushed aspect (about one day) and I committed on it too soon. I did have a few friends play test and saw there were some early difficulty spikes but at that point I felt like I wouldn't hit the polish I wanted burning a day or two more. When it came down to concessions made in the remaining time I opted for effects and things instead of level design which in hindsight is a bit of a failure. As one café patron put it 'it's a well put together game but really frustrating'. In general I need to do a better job of either setting expectations or being more serious about interpreting how friends trying it feel. Not to sound like I'm after a pity party or anything! Overall I'm happy with what I got done in the time and it gave me things to think about for next projects.

>What caused your results?

drmagma2.png
[Hide] (42.4KB, 800x600)

>>942
>What were you trying to accomplish?
My aim by joining the jam was to both try something I hadn't before and to get my feet wet with C(++). I decided to keep the scope simple to make sure things were achievable with my lack of experience.
>Where did you hit or miss your objectives?
The game is fundamentally as I imagined it, all my specific targets were met. Of course there are things that I want to resolve and improve in the future. Certain implementation details and bugs weren't fixed, the falling platforms and boss battles are the most janky in that respect. I also didn't get the difficulty curve completely right, with some big spikes in there that can easily turn into slaughter houses. Providing more configuration options, preferably in-game is something worth doing also. Finally it would've been better if the sprites were integer scaled, uneven scaling definitely hurts the game's appearance.
>What caused your results?
Leading up to the jam I went through some surface level C & C++ tutorials, this allowed me to get straight to work without being obstructed by unfamiliar syntax. Using Newt's template provided the jumping off point I needed as a beginner and allowed me to make fast progress, though in the future I want to try working from scratch. My simple scope meant that I didn't have to refocus my eff

>>942
>What were you trying to accomplish?
Just, like... make game. Seriously though, what we wanted was to make and release a game. You discover things, both good and bad, by going through a complete release cycle that you wouldn't be able to discover any other way.

More specifically, what we aimed for as outlined in >>712 was:
>a fast-traversal platformer
>where you have to escape a pursuer
>with some original character sprites and
>at least one piece of original music

So this now brings up the question of what a "game" is. I'll sidestep all the tangly stuff that can come with answering that question by simply saying what we wanted was to have a game that
>worked on a "toy" level by being satisfying to control
>had a win and loss condition
>had characters
>had a story of some kind, however thin

ClipboardImage.png
[Hide] (2MB, 2048x2048)

>>962
>Strange to think
Strange to think that character animation would seem easier than background tiles, but that was just how we thought of it.

>weird Godot shit
One place where we were unfair to Godot: The segfaulting in the Linux export was the result of using an older machine where Vulkan was way behind. Narrowed the problem down to a particular GPU particle spawning and somehow crashing lavapipe/llvmpipe, which the program fell back to in absence of a Vulkan-compatible 3D card. Testing the Linux build on Ubuntu 22.04 with Godot 4.1 instead worked fine, likewise a macOS build taken from that version.

Godot is great in many ways, provided you don't stumble into one of its skull-splittingly horrible long-standing-yet-utterly-neglected bugs or under-/mis-documentation... which, given enough time, you absolutely will. Again, no other game engine experience to compare it to, but it didn't live up to its own hype in many ways.

Still, discovering that the Linux problem was the VM's fault and that the macOS build worked went a long way towards our not ditching it for future projects.

>>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