/v/ - Video Games

Newbie game dev here, I will make a simple game and upload it as soon as possible. I want to make game, I don't care how bad it will be. I just want to make game.

>>15154628

Just make an Arkanoid clone or something to get the groove.

>>15154628

>>15154696

I would advice against making it for android, add basic controls and see how it goes, remember, design gameplay first, then the art.

>>15154628

I honestly don't think this is a good idea. Make the game shit, sure, but at least fill it with enough stuff that you'll get to experience all the necessary steps of gamemaking while you work on it. From concept, to prototyping, to art and music.

Vid related

>>15154628

Do a Snake clone

>>15154618

is this minecraft?

>>15155026

Why would you ever want to animate in godot, an engine that has nothing to do with animation when you can do it in a program built from the ground up to do it?

I mean I guess you could look into procedural animations.

>>15155026

Unless Godot has the tools for that I don't think so, what are you trying to do? does your model have a unique skeleton? you could use Mixamo's auto rigger and get some free animations.

>>15155026

wait for 3.1

I added iTween to my project in Unity but I'm unsure how to create visual paths with it

Anyone know how to get this to work?

Do I have to download vid related separately? The files are 8 fucking years old

>>15155267

You could theoretically animate 3D bones by keyframing bone transformations, but there's no visual editor yet. Much better to animate in a modeling program and import.

>>15155366

So, what kind of game is the "notShinobu Simulator" ?

>>15155392

Not really a game it's just a fuck around sort of simulator. Basically a tamagochi is what I'm aiming for. There are things to do and actual games within like chopsticks but really it's more of a chill out sim. I'd like to eventually add things to explore with her and what not.

>>15155399

Can you at some point explore her ?

>>15155434

Sure.

>>15155608

So what's considered a "portal"? I'm taking it to believe it's some kind of depth window, and not like Portal portals

>>15155608

what the FUCK are you trying to do?

>>15155662

Nah, they are actual portal portals. Watch embed related.

>>15155742

Lurk moar.

>>15155383

Neat stuff as always shinobro

>>15155768

Is this technique used in modern engines as well, or are you using it to emulate older style games?

>>15155820

It's not used in modern engines. The engine I am making is an old-style engine.

GDScript or Mono for Godot?

Why are skeleton animations such a huge pain in the dick?

>>15156294

If you're coming from traditional animation, believe me then I say the annoyance of having to micromanage bones is made up for via the computer handling interpolation between keyframes

>>15155608

> and none of them face outwards into a void.

Logically you'd cull those in a preprocessing step since they'd never be seen.

>>15155820

It's a method for culling polygons/tris. It could be used in a modern engine. What does that even mean? City of Heroes used it. Many games from 1995-2005 used it. It could be used in modern engines. If it is or not I don't know. Culling the total set of tris to render is always an issue. How to organize and cull the total set is an ongoing area of research. Portals are a reasonable way to cull interiors.

>>15156329

I can translate the bones fine I just can't get the skin to bind to them.

>>15155033

No this is aggy daggy. I'm making a hacky slashy. The block terrain is just there as it is way easier to work with than polygon/bsp's, and the model is something I quickly threw together for testing. I have no intention of recreating the box-character style from Minecraft.

>>15155608

Aren't portals in BSP's just walls like any other? (Except that they render the room behind them instead of a texture of course.) I'm pretty sure if you have them sticking out of the room partially you're violating the principle of convex rooms.

>>15156368

Delicious octahedrons.

>>15156422

Where are you having the problem? In your modeling tools? Or are you trying to write code to import a model?

>want to make a tactical shooter

>That would actually take artistic talent to model, animate and design maps/scenarios

Fuck that. I'll just make a roguelite

>>15156634

lel. maybe learn those skills then?

>>15156634

Your levels can be square grids and your characters their hitboxes if the gameplay is good. Find a minimalist artstyle that fits and people will praise you for it.

>>15156939

You are missing hip bones. Hip bones connect the thighs to the spine. You do not have any.

>>15156968

I don't think it's turning the leg bones into a single bone, I think it's not detecting the leg bones correctly and making an existing bone appear larger.

>>15156988 is a good suggestion. You shouldn't have those dotted line relationships between bones I forget what they're called exactly you should have actual bones there. Not just the hip, but connecting the arms to the spine as well.

And if it's not auto-detecting correctly in Unity you should be able to manually assign the right bones to the right body parts.

>>15156906

I'm the vulkan engine fag. My primary goal is making a physics engine and employing it simply while also making a game I want to play. The whole point of me making a physics engine is because with sufficient physics you can naturally invent create a world that looks good (e.g. ray casting lighting/shadows).

There's a lot of repetitive elements in the roguelite I envision while a tactical shooter requires a hell of a lot more general gamedev/artistic skills.

>>15156939

Not simple hitboxes. Regardless of the game, I want to make everything decomposable. Characters (possibly different monsters/things) will have bones that articulate with flesh surrounding. I really liked the low-poly meshes someone posted in the previous thread. I'm currently wondering if I could make a game that's graphically basic (like an old fear game) but squeezes as much physics performance out of the engine. Think of a modern game that looks like FEAR except you can turn everything into dust (like vid related). Doing this well would be incredible but to accomplish it is bit idealistic, especially since good tactical shooters require a great deal of work in their level design which is stuff I just don't want to focus on right now.

I'm just being a dumb cunt though with all of this though since I only just implemented a sampler into my engine >>15156299

>>15156268

I think a component of Mono calls home., so GDScript.

The next version of Godot will have optional typing for GDScript.

>>15156995

>>15156988

Oh shit nevermind the thing isn't there in the original rig

sorry

>>15156565

>Where are you having the problem? In your modeling tools? Or are you trying to write code to import a model?

I'm using an importer that imports GLTF models.

The problem is GLTF is basically trying to be a universal format that is bloated and confusing as shit. There's tons of duplicated data and redundant references. Also it can say NON-JOINT nodes are a child of a joint. So if you're building out a skeleton you can have your joint point to random garbage as a child. I'm honestly thinking about switching formats. I only picked up this garbage because it's been made by the group who made OpenGL, is FOSS and has a blender exporter.

>>15156565

BSP does not normally generate with portals, you have to create those after the compilation. It's not a violation to have them sticking out of a room partially since the leaf that that portal is attached too represents a space that stretches out from it's polygon into an infinite void. It's fine for my intents and purposes (but obviously not generating the way it should be…)

>>15157255

>The problem is GLTF is basically trying to be a universal format that is bloated and confusing as shit.

So basically, the same as every other model format.

>I'm honestly thinking about switching formats. I only picked up this garbage because it's been made by the group who made OpenGL, is FOSS and has a blender exporter.

Why not Collada? It's also managed by Khronos, but it's a lot older. I don't know what it misses in features, but it has plenty of tutorials and libraries out there to help you with getting it set up. If you google "OpenGL Skeletal Animation", you'll find a whole bunch of tutorials using Assimp to import a model file, which also supports it. It's what I use.

>>15157301

Sorry, I'm fucking up my terminology and confusing BSP's with PVS's.

>>15157353

>So basically, the same as every other model format.

Obj is perfect, but it doesn't support animations. I don't know why nobody there wasn't an extension of it to do this.

>Collanda

That popped up a ton when I was trying to figure out problems with GLTF. I think theres a ton of overlap between the two. Apparently the blender exporter is broken though, at least according to this godot article.

https://godotengine.org/article/we-should-all-use-gltf-20-export-3d-assets-game-engines

From what I've read, it seems to have GLTF's problems and then some.

>>15157371

>Obj is perfect, but it doesn't support animations. I don't know why nobody there wasn't an extension of it to do this.

That's where the problem lies. Making a model format that is just the raw vertex + element data in text format is trivial. But the moment you introduce all the complexity that animation brings the shitshow of different approaches to the same problem starts.

>Apparently the blender exporter is broken though

The blender exporter definitely has issues. For one, it doesn't support shape keys. But you can easily fix that by telling blender to simply generate in-between keyframes for you. Alternatively, people made their own exporters for blender that don't suffer those issues.

But, all in all, it does actually export a model with working animation, as you can see here >>15154618

Even if a model format is broken, I'd rather use a broken model format with a compile-able working example that has no problem importing my blender model & its animations than actually use a good model format for which there is no such thing.

>>15157453

>That's where the problem lies. Making a model format that is just the raw vertex + element data in text format is trivial. But the moment you introduce all the complexity that animation brings the shitshow of different approaches to the same problem starts.

I don't know if I buy that. OBJ did one thing and it did one thing well. It held mesh data. All these animation formats are trying to do 20 different things, and they're shit at all of them.

>Even if a model format is broken, I'd rather use a broken model format with a compile-able working example that has no problem importing my blender model & its animations than actually use a good model format for which there is no such thing.

Right now I'm just worried about switching over and hitting the same dead end and wasting a ton of time. Although, GLTF is still in it's infancy so maybe it's the one with more issues.

>>15157682

>using unity

Well there's your problem.

>>15157685

Unity is, unfortunately, the most feasible engine to actually make game in

>>15157763

Don't respond to bad bait and shitposts

>>15157784

>bad bait and shitposts

It could be either, but there's a lot of schizoids here who actually believe that using an established engine is wrong.

Do you ever just feel like a dummy?

>tfw get confused about how 8K textures can fit in VRAM because 8K textures are obviously 8GB

>Oh wait… They're 8MB

This is the second time the sheer size of gigabytes has stumped my mental midget mind.

>>15157763

As opposed to making your own engine? I doubt it. If you're going to put in the effort to make your own game you might as well make it truly your own.

>>15157792

You're not going to make anything that stands if you walk the worn paths.

>>15157799

I'm pretty sure an 8k texture would be more like 250mb in memory.

>>15157800

Are you lazy? Why not design your own computing architecture to run your game on so you can program you game in assembly?

>>15157800

Nevermind, this is bad bait.

>>15157820

Working on making Ternary a thing so we can eventually get to matrix-levels of code density. If you want to make AI a reality then you need to copy the human neural network as closely as possible and nerve cells certainly do not work on a binary level.

>>15157824

>le ebin your argument is just bait :^)

>>15157820

>not hardwiring your game directly into the circuits of your own computer

You can't even call yourself a gamedev

>>15157799

>an 8K texture is only 8 MB

>64 million pixels are stored in 1 million bytes

except for some rare occasions (like the gamecube) textures are stored completely uncompressed, so it'd be a lot more

>>15157799

>>15157812

RGBA 8K textures are 256MiB.

>>15157833

GPU's have had hardware texture compression since 1999 and it has only become better and more prevalent since then. If any game is using 8k textures, it is probably using that compression to save VRAM.

>>15157812

>>15157833

Oh right yeah.

4-channel 8K would be 256MB

4-channel 4K would be 64MB

Are there any good places to view differences between 1K, 2K, 4K, 8K textures in a game??

>>15157255

I've been using directX (.x) files and 3d studio max files (.3ds) exported from Blender, then into AssImp converter which writes out my own binary file format. I haven't found any other Blender exporters that have worked quite right with animations, UVs, & normals.

I tried Collada a few years ago and it didn't work correctly, producing really bad meshes. Maybe it's better now.

I'm interested to hear how your work with GLTF goes. I was looking at it too, but .3ds files are working for me so I haven't spent that much time on it.

>>15157840

>GPU's have had hardware texture compression since 1999

Which consumer GPUs specifically?

>>15157849

The first consumer card to support it was the Savage3D in 1998, and it was supported by the MeTaL graphics API developed by Savage for it's cards. Unreal Tournament even offers special high resolution textures that require the texture compression.

https://www.youtube.com/watch?v=1B1SSdSAhqY

https://www.youtube.com/watch?v=DfjZkL5m4P4

Texture compression is a hardware feature in basically every modern graphics card now, it's a standard feature and better compression formats are supported. So, it's not new at all and essentially every single GPU made in the last 10 years should have some kind of texture compression.

>>15157871

Is this a feature that has to be activated or would graphics libraries use it natively?

Just wondering because it probably slightly impacts performance.

>>15157885

You have to activate it and explicitly use it, you can even store textures on the disk in compressed GPU formats, for example. If you're using a high level API above OpenGL or something it could in theory compress the textures internally for some extra space saving. (but this wouldn't allow for the same optimizations).

>>15157871

Alright, that card in 1999 had it, but I'm still not convinced that hardware compression is commonplace now. I'm sure it can be performed on the hardware.

>>15157914

https://www.khronos.org/opengl/wiki/S3_Texture_Compression

>>15157846

>I'm interested to hear how your work with GLTF goes.

I'm probably going to switch. I've been banging my head trying to get skins to work for almost a month now. Everytime I lookup the issues I get Collada mixed in, because the two are so similar. GLTF 2.0 is basically looking like Collada 3.0 to me.

>>15157937

Yes, texture compression can easily be performed on any modren programmable graphics card, but that's different than hardware support. we're just being pedantic at this point anyway

>>15157792

>Calling anons schizos

>While supporting using engines that fund the Jew

I'm on to you Rabbi Schlomo

>>15158055

>Calling anons schizos

The reason I call them that is because they can't separate their own thoughts from anyone else. People aggressively shitting on using engines invariably use reasons that only apply to them, without actually considering anyone else's thoughts or goals. This is different than shitting on the engines themselves, which I do all the time

>>15158055

Notice how he turns unity bashing into general engine usage bashing. Dudes a master of D&C.

>>15158124

>Notice how he turns unity bashing into general engine usage bashing

Enginefags really enjoy solving problems that have been solved and thoroughly documented. In current year + XX , the only real merit to choosing an engine for the rest of us is whether you can actually get shit done with it.

>>15158221

no one can accuse me of doing anything for free

>>15158240

>>15158221

>>15158189

>>15158166

You guys want to maybe stop shitposting in /agdg/? This petty argument is fucking worthless and has already devolved into namecalling.

>>15158247

The only argument I'm having is he's trying to D&C the thread, which is why I filtered him and will do so in the future.

>>15158255

You still haven't explained what I'm supposedly trying to conquer. Nodevs who build their own engines?

>>15158200

I made pong once. Now I can shit all over your work and you just forfeited your only way of deflecting it.

>>15158200

>If you haven't operated a restaurant and cooked a burger for someone, you can't call their food bad

>>15158292

More like

>If you haven't operated a restaurant, you can't tell someone the best way to operate a restaurant

>>15158292

Did you even read the post

You can criticize the game, not the engine.

By your metaphore it would be like going to a restaurant and saying they're preparing lasagna wrong

>>15158282

Since we're on cooking allegories, you made a sandwich and now are telling chefs how to cook.

>>15158200

>>15158282

>>15158292

>>15158302

>>15158307

>The ultimate win-an-argument card in /agdg/ is "Where is your game"

>100% of the time the other person will have nothing to show for it

>Because the people who actually make games aren't arguing about semantics

>>15158441

If you're even bothering with MSDN I assume you're using C#. What are you trying to look up? Since they own GitHub now, it's actually a great spot to peek at their source code, even if it's kinda bloaty https://github.com/Microsoft/referencesource/tree/master/mscorlib/system

Also, I know the previous version of MSDN, if you clicked on a class name or something, it would take you to a generic lander page for that object, and then you'd have to click class members to actually see shit

>>15158480

Anyone who makes their own engine and doesn't have some kind of clairvoyance will definitely need MSDN.

http://archive.is/kVG4B

Oh hey so this is interesting. Just a little weekly writeup by the Factorio devs, but they look at a few different sprite handling techniques

Is the (microsoft) standard of having gigantic walls of comments actually good practice?

>>15158480

I'm using C/C++ and am trying to look up SetDIBits and GetDIBits. I don't use C# at all, sorry anon.

>>15158561

It's used for documentation. They probably have a program that looks in the source files and uploads the struct and function definitions and the comments to msdn.

>>15158561

>>15158567

The Microsoft® best practices™ is to either inline XML comments above every single public-facing field for every object, or else point the compiler to an XML document to include with the binary file. Obviously, this bloats the source, but if you're making an engine/API, the separate attached file may be a good idea if you're pedantic.

Either way, self-documenting code that actually works is a good thing to aim for

>look over MSDN's C# code

>find contracts

So it's like Debug.Assert, but can also do static analysis when compiling? Guess there's no reason not to use it.

>>15158561

Having good comments in a reliable place (ideally in the headers) is never a bad idea.

Okay so here's a gameplay question that's not related to my current project, but one I'll have a few games from now (I want to just mull it over for some time, while working on somsething)

So I want it to be a dungeon crawler, party of four maximum with a first person perspective, like those old games, and grid based. Combat would be simple and round based, but I'd want to have a gambit system like FF12 for assigning basic AI.

My problem is how can I set a "timer" of sorts where it makes the players periodically return to town? I feel that having a good cycle between killing monsters and resting is ideal, so they don't clear half the dungeon heal, run down, and do it again.

>Stat timers (HP/MP); once they run out you're dead or can't make good headway. Warriors can keep going though

>Artificial timers (oxygen/food/morale/corruption); arbitrary and difficult to design around, it's a timer for the sake of it and doesn't integrate well with mechanics

The one thing I wanted to do though was have 3 different ways of affecting MP for abilities: straight regeneration, reduction in MP costs, and having a large pool. That way you can itemize and build different ways, which would affect how you can do certain things, which I think would be cool. But then, if you have regeneration in MP you can stay down indefinitely.

So I was thinking of having a THIRD resource, energy, which can't be replaced until you rest in town, and only decreases by using special abilities (or certain very rare monsters). If your energy is depleted, you can only attack or move. Thus, energy would be a long term thing for abilities, while MP would be short term.

I think I'm okay with it up to this point, but here's where I want your advice: If I let players buy food/rations, at the cost of increasing their weight (thus delaying their turn order in combat), but let them rest outside of combat to restore their energy (and a fraction of HP), do you think it would break this system?

>Want to stay out longer, so buy food

>But now I'm slower in fights

>But as I rest to recover, food is consumed so my weight goes down, so now I'm faster

>>15158564

I haven't used SetDIBits or GetDIBits but I have successfully done software rendering with StretchDIBits, maybe you should look at that. You can see an example of how to use it in Phillip Buck's "Handmade Quake" series.

>>15158035

>>15157914

If you don't know about this resource, here is a list of the cards that support some kind of texture compression and comply with the most basic GL_ARB_texture_compression OpenGL extension from 2000.

http://feedback.wildfiregames.com/report/opengl/feature/GL_ARB_texture_compression

And here is the extension in question:

http://feedback.wildfiregames.com/report/opengl/feature/GL_EXT_texture_compression_s3tc

If you look at the full list you can see there are 19 diffrent extensions that have "texture_compression" in the name, with varying levels of support. However ARB texture compression and S3TC texture compression are both at 99%.

http://feedback.wildfiregames.com/report/opengl/

>>15158705

If this is for mobile, those guys really do not care about slightly grindy mechanics.

I would personally do cooldowns, but allow players to create teams with different characters that are part of their guild.

This is essentially the Darkest Dungeon system, but it works extremely well not only gameplaywise but it also allows the player to get REALLY attached to their characters. If you want to go a mile more add some nice customization options and you'll get plenty of people addicted as long as the dungeoning is fun.

>>15158705

Forgot to answer your actual question.

I think food/rations/weight mechanics are really really annoying. Honestly the only game I've played where they are not a massive ballache is New Vegas Hardcore mode because it's extremely easy to break if you know the game well.

But since you're planning for people to buy rations you will not be able to actually make them, so that might create a lot of annoyance.

>>15158715

>I haven't used SetDIBits or GetDIBits but I have successfully done software rendering with StretchDIBits, maybe you should look at that. You can see an example of how to use it in Phillip Buck's "Handmade Quake" series.

Yeah, thats what I ended up using. I already knew how to do use that from Handmade Hero.

>>15158737

>But since you're planning for people to buy rations you will not be able to actually make them, so that might create a lot of annoyance.

Not necessarily. I know it's an annoying thing, but I don't want a player to clear the dungeon in one go, but just throwing strong things at them to waste their resources feels cheap as well; they should be able to control the rate they use resources, but still have a finite limit before they can return. I feel like this creates a rhythm to the game flow

But also, depending on how I implement it, I could eg have a Ranger or Survivalist class/ability that lets them create food from plants or monster parts maybe. Not sure how I want it to feel though, since it's still a very distant project. I think the whole issue with hunger mechanics is that they are added in as an afterthought and there's no design space to interact with them.

>>15158837

Also, since it's a round based combat (think FF), weight would just end up making the slowest character go last, while your thieves and such get their first strikes in

what math subjects do I need to know before getting started with programming? I don't know anything besides some 1st grader bullshit to be honest and I have to use a calculator for that..

someone give me a list and i'll get started on it

I assumed algebra (equations) so i'm learning that first

>>15158938

Trig.

You can probably survive without it for 2d, but I've had to use it numerous times before. For 3D, you're probably fucked without trig.

>>15158938

That depends on what you wanna make and what tools you'll use. Anything with rotation or more than 8 directions and you'll probably need trigonometry, but classic games often don't rotate anything. Engines solve many problems for you and if you don't need anything fancier then that's that. 3D is obviously a lot harder in many ways than 2D.

>>15158938

The benefit of programming is that you don't have to do the math yourself, you have to know how to instruct the PC to do the math for you. Like other anons mentioned, trigonometry is pretty damn useful, but you'll also want to know vectors to some degree. You don't need to know how to make them when using an engine, but you do need to know how to use them.

Aside from that, it's very much more about being able to identify what problem you are trying to solve rather than actually solving the problem, you can find a lot of solutions to problems online.

>>15158938

Simple curves, rates of change, and linear algebra have been very useful for me, but I'm somewhere between making a game and engine

>>15158938

Unless you get into engine devving you're probably not gonna need that much math honestly. Unless you want to get really autistic with stat calculation, but even then most of the formulas that the Final Fantasy games used are online so you can probably get the idea on how to make them work.

Trig is a must if you want to get any complex movement working, useful mostly if you work in 3D.

But really the best thing to learn to program is plain old logic.

>I'm here

>I need to get here

>What's the best route to take

>>15158938

I was literally just listening to HH where he mentions this.

https://hooktube.com/watch?v=_4vnV2Eng7M&t=5477

>>15159353

You really ought to use probuilder to shape your environments before making them in blender, those stairs are going to be a bitch to navigate even without the bug to travel to PUs

>>15159399

upper floors will not render if you are not on them

>>15159399

naw

just fix the controller or geometry

>>15159412

That's not really the problem here

Hi all,

I'm using the learn opengl tutorial here: https://learnopengl.com/

I'm using the source code from one of the parts, and attempting to get it to compile without using the provided cmake/generated make files.

It compiles correctly without errors, but when I execute the binary, the screen's background is colored correctly, but no primitives are drawn or textured.

Any ideas on what to do here? I know that the code works correctly when compiled with the provided make file, so I don't think the source code is the issue, but how could it compile and result in very different runtime behavior?

>>15157008

how many lines are you up to?

>>15159574

okay, nevermind, I fixed it. Still don't know what was the issue, but at least it's over.

>>15159622

what gaem?

>>15159707

Welcome back to "Anon Googles so you don't have to"

https://www.rpgmakerweb.com/support/products/tutorials#rpg-maker-vx-ace

https://forums.rpgmakerweb.com/index.php?threads/a-list-of-tutorials-for-beginners.15135/

I've used the official PDF tutorials and they are good.

>>15159707

>>15159755

Bouncing off of that, I thought RPG Maker was hated due to the many, many games that use default art assets and do nothing new with the combat systems?

Assuming you could get a decent artist on board with something that looks interesting, is it worth it? Or does the engine itself limit you to make the same turn-based combat every-other game has, so you can't do your own shit?

>>15159559

Thanks, anon!

>>15159775

I think rpg maker is hated for a lot of things including the rtp assets. Although from what I hear VX Ace seems to

need extra work for some battle stuff that was easy in 2k3. I don't know specifics though since I just started looking.

I am planning to get custom art but this is mostly just a game for some close friends since it's mostly in jokes.

>>15159755

>Anon Googles so you don't have to

I can google I was mostly just looking for what other anons have used and found helpful. Thanks anon I will look through these

>>15159707

>>15159755

>>15159775

RPG Maker was designed for creating a very specific kind of game, and fucking sucks at anything even slightly outside its intended use. If you stick with it, you'll waste more time struggling with its quirks than you would have if you'd just picked up a general purpose 2D engine and made an RPG with that instead.

>>15159817

Thanks.

Any advice on the engine?

Any advice on where to find people to do the sprites/models? It'd be paid of course.

>>15159707

RPGmaker is great if you're making OFF or 7th Stand User and you need a battle system to be functional out of the box but not the main draw of the game or Yume Nikki where you don't use it at all. If you really want to set up RPG combat that's going to be different from what RPGmaker does then it's easier to build it from scratch in a 2D engine like Gamemaker, Love2D or Godot 2D than it is to take RPGmaker apart and rebuild the combat - that's why Shut Up and Jam Gaiden ended up switching to Gamemaker though they started in RPGmaker.

>>15159839

IIRC, Game Maker asks for a license if you sell anything. That still true?

And while Godot doesn't, there was some drama with a language they used or some BS? All I remember is they (allegedly) caved to someone bad or cliquey. In either case I didn't like Godots tutorials because it was like

> Hey this works! We won't tell you why it works right now though. Onto the next bit!

>>15159817

> If you stick with it, you'll waste more time struggling with its quirks than you would have if you'd just picked up a general purpose 2D engine and made an RPG with that instead.

I agree but I don't really plan on sticking with it for more then one game. I've been procrastinating for years and I feel like if I just make anything at this point it will be progress.

>>15159839

At this point I'm locked into rpg maker but like I said I don't really mind using one battle system since it's not far off from what I wanted to do anyway. I probably will go with game maker or godot after this.

>>15159838

I used MV instead of VX MV is supposedly the most customizable of all the RPG Maker engines because it's a fucking JavaScript web application, but modifying it still sucks balls, and my experience is basically what >>15159839 said: the default combat system werks but trying to modify the default behaviour is a pain in the ass, much harder than implementing your own combat system from scratch in another engine. Any experience you gain in RPG Maker will be very specific workarounds for retarded design decisions and won't carry over to other engines, which the developers use to entrap their customer base instead of actually improving the fucking engine.

>>15159854

Yeah, gamemaker has a license so I'm not really sure what the draw of it is when there are pretty good free alternatives out there. Haven't heard anything like that about Godot, though.

>>15160438

>When you dislike [feature] of current engine/framework so you make your own

It's always hell

>>15160452

It will all be worth it. I'm sure of it!

>>15159353

Nibba, you best be planning to pull the camera closer while in an interior.

>>15159353

just scale the environment up a bit

also for the love of dog, please bake the lighting

>>15158715

> http://feedback.wildfiregames.com/report/opengl/

>s3tc has 99% support

>anistrophic texture filtering has only 98%

Well I sure didn't expect that.

>>15161757

Yup, I am. The minecarts are a bit of an afterthought, but it's one of the items that should make my clone a little more unique, I hope

>>15160478

Why even bother with Hooktube now since all it does is embed youtube?

>>15161757

cool shit

what are you making exactly?

>>15161784

Pretty sure it's this guy http://8agdg.wikidot.com/fps-arpg-hybrid

>>15161774

To not give youtube any views or revenue, especially now that they were big enough assholes to force hooktube to gimp itself?

>>15161774

>>15161832

Nevermind, the hooktube thing, just woke up and didn't get the news yet

>>15161770

Oh these carts are for that game?

>>15161784

Original plan was Hexen meets Diablo but that probably doesn't explain current intention too well anymore and I've meandered about a lot. If you saw February's demo day thread, I had an online multiplayer demo.

>>15161832

Yeah that's me, I should really update the wiki page.

>>15158938

>what math subjects do I need to know before getting started with programming?

In general, not really more than + - * /. That said, algebra can be useful for reducing expressions, which sometimes lets you realize that you've been overcomplicating things in the first place. It can help you keep your code clean.

Some specific problems do require math, e.g. if you want to make a physics engine you obviously need to understand the math behind the physics, and even if you're using someone elses engine, understanding the math lets you use it more effectively, and troubleshoot stuff easier too. If you're going to be doing 3D games, learning linear algebra can be pretty useful, especially for enemy behavior.

>>15159622

Steal their ideas, observe their missteps and make yours even better.

>>15159551

if you had just used D you wouldn't have to worry about header hell

>>15162170

There's no such thing you fucking pajeet

>>15162316

>he doesn't know about how fucking bad the C preprocessor bogs down compile time

>that's before C++ bloat

It shows that you haven't worked on a large project where compile time gets worse and worse the more you pull in. Even C++ is considering adding modules to an upcoming standard because they know how much of an ancient kludge their system is. However, even in C and C++ you can get a speedup by using a faster preprocessor such as warp, which is written by the creator of D.

>>15163152

Here's a tip I wish I could've learned when I started using unity.

Instead of using tags, use different layers, and make certain layers interact with certain others. This way you don't have to do it via script and you don't need to manage random tags or strings.

(this also works with filtering out certain colliders for raycasts and spherecasts)

>>15162823

I've worked on plenty big projects before, except we had proper code standards which included various rules to keep compile times down plus an in-house compiler because every big gamedev company wants their own The Best Shit™. Except that has nothing to do with header hell anyway, that term is purely used by either retards who don't know how to manage headers efficiently or lazy faggots. And it has even less to do with the post you originally quoted, which was just an anon being happy about his new code compiling.

>>15163361

Ah I see.

Tags are probably fine for that then, but it would probably still be good if you deactivated collisions with all other things that can't be ally, enemy or ignore.

I mean I doubt it would have that much effect on the optimization at all either way, but you might as well do it.

>>15163223

>recompiling the header for every file that uses it

Yes, this is completely fine.

>>15164016

>not precompiling any header that is used in many files

Yes, you're completely retarded.

>>15162823

Well here is a data point. I have a 26k lines of code project in 55 C++ files and 44 header files. I'm using Qt's nmake with a mingw64 version to build (multi-threaded). It takes ~ 55 seconds to build from clean. I'm not using any precompiled headers. My header situation is kind of a mess. Every library I'm using is statically linked. Exception handling is disabled. I don't think that's too bad, or slows me down. When I'm working I'm usually only recompile 2-3 source files so compile time is < 10 seconds.

I suppose if you're a guess-and-check style programmer, don't know how to manage headers (include everything everywhere, "just to be sure"), and don't know how to use a debugger.. yes, it could be a problem.

>>15164831

You really don't need to do any of that.

>>15164842

I kinda have to, since SFML doesn't provide any sprite sorting out of the box… Being able to batch my textures and group draw calls by that or depth is going to be very helpful

>>15164855

What language are you using?

>>15164093

>have to use implementation specific features to not compile the same shit over and over again

Headers sure aren't an archaic paradigm. You really got me there.

>>15164967

SFML via C#

>>15165265

I was afraid you were using Java

>>15165296

Also, I'm willing to take any advice on how to do this more efficiently. I can barely find any info on this so I assume it's something that OpenGL probably does behind the scenes?

>>15165296

This is called vertex indexing and I believe it's fairly low level. Even if it's not provided you can make do with a pair of arrays yourself, one for the vertices and one for the indices, in sets of 3

>>15165296

>implement a hash table

surely the c++ standard library has one

also isn't an array sufficient?

>>15165296

>why people use C++

Wait until you figure out why people use Java.

>>15165506

It would be trivial if I just had to take into account an array of vertices and find unique ones. The issue is that I'm basically looking at two arrays representing the index to vertex position data and index to texture coordinates. I need to hash (not necessary but probably most efficient) these two together in order to find what is unique then fill the vertex buffer with only unique values.

The index buffer then has to reference each of those vertices in the vertex buffer in correct order.

>>15165541

Because they're part pooinloo?

>>15165506

>>15165578

and I'm using C.

C++ has all those types.

Oh hey I have an important question.

So if I ask SFML what Texture.MaximumSize is, it returns 16384x16384 (based on my graphics card). If I create an Image object of that size (raw pixel data on the CPU), it lags for a sec then consumes 1,024mb of RAM memory. The debugger also says it throws a memory out of range exception.

However, if I create a Texture object of that size, it does so instantly, and no RAM use is listed - since it exists entirely on the graphics card. Thus, I'm wondering if I can check the amount of graphics memory my game is using, since Task Manager doesn't seem to list it.

>>15165627

Here's the tutorial I'm following. Notice how he uses an unordered map in the last section?

https://vulkan-tutorial.com/Loading_models

The issue is each face has a vertex index AND a texture coordinate index (and a normal map index). These are just plain, ordered arrays. I need to be able to find out when a combination of the vertex index and texture coordinate index are unique and then only record these in the vertex buffer and reference them in the indices buffer that I pass to the graphics pipeline.

It would be trivial to do this if I only had to deal with the vertex indices and not both texture/vertex indices.

>>15165736

I see how it is now, sorry if my response was a kind of dumb tangent on stuff you knew already.

Still it's not terribly difficult, just hash the data and allocate an array of buckets, then use it to index into that array (remember to have a pointer to an expanding array or linked list for each bucket just in case there are collisions unrelated to identical vertices), and store the unique vertices with the indices (just count up on collisions that are real). Then dump all the unique vertices and indices into a new file (with your own custom format) that just lists off the vertex data (with texture coords and normal maps, of course), and then the indices. That way you can do this before runtime so it doesn't actually matter how fast this table is.

>>15164831

Can you fit everything in one texture atlas? That would be ideal if you can do it. If not I guess you could swap them around the minimize texture binds, if you're not using bindless textures.

>>15165341

There are stand-alone tools that will index your verts from an imported model and output an OBJ file. OBJ can include vertex indices along with the actual vert data. If you want to do this yourself though and index your model.. maybe just copy to new array and only add unique vertices to the new array, of course also building the index list as you go. Might as well calculate the tangent and bitangent of each tri as you go if you don't already have it in the OBJ file. If you want sharp or blended normals you will need to insert extra vertices so that you can have different normals at the same spatial position - much the same issue as >>15165618 mentioned with respect to unique texture coordinates.

>>15165736

oh, Vulkan has separate index for texture and normal index? that's pretty nice. All my info is OpenGL related so ignore everything above.

>>15165726

Hey so, I realized it literally does not matter.

>Create 1024 textures of 8192x8192 in size

>This is 274,877,906,944 raw bytes of data, or 262,144 mb at most

>My graphics card has 4 gb memory, my toaster from a decade ago still has 1 gb or more, since it runs Win 7 just fine

>260mb is a huge amount of texture memory, but it's only a fraction of the GPU, and I will at most use maybe a dozen textures of half that size

It's like pissing in the ocean, jesus

>>15165790

See >>15165803

Since my toaster supports 8192, I want to support 4096 textures at minimum, and if I can go bigger than that, great. That should avoid alienating any hardware through my optimizations. I'm just dumbfounded, how do modern games end up so fucking bloated? I went out of my way to shit up my gpu just now and didn't even come close.

>>15165775

Thanks. That's precisely what I plan to do. I'm just a bit unfamiliar with hashing/linked lists but I'll figure it out.

>>15165790

It's quite interesting. When I don't repeat vertices, it takes 0.0006 per refresh but with repeat vertices it takes 0.0003. I wondering if this will carry on to improve performance greatly in the future.

>>15165819

>I wondering if this will carry on to improve performance greatly in the future.

Based on what, your stuff you write, or improvements to Vulkan?

>>15165826

I mean that I'm unfamiliar with OpenGL. I imagine there's probably some complex system for indexing vertices/texture coords so I don't know whether vulkan has significant performance gains or what.

>>15165815

>Mega Pies

>cupcakes

>regular cakes

>donuts

>potatoes

>no pies

I feel cheated. Is Mega Pies the brand name for a pastry warmer or something?

>>15165815

>all those perfectly laid out and spaced donuts

Where do you go to get your donuts?

>>15165815

>The total scene is up to 281k tris now

That's a little high for an unfinished scene with no player models. You s>>15161757

hould try simplifying groups of donuts. But if you really want to have detail for each donut for whatever reason, make each donut 400 or so triangles. You wanna aim for at most 1M triangles in the scene.

>>15161757

>how long did you work on the editor/engine?

2-3 or so years with the game included.

>>15165237

>oh noes I have to think about my code when programming

And thus you fall into the lazy faggot camp instead of the too retarded camp. Better make everything dynamically typed since having to think about implementation specific variable types over and over again is a hassle. And add a garbage collector because having to think about my memory is a hassle and archaic. Wait, why am I suddenly using java? Why is my home in India?

>>15166482

Who are you quoting?

>>15166498

<greentext is only for quoting

Alright, I'll use the more appropriately named one next time.

>>15166498

>Who are you quoting?

go back to

>>>/cuckchan/

>>15166027

you're right, I need some pies.

>potatoes

wow my bread model needs some work.

I think the steak house restaurant across the street is owned by a nice eastern European couple. they win the county fair pie bake contest every year. they bake extra bread and pastries and sells them in the convenience store.

>>15166143

can't figure out how to do random jitter with blender array modifier. I'll move & rotate them by hand before exporting.

>>15166447

Thanks. my donuts are in the 300-400 range. they'll be using glDrawElementsInstanced() so not too worried about the # of donuts. I was going to have a stack near the coffee maker too.

I'm also considering using Armory (mentioned by an anon a few threads ago). It has some rough edges but rendering performance seems pretty good. Only problem is I've never used Haxe to program before. I'm struggling to find good examples of game code written in Haxe too. anyone have some examples?

>>15166447

OK, I understand now. I think you mean grouping donuts into single object and deleting the hidden faces. That makes sense, I should do that, and also with some of my other object groups. thanks

>>15166482

>slippery slope

>calls me pajeet again

okay

can anyone here tell me how GPU computation works and whether or not it's applicable for ULTIMATE PARALLELISM of voxelshit? I made a knockoff autismcraft and i wanna see how tiny i can go. im up to 2 million voxels per chunk and the terrain generation is starting to get too slow for me so i thought maybe i can use the graphics card

thanks in advance lads

>>15167172

Maybe have the animation have a reference toward the "desired look direction", so it can smooth into and out of it, keeping its usual movements around said desired direction.

I guess that depends on how your animation works. If it takes a parameter every frame, you could just feed it that look direction, if not, it's going to need to read it in from somewhere.

>>15167408

looks pretty fun already. going to have a skellie "reverse" mode so you can blast hobbits?

>>15167193

Basically, GPU's can't branch.

If your workloads don't require branching, it's fantastic. If they do, assume that for every branch, the computational cost requires you to go through BOTH branches. It goes without saying recursion is impossible too.

>>15167557

Can they use iteration such as while loops, or is it better to think of it as a giant calculator to manage basic FLOPs?

>>15167644

To dive into more exact details:

GPU's have a fuckton of shader cores, which are grouped together in compute units.

The compute units can branch. The shader cores, however, cannot. Meaning that the branching has to be 100% consist amongst all shader cores. This is also referred to as "dynamically uniform".

This means that any meaningful control flow has to be 100% predictable amongst a large group of instances, which often defeats the entire purpose of computation.

So to answer your question, you're allowed to do this:

uniform int loops; // global variable, consistent per draw call

void main() {
    for(int i = 0; i<loops; i++) { // amount of loops is dynamically uniform in this compute unit
        // do actions
    }
    // write results for this shader core
}

But if you do this, you get undefined behaviour:

in int loops; // per-shader core variable

void main() {
    for(int i = 0; i<loops; i++) { // amount of loops is not uniform, so the amount of loops the compute unit chooses is the amount of loops that actually happen
        // do actions
    }
    // write results for this shader core
}

If you've looked at a bunch of shaders, you would notice that some of them DO have if statements in them. These are resolved by having the compute unit step through BOTH branches. That means that if you want branches to be efficient, you should keep them as small as possible.

I think it's more meaningful to use CPU multithreading for huge voxel worlds though. GPU's are literally only good for brute-force straightforward work. CPU's on the other hand have tons of pipelining magic and, most importantly, their ability to branch allows them to utilize complex data structures. If you want extremely high resolution voxel worlds, then data structures like octrees are almost guaranteed to be way more efficient, especially if you have your typical minecraft world where almost half the blocks are air, and the other half is dirt or stone.

>>15167644

>>15167794

To summarize: If/else branches will cause both of them to be executed. Loops must be consistent in the entire branch. And to add: code recursion (functions calling themselves) are entirely impossible.

Additionally, if your shader accesses remote resources (this means textures or shader storage buffer objects, but NOT uniforms themselves) then which resources they access must be dynamically uniform. So you're not allowed to attach an index to indicate which resource you want to pick out of a uniform array.

>>15167891

>Loops must be consistent in the entire branch.

*in the entire compute unit

fug

>>15167172

look into IK

unity has a built in implementation of it if you're using a humanoid rig

otherwise the way it usually works is like this:

have 1 animated skeleton that you never modify and isn't visible

have another skeleton that copies the positions/rotations of the bones in the animated skeleton + IK calculations, and has a renderer

>>15168667

>1. Vulkan (or OpenGL) are implemented in a way that translates better to OOP. C++ is obviously more capable in handling objects, even just by allowing inheritance.

OpenGL/Vulkan translates better to C than C++. They're C API's after all. However, if you want to write game objects with inheritance, C++ will obviously be a better choice.

>2. There is overhead in C++ but I'm starting to think that in time-criticial parts of code, this won't be relevant

Correct. If you're not doing anything retarded in your engine it'll run on a potato anyway. Besides, there's nothing stopping you from rewriting the critical parts in C or even assembly. Or just release the game a few years later when the average computer is faster.

>3. The use of C++ is much more prevalent in any guides/tutorials for graphics programming

If you can't read and understand different programming languages, then maybe you should reconsider programming your own engine for the moment.

>4. I could basically just use C with C++ classes which may possibly improve readibility but is it worth it to betray the C standard?

I recommend against mixing C and C++, purely because the style of code is different.

C is focused to do exactly what you tell it to. It wants you to explicitly say what you want to do, and never does anything more. If you allocate an object, you have to also free that object.

C++ on the otherhand has a ton of code that it'll tend to run behind your back, even taking care of some garbage collection in the process. If you create a vector, then that also incurs allocations. But when the vector falls off the stack or the object owning the vector is deleted, the vector is also cleaned up for you.

Mixing the two means that you'll be writing more explicit code in some parts (C), whilst relying on very implicit behavior in others (C++), which makes it harder to read.

Note that you can always use two language separately. You can write most of the engine in C, produce C++ bindings for it and build all the game play code on top of it in C++. Whether that's good for your engine is something you'll have to decide for yourself. Plan out how you want to break up your engine into smaller parts, and ask yourself what parts would even benefit from OOP at all. Depending on the game you want to make, that can be a lot or even absolutely nothing.

>5. Most people are going to be used to OOP so I'm worried about people being turned off by pure C for future support

You're going to be engine-devving. If you think you can avoid god objects without introducing a unmaintainable amount of smaller objects then you're very wrong.

>6. Plenty of very good libraries related to OpenGL/Vulkan (like GLM) are made for C++

There's also plenty of C libraries to replace those. Or you can port a C++ library or write your own replacement.

tl;dr if you have to ask then you're not good enough at programming for it to matter. Use a language you like, shoot yourself in the foot and learn from your mistakes. By the time you have a half-decent engine going, you'll be proficient in both anyway purely because of the amount of material you'll have to go through.

>>15168882

>C++ on the otherhand has a ton of code that it'll tend to run behind your back, even taking care of some garbage collection in the process

Okay, now explain why people give C# shit for doing that and C++ gets a pass

>>15168903

Because the things that do it are also things you shouldn't be using for gamedev anyway.

>>15168903

Because of the way garbage collection occurs.

C++ only does garbage collection when:

>When the object falls off the stack

>When an object containing the (to be garbage collected object) gets deleted

In other words, doing this:

obj* o = new obj(vars);

You still have to manually clean it up by manually deleting the object as such:

delete o;

C#, on the other hand, does a complete garbage collection every once in a while. The way is does this is by:

>Pause all threads

>Traverse every single object that is global or on the stack, and marking it and it's children (recursively) as used

>After this, every object that isn't marked as used is no longer used, so delete them

>Resume all threads

Of course, stopping your program periodically and traversing literally every instantiated object is expensive, and often causes a frame to take many times longer than the other ones, resulting in a quite poor gameplay experience.

The garbage collection that C# (and Java) uses is amazing for enterprise programs, since you don't have to garbage collect at all! It's just expensive to do, and is guaranteed to cause a laggspike in large applications. This is considered sub-optimal for vidya, which is why everyone shits on it.

C++, on the other hand, garbage collects some objects for you, but not everything. You still have to manually manage a bunch of stuff. It's just a bit less than C, which is convenient. It's not really garbage collection in the complete sense like C#, but it's got performance in that it doesn't have to do a bunch of other shit.

tl;dr C++ garbage collection is free but incomplete whilst C# is complete but causes laggspikes which are really bad for vidya

>>15154904

>>15155383

Reminds me of some vintage stuff.

>>15168967

>The garbage collection that C# (and Java) uses is amazing for enterprise programs, since you don't have to garbage collect at all! It's just expensive to do, and is guaranteed to cause a laggspike in large applications. This is considered sub-optimal for vidya, which is why everyone shits on it.

I'll assume that it doesn't traverse every object, since you could probably optimize references and the object graph as things are created and collected.

However, your post doesn't go into detail about how C#'s GC also promotes certain objects that are long-lived. Essentially, if an object survives one or two GC's, that object and its entire graph get promoted to higher levels that almost never get collected (but eventually still will if they are eligible for collection)

>>15169013

>However, your post doesn't go into detail about how C#'s GC also promotes certain objects that are long-lived.

Because I don't know nor give a shit how which C# implementation optimizes what. I don't program in C#.

I'm just responding with what the difference in theoretical garbage collection approach is and why people hate on C#'s approach. If you were expecting to engage in some asinine discussion about muh perf then you're shit outta luck. Go profile your code instead.

>>15168882

The purpose of making this engine is as a learning experience.

I've realized that I need to take a step back and go through a few more books. I'm just worried about the future. I can't see any jobs in C that aren't embedded systems/electrical engineering related. I'm getting a dual degree in IT CS / Applied Maths. Maybe the work I do now will some day translate to systems programming or processor optimization. I don't know where you find a career in that except in Shenzhen.

>>15169134

Gamedev jobs always look for C++, but the C++ they'll have you write will pretty much be C anyway. Saying you mainly work with C but know C++ as well might actually be more likely to get you a job than the other way around, even though it's not what they ask for in job offerings.

>>15169134

If you're doing it to pad your resume, then you should ask yourself what job you exactly want and learn the skills required for that.

For software engineering in general, you're best off learning the skills required to manage development. Things like version control, automated builds, testing, managing roadmap, stuff like that.

If you want to do gamedev, it's either C flavored C++ as >>15169155 says, or C# because your employer wants you to work in Unity. Anything else means you'd be working in mobile/web. The above mentioned software engineering skills are theoretically useful, but the standards of the gaming industry are so low, it probably wont even register as useful to most studios.

>>15169255

Pro-tip: When managing memory, write your own allocators. Instead of using Malloc everywhere, you should malloc a giant pool of memory, or several pools, all at once then when you want memory grab from this pool of memory.

Malloc is slower than cache misses.This wasn't something I knew when I tried DOD and it's going to take me forever to fix.

>>15168667

>>15169134

OpenGL and Vulkan programs have "Objects" but not OOP. This is because none of the objects in these systems actually have any agency, and are operated on by procedures. I wouldn't worry about other programmers not using your engine because it isn't in C++ (you can link C++ code to C so what is the issue?).

Really what makes me think is, when C can become a burden, for example having to learn how to write a hash table when C++ has one built in, what is better? It's the same thing with GLM. You can write all your math functions yourself, it really isn't difficult and you should know how all of that math works anyway. But it's obviously less of a burden to just use GLM instead. Really if you are making this to challenge yourself, isn't the burden that you have from not having the STL or GLM the purpose of using C? You wouldn't be challenged in this way if you used C++.

>>15169809

The STL is riddle with performance flaws. For example: The hash maps you mentioned group key and value together which rapes cache.

>>15169853

I'm not saying that you can't write a better hash table or a better version of any of those data structures for the task at hand. That's part of the performance difference between C and C++, after all.

>>15169809

There are good C libraries for hash maps of all kinds. C++ comes with some OK data containers (in the STL) but you can get similar for C just not built into a standard library.

I've heard GLM isn't all that great for performance BTW. The MIT license Sony SIMD math library is probably better although not for beginners. GLM's advantage is that it looks and works very much like GLSL math functions so it is very easy and comfortable to use. Honestly though I haven't tried to use basic SIMD techniques like processing std:array's of GLM matrices & vectors in batches to compare to Sony's library, so I don't have direct data either way on actual performance.

I disagree, OpenGL doesn't have "objects". It has a State which controls rendering behaviour and it provides C functions to operate on data that you provide and to manipulate the graphics hardware. It also copies/creates new data but it always returns handles to you - it's your program's responsibility to manage the new data, track and remove it as you deem necessary. The functions and data are very loosely bound (not at all really), and no constructors/destructors for the GL handles to that data.

>>15170422

I am really just using the words that khronos uses to describe certain things in OpenGL, for example textures are an "object" in this system and as such are referred too as objects, you can see here:

https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_texture_object.txt

In this way resources like textures, etc, are called "objects" by the standards and so when I say in OpenGL you have objects that you operate on, it's really just saying you write procedures to operate on resources like textures and VBO's. Really I agree with you that the objects don't satisfy the requirements of OOP, but I don't think that it's wrong to call them objects still, just not in regard to what an object is in OOP.

>>15171149

high IQ

>>15171149

Study anatomy including bone and muscle structure, save references, look at drawing guides because the general idea is the same while the tools are not, realize that art is subjective and that you must realize what your standards are in order to meet them. Set goals, get good.

Also what >>15171158 said.

>>15167950

You beautiful bastard that works

>>15171280

The amount of time and effort put into it dissuades you from being attracted. All you see when you look at it are the steps you took to make it, not the finished result.

>>15161272

can the sun move and have baked lighting?

>>15169399

>Am I missing something or is the Character Controller in Unity unusable garbage?

>At this rate I'll have to write my own implementation

welcome to the club

>>15171002

>>15169399

I don't even think they have a proper download for it anymore honestly

>>15172398

/agdg/ metaphors are always on point

>>15172398

Except when you know how to cook it, you don't need to taste test it. There are plenty of people who can make and enjoy their own meals.

>>15172562

My analogy has some holes. While cooking, you can put off the consumption of your work until you're done, you can't do it while creating visual work, like a drawing or a 3d model. The creation and consumption are simultaneous, unless you can create with closed eyes. Now that I think about it, cooking seems to be more like gamedev, because you could make a game without taste testing it.

>>15172717

Well even then, whenever I listen to my music or look at my art I find myself enjoying it as I would someone else's music/art. So it doesn't seem too unlikely to me that there are people who "enjoy" their work.

>>15172929

If you give it a few months it'll look like someone else's music/art.

>>15172717

>/v/ using a food/cooking metaphor

>Has some flaws

You don't say

>>15173024

wew

>>15173024

I certainly hope he's cleaned up those vagina and anus animations by now. They don't just open up on their own as the dick gets near.

>>15172717

>because you could make a game without taste testing it

>write all your code without compiling

>theoretically finish your game

>hit compile

>despair as the error counter approaches infinity

>>15173024

This is what Ton Roosendaal has in mind as he works on blender.

>>15172717

>because you could make a game without taste testing it.

<Not doing QA

Disturbing

Has anyone here either attempted to or successfully kickstarted/crowdfunded a project without getting stuck with a project that never ends?

Hey /agdg/ can you make me a sandwich?

>>15173198

Give me 12 months, and I should have a sandwich engine made.

>>15171149

Where is this from?

>>15173331

There's really no need to keep the sword straight, the more cartoony the better.

>>15173331

Use real life as reference. I'm not saying you have to copy real life 1 to 1, but understanding how people move and exaggerating from there will give a better end result than not using real life.

You can look into HEMA, in particular saber fighting as that is done with one hand. You don't have to go full HEMA and make all of your sword swings historically accurate but seeing how certain body movements translate into certain sword movements is helpful.

Also pick up a stick and film yourself swinging it. You are the only person who ever has to see these videos so go all out and try your best to swing the sword how your character would swing the sword. Walt Disney would often film actors acting out scenes and use that as reference for his animations.

>>15173045

t. virgin :^)

>>15173783

What's wrong with this? https://docs.unity3d.com/ScriptReference/Quaternion.Slerp.html

>>15173927

I can't say what the industry standard is, but the way I've done it in the past is used IK for the arms and legs, then used FK for the rest of the body. I've never used a spline curve, just a lot of time and elbow grease, checking frequently to make sure everything looks right and fixing stuff when it doesn't.

>>15171311

How do you store these maps ?

>>15174088

Great, that's good to hear that you're steadily improving, your dedication is an inspiration to us all and I was slightly worried that you would think those were good enough and leave it as is. So it scared me a bit thinking that your dedication was slipping

>Finish work

>I feel like working really hard on my game today!

>Set up my environment again and write a dozen lines of boilerplate

>Have a nap

>4 hours later wake up in time for bed for my morning shift

We're all gonna make it lads

>>15174769

>decide I'm going to rewrite everything even though I've barely even started again

Also any advice for retards on data structures for culling renderable entities and collision detection? I am aware of the existence of quadtrees, kd trees, bvh but not sure how to implement these.

>>15174814

Depends on what kind of game you're making.

>>15174868

I dont' know what the context is. It depends entirely and if you are just trying to optimize stuff right now without measuring anything or having any sense of where the bottleneck is, you are wasting time.

>>15174242

What's the polycount for everything?

>>15174868

The second one sure looks a lot more error prone. Do you need this for something or is that a general question?

Speaking of Update(), here is something that may be related to your question: https://blogs.unity3d.com/2015/12/23/1k-update-calls//monobehavior-calls-optimization/

>>15175266

Great stuff. Will that model be used in a game?

>>15175214

547724 triangles on the entire city, but its static geometry, it runs at 70+ fps even without LOD models

The terrain editor doesn't count polygons yet, i will compile the mesh later and check on Unity

>>15176108

got any occlusion culling going?

>>15176217

Not yet, unless my brother activated it, but we will use it

>>15176369

What's your backup plan for if your game commercially fail?

>>15176509

Get a job and keep improving it until it stops failing

This game will succeed at some point, the niche is still not being supplied by any other game

>>15177036

Go with version 1. Stick with fixed function. Everything after 2 is a meme and depricated by Vulkan.

>>15177036

Probably 2.1, depending on your definition of potato maybe 3.x too.

>>15177101

Ideally, I'd like to support computers as old as possible, for curiosity if anything. Since the game will be largely styled after PS1-era games, I don't really need anything too fancy.

The big issue is that I don't have enough experience to know what's really reasonable. I have a couple potatoes with 64mb of video memory on hand, and if I could, I'd love to run it on those, once again, out of curiosity if anything.

>>15177066

Any good sources on 1? Just looking around for tutorials and the like, most are for 3 and up, though I did find this one for 1.

http://www.glprogramming.com/red/

>>15177137

In that case, OpenGL 1.x should be good enough. If you're targetting modern toasters, you'll gain more performance through using Vulkan and newer OpenGL versions wisely.

>>15177153

That's something to keep in mind, damn. Most of the playerbase will probably use modern-ish hardware at the least. Would OpenGL 2 be an adequate tradeoff, or is the performance enhancement limited to 3 and up?

Is the performance difference really that big, also?

>>15177036

Depends on how potato the potato is.

In terms of meaningful versions, consider the major number and highest minor variant. So 1.5, 2.1, 3.3 and 4.7. Each major version indicates new features being introduced that require new hardware:

>2: shaders

>3: deferred rendering (render-to-texture, feedback buffer)

>4: tessellation

Ask yourself what features you want to support first. 3.3 is often a favorite since it's the first version that standardized a lot of nonsense, but 2.1 is fine too as it allows you to customize the shader pipeline. 3.3 is mostly interesting as it allows you to do deferred rendering, making multiple lights and shadows significantly cheaper.

You probably don't need tessellation, so 4.x can be tossed out the window.

If you want to know what supports what, simply visit wikipedia:

https://en.wikipedia.org/wiki/List_of_AMD_graphics_processing_units

https://en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units

https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units

To summarize, 3.3 is supported on dedicated cards that are a decade old, whilst 2.1 is also supported on integrated that is a decade old. That should be a good enough target, because trying to support systems older than that means you are either dealing with ancient hardware running modern operating systems with shit performance, or hardware running ancient operating systems that will require you to do a lot more work to make your software actually run proficiently.

That last bit is especially awful, since it means you usually end up having to write separate code for different operating systems. And if you're doing that, then you can also consider using different OpenGL versions for different systems, and then your initial question is no longer relevant.

>>15177190

If your OpenGL 2.1 game can run at acceptable framerates on 2.1 hardware, then you don't need to worry about 3.x hardware being able to render it efficiently.

>>15175214

>context

I'm trying to make an AI script. Some of their behaviors are based on character attributes, like attack range. For example, it check whether the targeted enemy is in range on every frame to either punch him or change the state of the AI to pursue the enemy. That's why I'm wondering if it's more efficient for the script to get it from another script that contains various info about the character on every frame or have it kept in a variable inside, where it's updated only when something like changing equipment happens.

>without measuring anything or having any sense of where the bottleneck is, you are wasting time

I'm trying to trail and error this shit. So far it just works but I don't really believe I'll get it right this time so it's a learning experience to see what works.

>>15175315

>link

Very informative, thanks.

As I wrote above, I have particular use for this. But I'm also curious in more general sense for the future.

>>15177313

>loli

Anon..

Looking to make a small 3d multiplayer katamari demacy style game. Recommendations for physics engines?

>>15178177

Jesus, what kind of awful computer do you have?

I bet a $150 computer will get you more performance than you have right now. Or it's a driver issue.

>>15178177

TBH get SDL and make a pixelated platformer instead.

>>15178177

What do you expect, nigger? Fucking pong on unity requires a NASA supercomputer. If you want to live the toaster life, you gotta learn the art of optimization. Unity? Get outta here. I bet even Game Maker would push your computer to its limits.

>>15178243

>Your PC isn't a toaster

I know, that was the joke, that I'm making such a simple game on decent hardware

>It's just fucked

Wait what?

>>15178298

I confused you for the anon saying his game wasn't running

Sorry

>>15178315

Try shutting off some background programs and running it again. If you get the same results and Godot doesn't fare any better, either take >>15178201 's advice or go for some older freetard engines like Irrlicht, Panda3D, and the id Tech family.

>>15178365

Yeah, I'm going to try Godot and see how that goes for me. I hear that if you can't get 3D to work in Godot. Then there's no point in trying

>>15176602

>>15178401

What game are you making? Can I find it on the wiki?

>>15178417

Animu style farm sim with deep mechanics

http://8agdg.wikidot.com/everyday-life

I need to update the wiki, just noticed my page still describes the demo i made instead of the fullgame

>>15171002

Really nice models and detail! I like the windows and the detail work on the bathtub feet.

>>15178177

I used to sometimes get extreme stuttering where Unity's editor ran at 60 fps but freezed for a moment every second, while the exported game exe ran flawlessly. Once when it did this, I disconnected my laptop from the internet, and the editor instantly became smooth as butter. Then the moment I went online again, the stuttering came back. I suspect what happened is that I had a shitty connection, which slowed down all the phoning home Unity does.

I think it's unlikely you have the same problem, but going offline is a thing you can try.

>>15178735

Yes.

This doesn't really apply to replays, but it might be worth considering what would happen if someone pressed and released or released and pressed a button within the same frame. Whether to switch for one frame and back, or to drop input entirely. You'll have to consult your polling or whatever feeds data into the thing you're polling.>>>15174814