/agdg/ - Amateur Game Development General

>>788
Yeah, it's ass. Nothing you can't do with hap-hazard loop cuts and face extrusions on boxes in Blender. Can also get proper cylinders/torii and shit if you were trying to do something like that bike or another vehicle.

ClipboardImage.png
[Hide] (851.3KB, 1355x1015)

Simple setup for pixelized image, if anyone needs it. The lower "value" on the left is, the heavier pixelization becomes. Its just multiplication+ rounding+ dividing each directional vector.

ezgif-2-269630b1da.gif
[Hide] (932.5KB, 128x128)

PS.

a.png
[Hide] (649.4KB, 470x843)

I try to post here while we have that backupgate over there.

So I checked out this tutorial: https://yewtu.be/watch?v=0TzjpR3pdpk
One thing this guy does is that he selects a random face, Shift-D, RMB, P to make a duplicate into a separate object and work from there. But this way he ends up with a bunch of (partly) duplicate faces, and he only deletes a few of them. Isn't that a bad idea?
(Also the first time I made the building it was too low, normally I'd just go to edit mode, Alt-Z, box select the upper part, G Z and make it taller, but since this model was composed of 8 or so objects I couldn't do that (I don't think I can be in edit mode for more than one object at a time), so in the end I just scaled the whole shit along the z axis.)

Also, in the meantime I modelled a door. Baby steps. And I've managed to produce the worst looking procedural wood texture, I'll try to do something about that tomorrow. But my real question is, I want that door to look old and not exactly in a good shape. It should have paint, but that came off at various places (that's why I need the wood texture) (something like this, but with wood instead of metal, and probably without texture painting: https://yewtu.be/watch?v=bR4HtqxA9tk). I'll play around with my materials, bu

>>1001
>One thing this guy does is that he selects a random face, Shift-D, RMB, P to make a duplicate into a separate object and work from there. But this way he ends up with a bunch of (partly) duplicate faces, and he only deletes a few of them. Isn't that a bad idea?
It just how he does things, I suppose. Its possible he just extrudes them afterwards, so its not duplicate faces, but multiple fully complete objects. And adding them together is quite easy. Its also possible that he does it because its fast for demonstrational purposes.
>(Also the first time I made the building it was too low, normally I'd just go to edit mode, Alt-Z, box select the upper part, G Z and make it taller, but since this model was composed of 8 or so objects I couldn't do that (I don't think I can be in edit mode for more than one object at a time), so in the end I just scaled the whole shit along the z axis.)
You can edit multiple objects at the same time, just select all needed objects and move them. You can also do parenting, it all depends on what feels easier/faster to do. 
>painting texture
I would just use noise texture or noise + geometry>pointiness / AO texture as a mask. 
The problem with your wood material is values of various modifiers of texture. Most obvious is bump node, you need to lower its value. And it needs ramp nod

>>902
>lol don't kill my thread.
Heh my mistake Anon. Clearly you have more to contribute, please proceed. :)

>>903
Was joke, comrade :^). And nah, I'll stop shitting up the thread. Maybe somewhere else, some other time.

4f7760ce100e626199a77f0f635df8b8.gif
[Hide] (127.4KB, 500x500)

ac8a83920e36de410881d6c66b32a8063a129662.png
[Hide] (1.2MB, 2000x2000)

>>902
>license drama (of which I am the most guilty) should be its own thread, something like "gamedev legal/ethics/financial"
If we do end up with one, I am going to use it to yell about shitbirds who pretend to offer assets under Creative Commons licenses but then add restrictive "gotcha" supplemental terms that Creative Commons specifically disallow under their trademark policy.

>you can have this under CC-BY (unless your game's sales exceed $X) hurr durr now we come up in CC license search results make sure you read the Free* license terms! :)
IF YOU USE SUPPLEMENTAL TERMS TO IMPOSE ADDITIONAL RESTRICTIONS OF ANY KIND IT'S NOT CC-BY ANYMORE IS IT, CALL IT SOMETHING ELSE LIKE THE YOU CAN USE THIS BUT I WANT A CUT LICENSE FUCK I KEEP SEEING THIS SHIT EVERYWHERE I AM SO MAD

>>902
>GPL did not bring out the desired goal, that is, advancing 3D games and the FPS genre
Well that's not so easy to measure, since the lessons developers have learned from Id's codebases aren't necessarily so explicitly stated, as a learning resource the Doom 1-3 & Quake 1-3 sources have been invaluable to many game devs.
>"mod community" banging on 30 year old tech because that's all that's "free"
Seems more like a problem with the culture of game development, getting the sources for 20+ year old games if the planets align shouldn't be the norm but it is. Also the things people accomplish with those very old engines are very often more experimental and innovative than what you generally get from the modern industry, you have to at least appreciate the dedication involved.
>I'm pretty sure there was a Doom 2, Quake 2, Q3A...
Well yeah, but Doom 1+2 and Quake 1 have the most popularity in large part due to what the community does with them, which gets spread around various places and gets people outside those communities interested in playing these new mods and total conversions.
>Are you saying Id is making money off of Doom and Quake today?
Yep, for Id it's a very low maintenance deal: By providing the games on Steam and other stores (generally just the original DOS versions wrapped with DOSBox) players buy the games, then take the data files and play them with source ports and mods developed completely by outside devs, Id doesn't need to get involved at all and can just let the money come in.
>Presumes source port developers would keep their changes to themselves
I base that on observations of other scenes where sharing your work isn't a requirement.
>which is fine too, as it actually introduces diversity and competition
Personally I don't think so, in those scenarios you often get certain projects having lots of control over the community, where what they say goes and people have much less power to mitigate the damage in the event of a lead dev with bad intentions.
>you would have to play the original versions instead because the superior source ports didn't all release their code?
That's fair, I didn't think that completely through. My concern was more about the issue of continuous maintenance when developers inevitably stop working on their port and that project is closed source, such that eventually you end up needing a jenga tower of fixes for fixes of ports as operating systems and hardware move on.

>>896
I did not mess with it a whole lot, mostly played through the default game, tried mods, modded a little.
Demo game: worked nicely.
Simple ruleset and simple resource modding (adding a new ability, etc): was indeed trivial.
Variety between styles of the existing resource sets: good. From Diablo-like (Flare-game) to jRPG style (Polymorphable). https://flarerpg.org/mods/

The possible downside:
Rummaging through assets of Flare-game shows that for all this fancy equipment in hands to look so nice the sprites require not only a set of standard angles, but fuckery with split layers, which does not look trivial.
Not unexpected (FreedroidRPG data/graphics/tux_motion_parts/ is not for the faint of heart either, that’s just how sprite based engines do it).
Probably… maybe… hopefully there’s something in documentation on how to do this efficiently.

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