New Reply
Name
×
Email
Subject
Message
Files Max 5 files50MB total
Tegaki
Password
[New Reply]


rpg_classes.png
[Hide] (1.2MB, 2532x2000)
1700933429463404.png
[Hide] (4.9KB, 1024x512)
Found or thought of something interesting or helpful related to game development or design? Post it here.
Replies: >>1516
pz_progress_e9c0341760eeb5fd64eda2b61364b9b949bc581e.jpg
[Hide] (958.3KB, 1479x1757)
pz_progress_2d5e6cf4d59a6fbef417bd0a29d9d1baf4cb49dc.jpg
[Hide] (853.5KB, 1305x1550)
pz_progress_831e87d99dd0dfdec1463d2dc381af61f0f1cb8e.jpg
[Hide] (916.3KB, 1479x1757)
Reposting this here:
I saw these in Project Zomboid's blog and found it pretty inspiring. It shows that you don't need to do everything perfectly right away, you can always go back to improve things later when you have more experience/ideas/motivation. MUCH later, considering Zomboid has been in early access like 200 years and they only now did these.
Replies: >>1381 >>1384
tags.png
[Hide] (87.5KB, 1245x1176)
Found an interesting website, it shows how popular different tags are, and how successful games in them are.
https://games-stats.com/steam/tags/?sort=revenue-average

You should take it with a grain of salt though, for example the "Horses" tag seems super popular, but if you open it up then games like Red Dead Redemption, Mount & Blade, Kingdom Come, and Planet Zoo show up. So it's not as if Horse games are popular, it's that there's some popular games that happen to have horses in them.
Replies: >>1382
12.jpg
[Hide] (456.8KB, 2114x716)
I'm very interested about aspects of visual design that are not obvious. Take for instance this. At first glance the right image seems to have better and more "professional" color balance, so you might think it's better. However, I feel much more attracted to explore the world on the left, I'm not really interested in exploring the world on the right.

I'm not sure why this is, maybe the left one just looks more dreamy or happy or fantastical or something, it stimulates your imagination.
Replies: >>1380
sharp.jpg
[Hide] (405KB, 1600x1240)
>>1379
This one is also interesting, the difference is how sharp the background/ground textures are.

I feel like neither is better than the other, it depends on what kind of game you're making. For example, the top style might work for an action game where you want the characters to pop out and for the background to be less distracting, but the bottom style would work better for a sandbox MMO where you want to "live in" and feel more connection with the world.
art_upgrades.png
[Hide] (864.2KB, 1188x855)
>>1377
Here's another image in a similar vein. As far as I remember from when I saved this image, the dev got a proper artist and the right model is what the new art looks like.
muh_marketing.png
[Hide] (212.9KB, 918x564)
>>1378
Also, don't be this guy. Please make a good game before you worry about industry/marketing related things.
Replies: >>1390
challenge_without_reward.png
[Hide] (29.5KB, 768x506)
Here's an interesting thought exercise. There's a challenge where you already have the reward before you get to the challenge. You don't need to go through the work to get the reward, yet the challenge still seems attractive.

It breaks the conventional game design wisdom that player needs to be rewarded for completing things. Why is that? How could you extract this appeal and put it into everything that's in your game?
Replies: >>1386
Stardew_Valley_Trailer_Old_Version.mp4.mp4
[Hide] (15.6MB, 1280x688, 01:54)
>>1377
Here's more: a pre-release version of Stardew Valley. Looks like complete fucking garbage, but he didn't stop working on it and now it's the defining game in it's genre.
1697036805536623.jpg
[Hide] (1.4MB, 2400x1977)
1234235346646.png
[Hide] (2.8MB, 800x1506)
Here's some ideaguy food.
ClipboardImage.png
[Hide] (566.9KB, 860x430)
ClipboardImage.png
[Hide] (346.5KB, 640x360)
>>1383
Fromsoft did it with giantslayer swords if front of various giants.
>>1382
How did it fail though? Is it just not a good game?
Replies: >>1391
>>1390
You'd think the ugly unreadable artstyle would make it obvious.
triangle_performance.png
[Hide] (101.3KB, 916x1540)
Curious note about 3D models: the same surface area with the same number of triangles will perform better or worse depending on how you triangulate it.

It's hard to know how to make use of this knowledge, because even in the presented benchmark, the circle has to have with 40+ triangles before the difference starts to become at all noticeable.
Replies: >>1400 >>1408
>>1398
>2009
Useless data. It works differently for each machine, and each engine, different rigging systems, lod, and modern GPU pipeline will not be able to notice a difference if you add 50k triangles to the scene. Number of polygons is not even important, rendering depends on number of vertices, but only technically, because its rarely ever a problem. 
And most models use quad topology.
Replies: >>1401
>>1400
>modern GPU pipeline will not be able to notice a difference if you add 50k triangles
Would you make every screw and bolt of a car model be 50k triangles just because "GPU won't notice the difference between 50k triangles"? Scenes aren't made of single models, they're made of 1000s of models.

>Number of polygons is not even important, rendering depends on number of vertices
The biggest performance bottleneck will almost always be the fragment shader, and that article specifically talks about how the fragment shader has more load depending on how the triangles are laid out.

>And most models use quad topology.
A quad isn't physically a quad, it's 2 triangles that you're letting the program define for you.
Is this the off-topic thread?
Replies: >>1403 >>1408
>>1402
If you're gonna ask which engine/language/library to use or blogpost about how you lack motivation then no. If you want to discuss a topic then sure.
Replies: >>1408
discuss a topic or post something that you think is interesting*
I wish I could edit posts.
Replies: >>1408
I want to discuss the dilemna of wanting to watch cute girls fight but not wanting to see them hurt each other.
Replies: >>1406 >>1407 >>1408
splatoon-pictures-h5dpa2o3mtrxi5bp.jpg
[Hide] (275.1KB, 1920x1080)
1662210613974045.gif
[Hide] (1.1MB, 200x200)
>>1405
They can fight with something that doesn't hurt. Or your art style can use abstract looney toons -style violence that looks funny/cute instead of painful.
buttfight_1.webm
[Hide] (1.3MB, 1280x720, 00:08)
>>1405
Make them fight with their butts.
>>1398
This is nonsense. It's almost bait-posting, knowing how retarded people get with premature (and unnecessary) optimization here. The reason for the high "performance", if you look closely at the third circle, if that when the vertex count increases, the triangles around the edges quickly become triangles of zero area (so-called degenerate triangles), which are discarded somewhere in the graphics pipeline before rasterization, with no fragments generated for them. Total polygon count aside, how a plane is triangulated is pretty much never a consideration, outside of perhaps vertex lighting, which no one uses anymore. Real reasons to hand-triangulate or at least check (if automatically decimated/LOD geometry) are: to ensure a correct silhouette, ensure it deforms correctly, and/or that it meets a target poly count. Nice "study" though. I'm sure it was quite the buzz on hackernews for all of twenty minutes. What a tool.

>>1402
>>1403
>>1404
Honestly, I abhor the idea of general "dump threads" on boards. What ends up happening is that all discussion goes there, while existing threads for board topics languish at the bottom of the catalog. It promotes a very discord-like attitude to posting where you just tune into one endless stream of bullshit, and your board turns into a secret hangout for a small group of people who talk about whatever the fuck they want. Some people seem to think that slower boards warrant them but I disagree. If you have something to say, post it in the appropriate thread. It's not hard, just check the catalog. If you have something new, make a new thread - thread creation suffers when you have a dump thread. Everyone should be using catalog view anyway, so nobody is going to miss your post because it went in some rarely-used thread; that thread will now be at the top of the catalog for everyone to see. It also helps people filter posts based on thread and topic - they don't need to wade through a whole bunch of unrelated posts every day to see if someone replied to them or posted in a topic they're following, because it will have been bumped. Necro-bumping threads is not an issue either, since hobby boards should not have any "happening" or news threads anyway, threads that will become outdated, irrelevant, and should not be bumped anymore. 

>>1405
>I want to discuss the dilemna of wanting to watch cute girls fight but not wanting to see them hurt each other.
That sounds like you have a question, but not quite one that would warrant its own thread. Luckily we have a thread for those.
Replies: >>1409 >>1412
>>1408
It sounds like you're doing nothing but complaining about everything.
Replies: >>1410 >>1411
>>1409
Well you sound like a triggered faggot. Something in my post strike a nerve with you? Also, your contribution to the thread is noted and appreciated. Keep it up.
887e6a15d3b0d72fe24afdaf4884f4adf9a90ca56cacd46cb5e890f7ccfacdfc.jpg
[Hide] (216.5KB, 956x720)
>>1409
>>1408
>board turns into a secret hangout for a small group of people who talk about whatever the fuck they want.
You don't need to worry, /v/ on the webring isn't fast enough for that. Besides, there's already /kohi/ and /digi/ for off-topic bullshit.
https://www.youtube.com/watch?v=Fy0aCDmgnxg
Old video about making your game "juicy", it's 12 years old but still a lot of games feel very bland and static.

I often keep forgetting to think about this stuff too, the only thing I have baked in my intuition is that interactive things should immediately react when it's interactable (for example when mouse is over a button).
https://youtube.com/watch?v=fA8c1heR2-s
Blockbench low poly chibi modelling.
8c8668e623f80aa41be1b9381bd6ac1ea4d95d1ce5e1699088009b20369065e1.png
[Hide] (50.6KB, 1346x878)
Was supposed to re-post this here when I made this thread but forgot:
I heard of an interesting idea to help with game design from Jonathan Blow's Braid anniversary podcast (I think #4).

Make a matrix of all the things in your game, and think about what the interaction between those things are, and whether there's something more that could be added, you'd get more mileage from each feature in the game. Pic related, I made a crappy example from Mario. Blue slots are places where you could potentially add new interactions with, for example piranha plant could eat the mushroom, so maybe you'd have to reach the mushroom fast enough in some situations. Mushroom can go down a pipes and sprout back out as a flower. Fireball velocity changes when it bounces on a moving platform.

You could also use it for story writing. For example put all the factions/races into the matrix and write down what they think of each other or how they interact. If there's empty slots, then there's a hole in your lore. In this case you could do both sides, what faction X thinks about faction Y is not the same as what Y thinks about X (for example X looks up to and depends on Y, while Y thinks of X as subhumans but exploit them as useful tools).
cached_chunk_sprite.png
[Hide] (159.6KB, 395x494)
clip.png
[Hide] (261.7KB, 1450x938)
fake_depth.jpg
[Hide] (71.3KB, 1309x723)
I read old Zomboid blogs again and found an interesting technique they're adding into their next big update. Rather than drawing all the sprites and objects every frame, they're rendering a small chunk of the map into a sprite with depth information in it. They can then draw dynamic objects like players and zombies on top of the cached sprite, and those objects can "clip through" the environment as if it was 3D. It's kinda similar to deferred rendering which draws depth/surface information into a texture and adds lights on top of it afterwards.
https://steamcommunity.com/games/108600/announcements/detail/3635004526674526598

I think these kinds of tricks are very insightful even if you don't care about this specific use case. Makes me realize how shallow my view of shaders is since all I ever think about is basic stuff like modifying colors.
blend.png
[Hide] (521.8KB, 979x790)
Tool for visualizing opengl blending modes.
http://andersriggelsen.dk/glblendfunc.php
Replies: >>1432
>>1431
Naicu. Thanks, Anon!
c.png
[Hide] (44.6KB, 832x584)
I've been playing Stardew Valley instead of working on my game, and I think I understood something new about the design.

Most games have some kind of goal, and working towards that goal is what keeps you going. Stardew doesn't really have any kind of goal, instead I would describe it as an "unlocking game". The fun, at least for me, comes from unlocking new things and collecting all the items. It's similar to achievement hunting, except the game's content itself is achievement hunting.

I don't know if the game was intentionally designed with that mind, but I feel like it would be even better if it was. For example you could make some kind of museum or display case for pic related, so you can actually place items in it. Then you could have a self-imposed goal of putting the highest quality item on every slot, every time you obtain a better quality item you could "upgrade" the item in your display case. The game does have a museum, but it's only for artifacts and gems, and you can't customize it other than moving the items.

If the game is focused on this, there probably has to be some kind of reaction from the game when you completed it. Otherwise it will probably make you feel hollow; you finally complete the last thing and then just nothing happens.

I don't know if this alone would be enough to make Stardew a good game though. There's obviously a bunch of other points of appeal about it, like the atmosphere and comfy farm building.
Stardew valley feels like a lesser experience because you don't stop when you're satisfied, you stop when you've got other things to do. It encourages you to not play the game eventually, but without the climactic closure other games offer.
Even minecraft fares better despite it having a similar non-goal (discounting The End) because you can create things in it and that act is more memorable rather than the grinding routine of SV.
I'm so tired.
Replies: >>1476
u2rgfv3d.jpg
[Hide] (156.2KB, 666x562)
>>1475
A 3 word post? Better respond with a wall of text.

I used to do this thing I called "go to bed strategy". The TL;DR is to just go lay in bed, maybe with legs hanging out (it makes me feel like falling sleep isn't my goal), and think about what to do next in your game. You'll probably find out one of the following:
1. You're too physically tired, you'll either fall asleep or just want to go to sleep. Just do it, wake up at night and go to work/school at the end of your awake period if you have to, use your peak energy time on your projects instead of on school/wageslaving. Browsing the internet all day isn't going to give you energy, so why spend the rest of your day on that instead of just regaining that energy by sleeping?
2. Your mind is too preoccupied with something else like a videogame you want to play or boobs you want to touch. If that's the case then play the game or fap or whatever, this should only happen if you genuinely want to do it so you should just do it.
3. You have burnout. Burnout manifests as a total lack of interest, you may even question if you're interested in making games at all and would rather take up hiking as a hobby or do something that you usually don't do. In that case the worst thing you can do is try to force yourself. Give yourself a permission to take a break and forget about gamedev for some days/weeks until your interest starts to resurface, play games or watch movies or go outside or try whatever you feel like trying to do.
4. The idea of working on your game feels uncomfortable. This is a very silly but extremely common problem, sometimes you have a feeling that you want to work on your game but it just feels strangely uncomfortable and you try to distract yourself by browsing the internet or whatever. This has 2 likely causes. The first is that you're trying to do more than you're capable. You need to simplify things, throw away the hard work that you've done on it so far (because it has become a burden that's blocking you) and redo it, take up a smaller side project. The second cause is that you don't know the exact thing you need to do. "Work on my game" isn't a concrete step you can take, neither is "work on X feature". You need to figure out what part of your game you want to work on, and what are the actual steps you need to take to get started, something more like "loop through entities and put the ones that have X into an array", or "make sprites for the thing", or "figure out what buttons are on the UI and where they are".

You may not feel directly interested in working on your game which is easy to mistake as #3, but you can tell the difference by thinking about your game. If you feel like it might be fun to work on it, then it's not #3. In this case fate is in your hands, if there's something you want to do then do that, if not then consider finding some simple thing to do in your game and keep in mind if it's turning into #4.

Sometimes it's hard to tell if I'm in 2 or 3 or 4 because all I want to do is daydream about something like an indestructible robot emerging from an underground lab and starting to kill politicians as they helplessly try to mobilize the army or go to a bomb shelter only to have it all vaporized by overwhelming power.

There's also a type of exhaustion that sleep won't fix. It's not necessarily a problem by itself, I can work on some easy stuff like ideas or mockups in that state, but it's often combined with #3 or #4 which makes it much more complicated. It hasn't happened to me for a while so I don't remember the exact feeling though, I think I started wanting to do light exercise and go outside more because I felt like it would somehow alleviate this problem. Maybe the reason I haven't felt it for a while is because I started doing pull ups every other day.

One thing that I've learned to try to avoid is what I consider "unhealthy procrastination". Playing a videogame that you want to play could be thought of as "healthy procrastination"; although you're not working on your stuff, you are doing something that you enjoy. Unhealthy procrastination on the other hand is you doing something that you're not even enjoying, like browsing random websites or playing games you don't want to play or reading shitty manga/webtoons. If you find yourself doing it, this is when the go to bed strategy can be very helpful to figure out the problem or to find something better to do. I also sometimes turn off my internet connection because I just feel bad when I notice myself doing it.
Replies: >>1477 >>1478 >>1479
>>1476
Also, #4 may happen repeatedly. Even when you make some progress, you may hit the same problem again of not having an exact step you can take, it will cause you to feel uncomfortable and browse the internet or something to avoid working on the game. I sometimes went to bed multiple times a day to think about what to do and how to do it.
>>1476
>I used to do this thing I called "go to bed strategy". The TL;DR is to just go lay in bed, maybe with legs hanging out (it makes me feel like falling sleep isn't my goal), and think about what to do next in your game.
I've had good experiences with this.  I made it a kind of meditation practice where I tried to visualize the program while doing deep breathing.  Sometimes I'd get hit with the realization that my approach is wrong, like thinking about it away from the terminal givse my brain the latitude to think about the problem more laterally.
>I also sometimes turn off my internet connection because I just feel bad when I notice myself doing it.
I've lately reverted to the hostfile strategy.  Linux/BSD both have /etc/hosts, which is a table of IP address->domain names.  So you add a line like

0.0.0.0    idiotchan.poo

and keep the ability to websearch and deal with email and shit, but the next time you mindlessly try to waste "just a minute or two" pooscrolling on idiotchan you get an error message.  Then you think "oh, right, I wasn't going to waste time until later."
Replies: >>1480
>>1476
POTD
>>1478
>hostfile
I use that too. Windows also has it and it works the same way, it's at C:\Windows\System32\drivers\etc\hosts

Now I only visit the blocked websites when I actually want to check them so much that it feels worth finding and editing the hosts file again, which only happens once every several days. No more habitually typing the address before I even realize that I did it. The only imageboards I haven't blocked are those that I don't perceive as negative in any way, including this one because of /agdg/.
Replies: >>1481
>>1480
>The only imageboards I haven't blocked are those that I don't perceive as negative in any way, including this one because of /agdg/.
Something I appreciate about more obscure places like Trash is the low PPD, checking in only takes a few minutes at most and it's only worth doing a couple times a day or so.
I wonder if it would be practical to release a demo version of your game and record the gameplay.

You could simply record timestamps of all player inputs, and then simulate the entire gameplay based on them on your own computer. Certain aspects of the game must be deterministic, for example you should never use system time for anything like random number seeds, only game time, and game time should either progress in fixed intervals/pattern or you need to record the frame timings.

You could effectively watch tons of people play your game and even fast-forward it. It sounds incredibly useful but I don't think I've ever heard of people doing that, is it really that easy or am I missing something?
>>1482
Modern games often split frame rendering, the event pump, and physics logic into their own threads.  They can also have variable framerates depending on how fast the player's hardware can render.  These factors are tractable when you're writing your own thing from scratch in SDL, but if you're using Godot or some other engine?  Hard to say.

Though if you're making a game that runs in the terminal, you get recording for free with asciinema.  There are sites where you can watch people play Nethack and such.
>>1482
Sounds like you're describing the demo feature found in games such as Quake and Doom, as long as any RNG is fully seeded and you store that initial seed value with the replay it will play back exactly the same every time.
>>1482
Deterministic game is not that unusual, its often used in all of MP games, where you have to anticipate player inputs with network delay. In reality, nothing is really random, so its not really a problem. You can determine every random value for a game from a single seed at the beginning. 
Whole rng is really fucking complex, if you want it to be fair, evenly distributed, etc. but its already solved. 
Still, its a lot of work, for little benefit. If you want to go down this road, its better to aim at something more useful, like MP. Its very similar in principle. 
>framerate and logic 
People are supposed know how to untie game logic from framerate, but everyone still ties them together, in a lot of games.
Replies: >>1488
>>1487
>lot of work, for little benefit
The point was that it's not a lot of work. Obviously setting up a server and sending recordings there and making a playback system is more work, but it's not much.

>untie game logic from framerate
It's way easier to just do both at the same time. For instance if you have an immediate-mode UI, you'll basically have to duplicate all of your UI-related code and keep them in sync whenever you make changes.

If you want to highlight an entity that your mouse is hovering over and click it, you can just do it all in the same loop, but if you want to untie them then you'll need to loop through entities a second time and do weird synchronization. If there's a condition (like distance) for clicking an entity and showing a highlight, you'll need to either check it twice on both loops or create a global variable or add a property to entities.

It adds a lot of complexity and usually you don't really gain much from doing it. I can vaguely imagine it helping with a 3D FPS somehow because maybe your cursor benefits from more precise/consistent movement, but even then I'm not sure.
Replies: >>1489
>>1488
>If you want to highlight an entity that your mouse is hovering over and click it, you can just do it all in the same loop, but if you want to untie them then you'll need to loop through entities a second time and do weird synchronization. If there's a condition (like distance) for clicking an entity and showing a highlight, you'll need to either check it twice on both loops or create a global variable or add a property to entities.
But code for that is always untied, rendering and game logic are separate, you cant simply use "visual" rendered stuff to determine if something is near something else, its not how pipeline works. So, stuff like "hovering over" is (almost) always a frame behind. And games have "low long it takes for hover to register" variables. Input and rendering are completely separate.

And by "too much work" I meant that it require comparable amount of work to making game multiplayer. Its the same process of making everything synchronized. Making demos is a minor gimmick. There are a lot of things which can desynchronize the game. Even simple stuff like version control, its a lot of work to set things up, and make sure every file has correct version, so it will require certain compatibility between versions, or it will make a shitton useless demos. And for compatibility, you will need to plan architecture very far ahead, or make a lot of backwards compatibility features. Its neat, but is it worth all that work, while you can be doing something better, like MP support?
Replies: >>1490 >>1496
>>1489
do_entities () {
	for (entities) {
		move(entity);
		draw(entity);
		if (overlapping(entity, mouse) && distance(entity, player) < interaction_distance) {
			draw_highlight(entity);
			if (mouse_is_down) {
				interact(entity);
			}
			if (mouse_right_is_down) {
				open_entity_popup(entity);
			}
		}
	}
}
VS
logic () {
	for (entities) {
		move(entity);
		if (overlapping(entity, mouse) && distance(entity, player) < interaction_distance) {
			if (mouse_is_down) {
				interact(entity);
			}
			if (mouse_right_is_down) {
				open_entity_popup(entity);
			}
		}
	}
}
rendering () {
	for (entities) {
		draw(entity);
		if (overlapping(entity, mouse) && distance(entity, player) < interaction_distance) {
			draw_highlight(entity);
		}
	}
}

>I meant that it require comparable amount of work to making game multiplayer
No way in fucking hell. Multiplayer is in a completely different universe of difficulty compared to what is effectively adding append_to_file(input_id, timestamp) into your input handler and then adding a branch/toggle somewhere that reads inputs from an array instead of from window events. It technically can't even break through versions because all it does is store inputs.
Replies: >>1491
ClipboardImage.png
[Hide] (838KB, 612x570)
ClipboardImage.png
[Hide] (82.9KB, 498x278)
>>1490
>its easier to do logic and rendering and input handling within a single loop, because its tiny bit less code on a first glance (compared to doing it the same exact way but twice for some reason)
Are you retarded? You think its a good idea to do logic in the middle of draw calls? Or even structure the program this way.
First you handle inputs(preferably on a separate thread), than you do all the game logic, than you render everything. 
>it cant even break, because all it does is store inputs
Ah, good old "it compiles, so it must be working". Someone should tell people working on doom ports, that they dont need 10 different levels of compatibility, with each major patch, because it cant break at all.
Replies: >>1492
>>1491
Just stop talking if you don't know what you're talking about.
Replies: >>1493
e9cffe09b18d88911824aa5287bfd546f2ce873dc334a611711e736fdb4e8078.jpg
[Hide] (94.3KB, 948x671)
>>1492
Literally every article and book I read had the same game loop, and for a very good reasons. 
while(game){
handleinput();
handlelogic();
render();
}
Have you read some indian cooking book with random mess of a code, or you invented it yourself, due to thinking that you are smartest coder in the whole world? You literally dont understand how to turn this into a variable, instead of writing it twice.
		if (overlapping(entity, mouse) && distance(entity, player) < interaction_distance) {

Replies: >>1494
>>1493
>Have you read some indian cooking book with random mess of a code
I write code, not read about it. Logic and rendering need to both happen for a frame to update completely, so I don't see a need to complicate everything by separating them. You can try to convince me if you want to, but I'm not going to do it just because you told me that a book told you to do it.

>You literally dont understand how to turn this into a variable, instead of writing it twice.
Firstly I "literally" said that there's several ways to accomplish it, I'll quote myself:
<you'll need to either check it twice on both loops or create a global variable or add a property to entities.
Secondly it's more complicated no matter what method you choose because if logic and rendering was in the same place then you can just put the code there and don't need any synchronization method or secondary loops at all.
Replies: >>1495
ClipboardImage.png
[Hide] (96.1KB, 559x451)
>>1494
>I write code, not read about it.
Replies: >>1496
>>1482
>record timestamps of all player inputs
I just realized that it may not be quite this simple because how much time is required to process something depends on how fast your computer is.

I can't think of if/where/how it may cause a problem, but one clear issue is with asynchronous multithreading. For example in Starbound you can run into an unloaded chunk and your character will freeze, but that wouldn't happen if your PC was fast enough that the chunk loader thread loaded the chunk before you got to it. Not to mention NPCs will activate when the chunk loads, so they'll load at different times. Maybe you could record frame timings on threads and synchronize the threads somehow, but hard to say without trying.

The same may happen even with synchronous multithreading depending on how your threads/jobs are organized. If there's 2 tasks that affect one another (for example liquid simulation and NPC simulation), the result may be different depending on what order they complete in.

>>1495
You have to realize that I can't read your mind. I'm giving you explanations and code samples to explain why I'm thinking what I'm thinking, but you're just saying the equivalent of "trust me bro or else you're dumb". Just read your own posts, it's just demeaning assertions about how things should be done with no explanation or justification for any of it nor addressing what I'm saying.

You can say X is good and Y is bad but I don't want to hear whatever conclusions you've made or adopted from a book, I care about the reasoning for things. Why is X good? Why is Y bad? What is the process that created that conclusion and is it applicable to me and my game too and not just for the person who concluded that?

Also I ignored it before but I'll address it while I'm still engaging with this shit argument, that you completely lost me at the second paragraph of >>1489 because I have no idea what the fuck you're even talking about and how it relates to the topic. Demo is a minor gimmick? Version control? Files having a correct version? Tons of useless demos? Are you smoking mushrooms or what are you on about? How do any of these relate to recording player input and playing it back? It gives me the impression that you're completely misunderstanding what I'm talking about or don't understand something fundamental about how the game loop or input works. Multiplayer is THE feature that may cause compatibility problems and absolutely needs everyone involved to have the same game version, but recording input is just a series of timestamps and key codes and they'll work as expected as long as you yourself play them back on the same game version that they were recorded with. I can summarize input recording in a sentence, but there's so many requirements to make multiplayer work properly that I don't even want to bother thinking of them all.
Replies: >>1498 >>1499
Oh yeah, what made me think of that timing problem in the first place was loading screens. The amount of game time that passes during a loading screen (or world generation) will be different depending on how fast your computer is.
Replies: >>1498
>>1496
>>1497
Ignore that guy, he's some kind of ESL sperg. As for your recording/playback problem, use frame counts and not timestamps. Use a standard input -> update -> render loop and for each input step, keep a record of the player inputs and the order they come in. You will probably need the time delta per frame as well, for stuff like determining exactly how far a player moved forward by holding the 'w' key for 147 frames or something. Floating point numbers may jam you up, probably better to sacrifice a little accuracy here and there and use integer math for all gameplay and floats only for rendering stuff.
Replies: >>1499 >>1501
ClipboardImage.png
[Hide] (21.1KB, 844x511)
>>1496
>How do any of these relate to recording player input and playing it back?
Because you need all these things to make sure that demo will work. Its not "just record inputs and timing". https://doom.fandom.com/wiki/Demo#Demo_issues
You will need to design the game around the idea, that it will be replayable. It means ensuring that each and every number is deterministic. All of the features required for replays, are required for multiplayer. If you think that its enough to "just record inputs" than you should assume, that it should be enough for MP, just send inputs to other clients, and make them affect multiple characters, right?
Making it is not fucking easy. How many of modern games are perfectly deterministic? How many of them support replay feature? Why do you think that is? Even save/load features often discards a lot of information, and a lot of games prefer to use checkpoints instead of letting players save at any moment. 
>it's just demeaning assertions
>I write code, not read about it.
You personification of Dunning Krueger effect. How do you learn new things, if you dont read?
>you can just put code there...
No, you cannot arbitrary put code there, for no reason.
>or (you) don't understand something fundamental about how the game loop or input works
I dont understand? Its coming from a guy who never reads, and thinks that you can just place things at random, because "that way you need one less loop". 
>Why is X good? Why is Y bad?
Because read a fucking book or a dozen. 


>>1498
>he is a sperg ignore him
>but do as he says input -> update -> render
Nigger.
Replies: >>1500 >>1501
>>1499
You didn't invent the game update loop, nigger. Also, sage for dump thread.
loading.png
[Hide] (18.1KB, 833x464)
>>1498
>use frame counts and not timestamps
It depends a lot on how your timers and game loop and delta times and such work, so it's hard to generalize. As long as you can replicate the exact game tick durations, everything should just work regardless of if you store a frame count or a timestamp. If your game loop has a fixed time step (like 16 milliseconds) then that makes it easier, but if you have a dynamic deltatime-based time step then you'll need to record the deltatimes too.

The complication is just as I mentioned; the number of frames/ticks that pass during a loading screen depends on your computer's power, unless the loading screen is on the same thread as the rest of the game (which will cause the game to freeze during loading). You may be able to solve it by recording timestamps for certain events like "loading started" and "loading finished". Then you can pause the recording playback until loading has finished, that way the loading speed difference is negated. The same may or may not won't work for real-time multithreading problems. Pic related is a crappy illustration.

>floats
I could be wrong but even though floats are imprecise, I think they're very consistent even across CPUs, so the result should always be identical as long as the order and timing of events is the same.

>>1499
>you need all these things to make sure that demo will work
>All of the features required for replays, are required for multiplayer
My game isn't Doom though. There's nothing I can think of in my game that isn't deterministic as long as the inputs and frame times are exactly the same, and there's nothing about input recording or playback (in the way that I imagine it) that is similar to what multiplayer would require.

The way I imagine the input recording playback is that you launch the game with regular keyboard/mouse inputs disabled so you can't control the game, and then simulate input based on what's in the recording at the exact same times/frames. The entire game including menus and saving/loading and closing the game and possibly even game crashes are being simulated as if the player who made the recording is currently playing. The goal is to look at a playtest, so I want to see the entire play session from start to finish including what they're fiddling with in the option menus. Since you can't control the game during playback anyway, you can instead use keyboard to control the playback speed.

You COULD make a more user-friendly playback system if you want players to record and watch each other's gameplay without the playback taking over the whole game, but I haven't thought about what extra considerations that would require.

>How do you learn new things, if you dont read?
By doing. It doesn't mean that everything I learn is correct or perfect, but it gives me reasons to form certain opinions, and since there's first-hand experience behind those opinions, they can't be turned over just by telling me that someone else has a different opinion.
Replies: >>1504
4d5ce1baadce13d9adf369b0f4db0e13370ecdc4bfce89d594c9d92304669497.png
[Hide] (162.7KB, 274x325)
Hold up a second. It just occurred to me that you could use the gameplay recording thing for debugging too. If there's some bug or crash that's hard to catch in action, you could basically play until it happens and then replay that recording as many times as you want and inspect things and even exit the recording so you can play yourself right before the bug happens.
Replies: >>1503
>>1502
Cool idea, Anon.
>>1482
>You could simply record timestamps of all player inputs, and then simulate the entire gameplay based on them on your own computer. Certain aspects of the game must be deterministic, for example you should never use system time for anything like random number seeds, only game time, and game time should either progress in fixed intervals/pattern or you need to record the frame timings.
I did exactly this for leaderboard replays in one of my games. Each run has a seed which is used for prearranging enemies then everything after that was deterministic with frame inputs. Playing them was as simple as disabling player inputs and consuming the replay's instead. There were a few concessions, like >>1501 is talking about, but overall it was easier than I thought it would be.
Some musings/blog.
I think I figured out how to stay most productive in moving forward, without wasting too much time on "temporary" stuff, while making the game solo. 

First, is to make everything I will use into a proper API. And things should not overlap. One part handless all file loading, another handles all rendering, another all gameplay data, etc. 
BUT instead of making feature complete API, I only do it for a minimal viable version. So gui will have only a button, with text, which can be pressed. I (swear) will not make "onRMB, onHover, onDoubleClick, onLongPress, etc" functions, which I would not need, for a very long time (if ever).
Replies: >>1513
>>1509
Not prematurely over-engineering is useful in general. It's good to keep in mind what your plans are so you won't accidentally design things to be difficult to refactor/replace into the final form, but it's almost always better to just do the obvious simple solution rather than trying to build some ultimate "everything" solution. They're good for learning though.

I've made like 3 "ultimate" UI systems with the goal of them being reusable for different projects, but I've re-used any given system at most in 2 projects. The latest system was already made with this knowledge in mind, it's basically just a bunch of helper functions that organize/stretch rectangles, it's meant to be barebones so I can take it in it's entirety into another project and modify all the structs and functions to have whatever functionality I need. Remains to be seen how useful it is.
>>1375 (OP) 
I'm afraid of netcode.
Replies: >>1518
>>1516
Why so?
Replies: >>1519
>>1518
Because I don't know how to do it and it seems like it could be really hard.
Replies: >>1522
>>1519
I think quake's source code has an implementation that you can look at.
I often struggle with art, and I found this thing from Factorio blog to be inspiring. These are actually rotations of the same object, but you could think of them as different designs.

If I wanted to make this kind of display panel item, I'd probably just make a rectangle display and a platform and then be unsure what to do. But this shows that they come up with "pencil sketches" to find the design, and then do the final polished asset afterwards. This sounds obvious but it's so easy to forget, the problem is that I have a tendency to jump straight into some kind of colored pixel art, and forget that I can just draw design sketches, even if my plan is to turn it into pixel art later. It's much easier to design things if you're not autistically tweaking pixels all the time and trying to find the correct color to pick.
displaypanel.jpg
[Hide] (130.7KB, 1120x792)
Gonna upload the image or what?
How much effort would it be to recreate Dark engine's stealth? I'm learning dhewm3
Replies: >>1552 >>1554
>>1551
>How much effort
Relative to what? Seems like regular gamedev stuff to me.
>>1551
>dhewm3
Have you looked at how The Dark Mod does it?
average_summer_day.jpg
[Hide] (28.5KB, 400x393)
>hand sticks to my drawing tablet because of sweat
What's the pro game dev technique to deal with this?
>>1572
Air conditioner.
>>1572
Don't they usually wear those half gloves that loop around the thumb and only cover the last two fingers?
41fT+pYSxLL._SX342_SY445_.jpg
[Hide] (7.5KB, 342x342)
>>1572
>https://www.amazon.com/dp/B018VASU3O
Replies: >>1603
>>1572
>>1591
Definitely the glove.
nightraider.png
[Hide] (233.6KB, 1920x1080)
scav.png
[Hide] (120.1KB, 1280x720)
I've been addicted to Night Raider for over 2 weeks now, and it's making me have second thoughts about my game.

It's crappy in many ways, but it really scratches the completionist hoarder part of my brain. There's a final map that you can only access by first going through a laboratory in the previous map, and the lab also requires a special key card that you can only find rarely (I currently have none, so I can't even do that part let alone the final map). It's really meaningless to grind for the items I haven't gotten yet (I don't even know what kind of things I haven't found yet) because there's nowhere new to go anymore, but I just want them. It takes a really long time to complete those maps properly, I was supposed to work on my game today but the entire day just disappeared somehow.

So then it comes to my game. I think my game would have this exact quality and I can perfectly imagine someone getting stuck on this grinding loop in it, maybe even much worse, it makes me have second thoughts about making my game at all. I really dislike this part of games where I'm done already and don't really want to play, but there's still stuff to grind for and I want it due to a combination of desire to be "truly complete" and autism and sunk cost fallacy and just monkeybrain gibsmedat-ism.

I COULD make my game more linear and quest-based, but the whole game is based on the idea that you go out to find rare things, even more so than Night Raider or other similar games (in which it's usually "too easy" to obtain stuff). It wouldn't be the same game at all if that wasn't the case.

I don't know why I'm posting this. I'm not sure how to proceed so I'm just blogposting I guess. I've been thinking of trying to work on 2 projects at the same time so things won't get monotonous, maybe this is the excuse I needed to do it.
Replies: >>1665 >>1669
dark_patterns.png
[Hide] (50.1KB, 1108x662)
Just found this: https://www.darkpattern.games/patterns.php
It lists different kinds of game design/mechanics that are exploitative or otherwise harmful to the player.

The most interesting "dark patterns" to me are the ones that don't let you play at your own pace or that basically force you to do something (mostly referred to as "Temporal Dark Patterns" in that website). I think a lot of games that don't have any bad intentions have that kind of qualities. Relatedly, Noita and Factorio have a perfect save system where the game basically pauses when you close it, and continues right there when you start it again, I really want that in my game(s) too.

The "Psychological Dark Patterns" are also very interesting, and directly related to >>1626

Another related video that I unironically think should be shown in schools: https://www.youtube.com/watch?v=xNjI03CGkb4
This one is trying to teach you how to use dark patterns, not how to avoid them, but it just feels so obviously slimy and villainous.
Replies: >>1667 >>1668
Wait no, Factorio doesn't auto-save. You can save it anytime anywhere though.
Replies: >>1668
>>1665
Good finds anon, the brazenness of industry people exploiting the especially harmful methods is stunning. All the more reason to develop games that respect your audience.
>>1665
Most of it relevant for freemium games. These are tricks, which lose their efficiency the more you notice them. And some of them related to chink laws, which are designed to combat this kind of crap. 
Its designs to keep player around the game, and increase probability to spend money on it. Pretty sure some crap companies patented "if player pays for something, he wins next 10 matches." Most of this list is amateurish compared to modern money milking schemes. 
https://www.youtube.com/watch?v=o17lBUZgjTs
Note, in this video he didnt even mention all the ways they try to steal your money.

>playing by appointment
If its coop MP game, its basically a necessity to designate play time. And some events have to be timed, or they lose meaning. Like weekend bonuses, or holydays. 
>infinite treadmill
They probably refer to infinitely incremental games, like diablo 3, where its physically impossible to get perfect gear. But if its something like infinite dungeon roguelike, where you cant win, and just climb as far as possible, most people will not consider it to be predatory, just addictive/fun. 
>cant pause
Most MP games. 

At the end of the day, if you dont try to intentionally abuse the player, it should be fine. 
For example, slay the spire (iirc) has daily challenge, which fits a lot of this list, but its just fun way to change things around.
And a specifically tedious mechanic, like inventory management can be turned into a core gameplay feature, like with backup battles. 
>>1666
It autosaves for backup purposes.
Replies: >>1669
farmingpatch.png
[Hide] (93.6KB, 512x350)
>>1668
>if you dont try to intentionally abuse the player, it should be fine
It's not though, there's a lot of things that can be accidentally harmful, as demonstrated here >>1626
Even you seem to mention "weekend bonuses" as if that's not a blatantly abusive thing with no benefit to the player. Holiday events aren't inherently bad because they're a form of celebration and community/culture. But now imagine that you want to make your holiday event even more fun, so you give people 5x XP and make bosses drop unique rare legendary items during Christmas. You might think you're doing people a favor, tons of people log in so clearly people love it, but in reality you just slapped your playerbase with a huge bag of FOMO and made them feel obligated to spend as much of their Christmas as possible inside your game. That may be great for people who have nothing else in their lives and who might have spent it in your game anyway, but it's really abusive towards everyone else.

I've played multiple games that I thought I enjoyed but that made me feel like absolute shit by the end, I think there's some kind of unacknowledged psychological thing where you're gaining satisfaction and motivation because you feel like you're building and working towards something, but then eventually the game's content/progression starts to run out and you realize that it was all fake and you ended up nowhere and accomplished nothing. Rather than saying "that's just the way these games are" and dismissing it, it's much more helpful to acknowledge these things so we can think of potential ways to minimize the negatives so we can make better more fulfilling games.

To give a random example, the farming skill in Runescape encourages you to log in at X hour intervals to replant your crops. You might think "that's just the way it is", but acknowledging that it has a negative effect on the player allows us to think of potential alternatives. Like what if crop growth was tied to something other than time? What if your crops grew X% for every XP you gain and it was explained in lore as some kind of Gaia's energy? That would make you feel like all your actions in the game are more valuable and might make "inefficient but fun" things in the game feel more worthwhile. Or, what if crops had quality levels and the quality kept increasing over time so you get a different (even if less efficient) kind of reward even if you wait 2 weeks? Another example: if you absolutely want to give people a holiday boost, you could give people a holiday themed item that they can use later, or give them X days worth of "holiday energy" that reduces as they play. That way people can get the benefit on their own terms, not on the game's terms.

Separately from all that, there's 2 separate ways to get enjoyment from games: gameplay and rewards. You can grind and grind and hate your life, but you do it because there's a trail of rewards that give you morsels of satisfaction; just a little more and you get rewarded with something again. That might look like a fun game at first and even the developer may think that, but that's ultimately not a good game. Even worse, the good feeling of the reward is always at the end, so your most recent memory is being rewarded which leaves you thinking it was a good game. Making the grind go on forever sounds like good design on paper because it gives "infinite replayability" and therefore "infinite fun", I wonder how many developers would even begin to realize that there is a dark side to that kind of design.

Another way to think about this is that there's a difference between feeling "relief" as opposed to "joy". When you have tasks to complete and XP bars are 80% full and unread notifications, it makes you anxious, and completing them gives you relief from that anxiety. You'll perceive that as a positive feeling even though it's just the game removing a chokehold that it put you into.
Replies: >>1671
Also something like an XP bonus would disincentivize players from celebrating a holiday even in your own game. People who would have otherwise socialized in the holiday themed town square now feel obligated to go grinding for that bonus XP.
Replies: >>1673
>>1669
With that logic all games are evil, because people play them instead of doing something more important. 
And if seeing unread notifications makes you anxious, its not the game fault, you just fucked in the head.
Replies: >>1672
>>1671
I don't think you read the post at all if that's your takeaway.
>>1670
That's a good point. It did occur to me many years ago, but for singleplayer games I just started to change the system date to see thw variations and easter eggs.
It's a shame changing the date is such a pain on linux and BSD.
[New Reply]
88 replies | 42 files
Connecting...
Show Post Actions

Actions:

Captcha:

- news - rules - faq -
jschan 1.6.2