I figure that's mostly just about venting and not looking for advice or feedback per se, but it pokes a few pain points for me so...
A lot of this is going to be about writing because I'm a writer first and foremost.
I think it's important to be skeptical of anyone who claims they know the one true way to succeed in or undertake creative endeavors, no matter how successful they are or convincing they sound. There are a zillion ways to tackle the creative process and they all work for someone.
Stephen King is skilled, but he has a very narrow idea about how to create. The one that always comes to mind is that he says that you can't plot a book in advance without killing it. He writes unplanned until he runs dry and then ends a book. And, like, it's obvious from his endings. He's a discovery writer who falls into discovery writer pitfalls and says there's no other way to write. But there are just as many successful outliners out there as there are discovery writers, who deliver explosive endings but maybe if they're not careful make things feel a bit stodgy and overly structured.
I can't speak to pixel art games in general because I don't see much point to saying anything about any particular kind of game in general, the question's whether you're going to make a game that satisfies you. Whether by being creative or just being a nice familiar little snack for people who like familiar little snacks. Not everything needs to change the world and be completely unheard of. It's okay to just make something pleasant or something that feels unique and worthwhile to you.
I have pretty bad ADHD, tedious work is always going to be a monumental ask for me. But creation isn't just the time spent putting prose on the page or programming; I enjoy the vast majority of the process of creation, not just the idea of having written or having made a game. Putting prose on the page is miserable, all the fidgety little dialogue punctuation I don't use in my day job writing and descriptions I don't care about because I want to get to fun stuff, but I can plan to the point that it's a very brief period of misery--and I actually quite enjoy editing and revision.
It's okay if there's a portion of the work that feels like work. Unfortunately, you can reach a point where you've put off that hard part for so long that it feels like it's all that's left, and you haven't actually done anything, and you just want to skip to the end, and yeah, that might feel like you just want to have written, want to have made a game. But I don't think that feeling is right, or at least, it's not telling the whole story.
I'm also reminded of how Brandon Sanderson talks about writing with writer's block. He points out that readers can never actually tell the difference between the chapters that came out perfectly on the first try as pure joy and the ones that were a miserable slog where he fought for every word and hated every word and was only writing because he was obligated to write that day.
Kupi, I wish I had some clever words of encouragement, but I think I'm in a similar spot.
I've been dabbling in game programming for about a decade, and in that time I've got a bunch of briefly started and abandoned projects, and a single, tiny, game I'd call finished.
I've enjoyed a lot of the programming I've done, but when I stall out I tend to go for quite long before coming back to it.
Thanks for your sympathy, y'all. I was, indeed, not fishing for advice but when you post things people reply. If venting my bile can make people feel like they aren't alone in whatever they're struggling with, that makes it worth it.
My favorite musical instrument is the air-raid siren.
+6
Options
IanatorGaze upon my works, ye mightyand facepalm.Registered Userregular
Sooo instead of making a game I am playing one.
But! It is an early pre-alpha thing that is a clear look into what I will have to deal with. I'm talking save wipes, incomplete assets, major gameplay bits that need rethinking...
If I can't stand to experience it at even this (actually very playable) state I'll have zero hope of realizing my own visions.
Twitch | Blizzard: Ianator#1479 | 3DS: Ianator - 1779 2336 5317 | FFXIV: Iana Ateliere (NA Sarg) Backlog Challenge List
0
Options
Dr. ChaosPost nuclear nuisanceRegistered Userregular
I love how I have all these ideas and energy at work and then when I get home, I'm like "ehhh..maybe in a few hours".
I love how I have all these ideas and energy at work and then when I get home, I'm like "ehhh..maybe in a few hours".
I've got like four sketchbooks, one of which is a quarter-size that I purchased specifically to take with me to work. For the last week or so I've finally been doodling ideas and assets in it.
Twitch | Blizzard: Ianator#1479 | 3DS: Ianator - 1779 2336 5317 | FFXIV: Iana Ateliere (NA Sarg) Backlog Challenge List
I need to schedule my time to be creative, because it's something I enjoy retroactively, however it takes a lot of spoons to pick up, and even more to keep going when things get hard. I wish I was the type of person who just gets consumed by a project, but that's not been true for about 20 years for me...
I was trying to find games similar to what I'm planning out with my sibling, to see what I could learn and what sorts of things appealed to me or annoyed me, and I'm surprised by the lack?
There plenty if we're talking first-person run-and-hide horror or horror walking simulators or first-person action horror, but I'm struggling to find much in the way of first-person survival horror games, like Eternal Darkness or early Silent Hill in first person. The Spooky's House of Jumpscares DLCs are as close as anything gets.
I wonder if I'll end up falling into more actiony gameplay too, especially since this a learning project with a lot of stuff that can roll directly into the bigger thing I want to attempt, a fantasy weird West/Age of Steam King's Field-like.
I've been in a rut myself where I don't really have any clear idea as to what I want to make, mostly caused by work using the same brain parts unlike my previous job which left my creative energy untouched. I've been building tech and systems but I always stop when I hit content creation steps of a project. Fortunately the indie game space is really booming and some ideas that I've always wanted to explore have been implemented in various forms answering any questions I had as to how the idea would look or why this is not a good idea and just leaves the player lost or frustrated. The typical sounds good on paper but when you try it it's just not fun.
Alternatively my youngest (8) is playing around with Unreal Engine and Blender and supporting him by adding functionality is good fun, no need to stress for feel guilty about the state of my project. Let him be the designer and content creator while I just provide him some basic tech to add to his levels like "Dad I want a spinning platform that also follows a path". So far the requests basically cover everything that has ever been done in all 3D platformers ever made. I even have a list of 20 different types of dynamite that needs to be added, I can blame various minecraft youtubers for making videos that boil down to "Today we are trying TnT mods that do..."
I think you have to enjoy the process more than the outcome at least to some extent, just because that's how you actually get things made - especially with larger projects, and games are usually pretty large commitments.
I'm definitely in the camp of having more ideas than I could ever actually make into games, and have to discipline myself to actually work on one thing and get it done, because the ideas in my head are always more fun than the reality of what I'm working on. It helps me to make a todo list of tasks and focus on the enjoyment of checking off the boxes once I finish them. Now I just need to work on not wanting to redo everything I've already done and add more tasks to the list.
I'd idly wondered if unlike third person Soulslike combat, handling first person melee combat as hitscan weapons with very short range might work fine and be less 'technicality more correct but feels more frustrating' than what can happen with actual hitbox collision.
Boot up Lunacid to play it for the first time, since I know it's fairly close to the sort of game I want to make, though unlike its maker I've no interest in accurately simulating King's Field idiosyncrasies or (lack of) balance. Immediately realize that's how its melee works. Not sure how common it is, maybe it's weirder that I didn't realize that's common? But it's funny to me.
That's how Team Fortress 2 handled melee weapons, although that was normally to its detriment due to being networked and a few other idiosyncrasies (like targeting characters' axis-aligned bounding box).
My favorite musical instrument is the air-raid siren.
0
Options
Dr. ChaosPost nuclear nuisanceRegistered Userregular
edited March 21
I thought "man, I'm really bad at mapping out modern cities" but then I remembered Earthbound and feel like I might be overthinking it.
Not that you shouldn't try but nobody will care how realistic your town is down to the last detail as long as they're having fun.
I spent an hour or so working on (the start of) the design document for Project Flying Bunny. I'm trying to be as explicit as possible about every aspect of the project, including a bill of materials for e.g. visual and audio content resources, in order to keep an accurate view of what the project is going to require and keep it from sprawling.
Also, as a matter of personal curiosity, I set out to build the Godot engine from source code. As with the rest of my experience with the engine so far-- surprisingly comfortable! On the Windows side, the prerequisites include only having a relatively modern Visual Studio installation, and a Python 3.6 or higher runtime on the PATH. Then you use Python to install scons (the main build tool they use), take a command line to the codebase (cloned from GitHub), and type "scons target=windows".
... and then wait 35 minutes for the build to finish. Golly but C# has spoiled me with its build times. Still, it all worked out of the box exactly as documented, which is a pleasant change from the sort of build-environment hell you encounter when trying to bootstrap someone else's codebase.
My plan for the coming week is further work on the design document, and perhaps a start on the most basic work-- with an emphasis on getting some amount of the content file work done in parallel with the coding, so it starts to feel like a game WIP as soon as possible.
My favorite musical instrument is the air-raid siren.
Trying to pin down what exactly I'm wanting to aim for with this first-person horror game, so I'll know what specifically I'll need to learn, create, etc.
I was thinking I didn't even want to hit RE levels of combat capability, much less RE4+.
Games at the run-and-hide end of the spectrum are just boring to me, even when they manage to be scary it's like...the nature of the tension makes it boring and forgettable overall? If there are no resources but running, nothing is frightening, but if the resource expenditure isn't cathartic it's just frustrating to me--something like Amnesia's lantern gives me the wrong kind of anxiety while also not being scary. I think games past that into the walking simulator side of the spectrum might actually be more effective at scaring me than running games?
I've actually tended to find that games that have a starker divide, with spooky downtime interspersed with non-spooky high action, like FEAR or even Nightmare House 2, work better for me even though you're more powerful, because you're not powerful in all contexts.
Early Silent Hill is pretty solid for spooky imo. It has the radio to tell you that that it's fight time, though there are also often monsters that won't set it off while laying in ambush, so you're incentivized to pay attention. You can kill everything with a katana or whatever but that's fine, the fighting is almost just a tension management thing--the scary stuff happens between fights.
You'd think you could manage tension with 'chase sequence' being the thing you dread instead of 'fight-or-flight sequence' but it's never worked for me. Maybe because there's no decision-making? Checking every dark corner for something I need to shoot before it gets me has worked pretty well to give me the willies in games where you're quite powerful, like Doom 3 or Riddick, more effectively than anything in Outlast or Amnesia.
So I think that I probably want a strong incentive to look around and take in environmental horror, wondering if you'll need to fight or run, resources that make things feel tense without being irritating, and raising and lowering tension to avoid stagnancy. Also a healthy mix of 'threats' and 'spooky shit' that don't necessarily overlap. Things that can't or don't hurt you directly allow for more imagining, maybe?
edit: I guess if I boiled it down, I think horror is most effective when it expects you to switch modes. Don't let you get in a rhythm, because if your character is the world champion of hide and seek and that's always the solution then even a powerless protagonist doesn't feel powerless. Maybe the specifics of how deadly you are or resource management or whatever aren't as important?
This week I turned up another bit of perf trivia from someone's reported experience in a Reddit post.
Area2D (and the associated physics body) has two boolean values of interest: "monitoring" and "monitorable". These determine, respectively, whether the shape will actively check for collisions and fire signals when other bodies enter or exit them (among others, I think), and whether the shape can be detected by other areas performing such monitoring. The commenter was putting together a bullet hell (or at least experimenting with a large number of bullets in play), and found that they could get nearly twice as many bullets in play before the game got framey by disabling monitorable on one side of the interaction and disabling monitoring on the other. Essentially, it was only necessary for the bullets to try to find the player, or the player to try to find the bullets, but not both, and leaving the unnecessary monitoring state on for the other objects was resulting in a huge number of unneeded physics tests.
I think the way Godot's handling its defaults is justifiable; defaulting either value to false would result in cases where the user is surprised by the need to activate some boolean just to get collision detection working. I thought there might be some way to make the is-monitoring state a combination of both the explicit flag and "is there even any reason to monitor if none of my signals have a subscriber", but I think that would ultimately result in more processing for an obscure case. If you've put an Area2D onto your character, presumably you've done so with the expectation of it colliding with something and reacting to it, so "the user added the node but didn't configure any signals" isn't a case you want to optimize for. Plus, since signals are settable at runtime, you might (for whatever reason) have a case where you set the Exited signal after an Area2D starts overlapping your Area, so it still needs to be monitoring before it has any signals. Better to just trust the user to actually disable things if they know they don't need them then try to find out when you can skip a physics check (and add that performance tax to all operations that do eventually wind up performing the check).
All this to say: by default, Area2Ds perform all possible processing, looking for overlapping areas and allowing other areas to look for them. But so long as your interaction rules can be expressed unidirectionally, you can knock an entire block of physics processing off by deactivating monitoring or monitorable on the appropriate shapes.
My favorite musical instrument is the air-raid siren.
I figured this is something people here might be interested in, going into a bit more detail as to how GPUs process triangles and how you can tank performance without understanding why (tl;dr, small triangles are bad. Having a lot of your on-screen triangles nearing the size of 2x2 pixels will murder performance).
I'm not working on any specific game at the moment, but I am looking at my 2D collision/basic physics code again.
It could resolve collisions either by making the moving object bounce off the surface, or by sliding along the surface. I had to set on objects whether they're bouncy or slidey, which is not ideal. Even a simple physics game like Peggle has a ball either bounce or slide depending on the angle of incidence.
I found a solution: calculate both the bounce and the slide and use the one with the higher velocity.
From some brief testing that works well. Although I need to set up a better test level.
What's working less well is that I have balls sometimes going through walls they're sliding along. I really thought I had fixed that previously.
So I'm taking my first steps into learning Unreal, and I'm wondering...to what extent do devs tend to work with what's provided by the engine versus rolling up their own solutions to, like, character movement or collision or whatever?
I've never once played a game and though oh, this is just an Unreal game, but is that because it's not something that would be apparent or a drawback, because I'm unobservant, or because no one does that...?
So I'm taking my first steps into learning Unreal, and I'm wondering...to what extent do devs tend to work with what's provided by the engine versus rolling up their own solutions to, like, character movement or collision or whatever?
I've never once played a game and though oh, this is just an Unreal game, but is that because it's not something that would be apparent or a drawback, because I'm unobservant, or because no one does that...?
Default lighting and post-processing effects(motion blur) are usually what gives a game engine. It used to be things like texture pop in. Plus there are only so many ways to write a character controller. Unless you manage to pull off something truly never seen before, literally no one is going to care if you wrote your own physics engine or are using Havok/PhysX
Generally the only things that can betray an engine is default presets. So, default gray UI in Unity, the default 3rd person character controller animations and handling in Unreal, things like that.
The thing that I've personally been picking up for years now are particle effects- around UE4 there was a pretty good looking but also recognisable "whoosh, a thousand sparklies fly out and swirl around!" (what I assume is) effect preset, and I've been noticing it over and over ever since then. So many games where their "I pull my magic sword out" effect was that swirl.
There's a UI quirk that I've seen in enough Unity games that I assume it is default behavior.
In scrolling UI elements you can go past the end and it bounces back. This is normal on mobile, but Unity also does it on PC when using the scroll wheel where that is weird as hell. If you keep scrolling the UI oscillates rapidly.
I'm on Ritalin now, which has mixed results. My coping mechanism weren't set up to be productive, is part of that. But I think I might be able to eke out a bit more productivity on the gamedev side of things.
Unity map generator:
So, this generates hexagons of variable shape in a hex grid, with canals and water spaces between the hexagons of land. The hexagons have outlines depending on distance from water, for example (beach, trees, tramway, road, frontyard, house, back of house, garden) . All of this with square tiles, and a hexagon can be 48-512 tiles big depending of what you want and how thick the bundles of lines, how offset the hexagons can be and therefore how oddly shaped they are, etc.
I have the map generator working pretty well. It doesn't have all the features I wanted (canals, bridges), but those can be added.
The system is really fast for large groups of tiles. (Setuptime = 0.8871015 for 16384 squares)
Some of the tricks it uses to be faster is to have a list of prime numbers and pi as a random numbers. It also pools a small list of recently generated tiles. It stores the 6 points that define the hexagons permanently to define the lines, those may be used for 'beyond the horizon' generation, and of course those points are shared between hexagons.
Tiling editor:
Once the map is painted you can edit the tiles.
The smart thing about the editor is that early on I had it scan the project folder for prefabs that are named house01, house01, streetstraight, streetdiagonal1, etc. It then automatically creates objects, both a pool to tile the map, and a line of objects as GUI to select them. It also makes a list of these, with the 01-02-03 added together into a single 'prefab' which can have random variations. As visible in the screenshot below, it even does LOD automatically (the purple cubes show this prefab doesn't have that set)
You can click on the map, shown with simple colour square tiles, and that will replace every similar tile with that prefab. You can select levels of similarity either just the tile type itself, crosswise neighbours or complete neighbour set. And you can have exact angles, random angles, or any angle for the placement.
The class that stores information about the combination of a tile on the map and all of the relevant criteria is called a 'tiling'. Tilings are stored in a list.
Editor GUI:
I have the tiling editor now saving tilings to lists, saving those lists to disk, loading them from disk, editing the saves, and starting to work on editing the lists (mostly to go back and delete bad tiling. Parts are in the Unity editor, parts are on-screen. Eventually it'll all be onscreen, as the editing takes place in runtime.
Loading saved tiling lists:
List editing (still WIP):
If all of this sounds boring, well it was and it took a long time. In my defense, the concept I'm working towards isn't really something I can get off the shelve, and procedural generation it makes possible can go really deep. In the time I've spent on the editor, now 1,5 years, I certainly could have hand-built a whole game map big enough for reasonable user expectations. But only up to a specific depth, however.
The next level will allow to have prefabs constructed procedurally as well. So another editor will allow you to combine prefabs to create houses, shops, gardens, streets with cars on them, etc. That's a nice to have for now.
A must-have is to have the tramways running, a-star navigation, and other things I need for even a simple game.
Once you are able to rapidly generate those things, hand-building stops being faster.
So the 'was this a waste of time' formula starts changing, the more intricate the generation is. At this point, it very much was, and for the first game I plan to make the time lost will be substantial compared to hand-building the map. But for the second and third game down the line, this will no longer be the case. Half a year of development (split out) for a procedurally generated map with these features of control really is pretty good.
OR SO I TELL MYSELF
The roll-your-own GUI was probably a bit ott, but then Unity has a shitty base GUI and the new one type is still very iffy. Doing it all in C sharp might turn out fortuitous if I find myself porting to, say, GODOT.
At the moment, I'm implementing a decision to have biome both as a default tile, able to quickly fill large portions of hexagon and water, and a modifier of the tiling, able to show different streets for different biomes for example.
Follow-up post: what is it for?
Well, the first game has water as its transport medium, but you can think of that water as navigable terrain between the hexagons. When your characters are going along navigable terrain, your game logic doesn't really care about the bits in between, only the character-facing bits.
So you could have a dirt/grass/heath 'navigable terrain' that has a line of tiles transferring into shrubs, into accessible woods, into inaccessible deep woods. But the hexagon on the other side could have mud, shallow water, deep water. The next one may be a village, with a moat, wall, catwalk, ring road, gardens, and a city center.
The logic is easily flipped, too, with the navigable terrain unnavigable rock with hexagonal valleys linked by passes.
But where does it all come from? The idea was to have a varied terrain with limited categories combined in a complex way, unlimited*, with the express intent of making it non-tiled on a macro scale* and limiting the scope of the algoritms*.
-Ulimited: most procedural generators will take a defined area, and then collapse or fill in in specific ways that do not account for the tiles outside that area. My approach can take any coordinate and generate tiles, then take the next door coordinate and generate tiles that line up, without having to know, remember, or generate the neighbours.
-Non-tiled on a macro scale: Here's an easy trick; most of what I did here can be applied to procedurally generate large tile sections, such as bends in the river, ex: straight, left bend, right bend, etc... at a scale much larger than the actual tiles, allowing randomisation of the composing tiles. Or, you can make those macro-tiles by hand. However, this rapidly leads to repetition in *distance* as they all have to line up. We tend to be particularly sensitive to distance, and so we spot the repetition.
This is the reason my the hexagons are all offset on the y axis (vertical in the screenshot). And the way they are drawn, that offset on the y-axis then creates variation across the x-axis and asymmetry.
-The algorithms have limited scope. All they need to know is what the closest nodes are, which are calculated for their random number to get an offset and the linebundle type and selected navigable terrain width. This allows calculation of the position of the horizontal center line, and the coordinates of the splits in the lines. From those coordinates, you get distance from navigable terrain, which then gives you a red tile or a green or default fill, line-bundle style (red-yellow-green or blue-red-red-green) and its breadth.
In other words, each tile uses only a few math operations to be drawn, and a quick reference to the nodes which can have more complex (computationally expensive) randomizing applied. It's so fast that most pooling methods I tried end up slower than simply calculating on the fly.
Sticking with 45° angles makes it possible to use manhattan distance a lot, but it also reduces the number of prefabs I'll need for tiles with diagonals on them.
I've always wondered why there are certain things that developers and deep dive game reviewers seemed to favor more that most players don't like or don't care about--stuff like silent protagonists.
...and then I caught myself thinking I'd make my protagonist silent, because maybe dialogue would break immersion or be a distraction from the atmosphere or...
As I was mulling that over, like within the hour of the realization, I was watching a Game Maker's Toolkit video about Dead Space's design across the series where he seemed to think giving Isaac dialogue in Dead Space 2 was a step down from him being silent, which is the first time I've ever heard that opinion from anyone.
So I'll probably not go with a silent protagonist.
IMHO the main thing to keep in mind with silent vs. voiced protagonists is whether or not the writing (and/or voice acting) is bad. A silent protagonist can be anything the player imagines them to be, but usually that won't include "annoying" or "cringe" or otherwise a "bad character". (cf. Metroid: Other M.)
A bad voiced protagonist can be an outright game-killer. (Just look at the public reaction to Forspoken!) A bad silent protagonist is... well, mostly just kind of bland. On the other hand, a good voiced protagonist elevates the game while a good silent protagonist mostly just stays out of the way.
It highly depends on what type of game you're writing, of course. If there's back-and-forth dialogue then having a voice is arguably a good idea, while if it's just about narration/monologue while clearing levels it could go either way.
Has anyone had any experience with gamedev.tv stuff? theres been a bunch of humble bundles with them recently and its stuff that im kind of on the fence about being interested in.
Posts
A lot of this is going to be about writing because I'm a writer first and foremost.
I think it's important to be skeptical of anyone who claims they know the one true way to succeed in or undertake creative endeavors, no matter how successful they are or convincing they sound. There are a zillion ways to tackle the creative process and they all work for someone.
Stephen King is skilled, but he has a very narrow idea about how to create. The one that always comes to mind is that he says that you can't plot a book in advance without killing it. He writes unplanned until he runs dry and then ends a book. And, like, it's obvious from his endings. He's a discovery writer who falls into discovery writer pitfalls and says there's no other way to write. But there are just as many successful outliners out there as there are discovery writers, who deliver explosive endings but maybe if they're not careful make things feel a bit stodgy and overly structured.
I can't speak to pixel art games in general because I don't see much point to saying anything about any particular kind of game in general, the question's whether you're going to make a game that satisfies you. Whether by being creative or just being a nice familiar little snack for people who like familiar little snacks. Not everything needs to change the world and be completely unheard of. It's okay to just make something pleasant or something that feels unique and worthwhile to you.
I have pretty bad ADHD, tedious work is always going to be a monumental ask for me. But creation isn't just the time spent putting prose on the page or programming; I enjoy the vast majority of the process of creation, not just the idea of having written or having made a game. Putting prose on the page is miserable, all the fidgety little dialogue punctuation I don't use in my day job writing and descriptions I don't care about because I want to get to fun stuff, but I can plan to the point that it's a very brief period of misery--and I actually quite enjoy editing and revision.
It's okay if there's a portion of the work that feels like work. Unfortunately, you can reach a point where you've put off that hard part for so long that it feels like it's all that's left, and you haven't actually done anything, and you just want to skip to the end, and yeah, that might feel like you just want to have written, want to have made a game. But I don't think that feeling is right, or at least, it's not telling the whole story.
I'm also reminded of how Brandon Sanderson talks about writing with writer's block. He points out that readers can never actually tell the difference between the chapters that came out perfectly on the first try as pure joy and the ones that were a miserable slog where he fought for every word and hated every word and was only writing because he was obligated to write that day.
I've been dabbling in game programming for about a decade, and in that time I've got a bunch of briefly started and abandoned projects, and a single, tiny, game I'd call finished.
I've enjoyed a lot of the programming I've done, but when I stall out I tend to go for quite long before coming back to it.
But! It is an early pre-alpha thing that is a clear look into what I will have to deal with. I'm talking save wipes, incomplete assets, major gameplay bits that need rethinking...
If I can't stand to experience it at even this (actually very playable) state I'll have zero hope of realizing my own visions.
Twitch | Blizzard: Ianator#1479 | 3DS: Ianator - 1779 2336 5317 | FFXIV: Iana Ateliere (NA Sarg)
Backlog Challenge List
I've got like four sketchbooks, one of which is a quarter-size that I purchased specifically to take with me to work. For the last week or so I've finally been doodling ideas and assets in it.
Twitch | Blizzard: Ianator#1479 | 3DS: Ianator - 1779 2336 5317 | FFXIV: Iana Ateliere (NA Sarg)
Backlog Challenge List
There plenty if we're talking first-person run-and-hide horror or horror walking simulators or first-person action horror, but I'm struggling to find much in the way of first-person survival horror games, like Eternal Darkness or early Silent Hill in first person. The Spooky's House of Jumpscares DLCs are as close as anything gets.
I wonder if I'll end up falling into more actiony gameplay too, especially since this a learning project with a lot of stuff that can roll directly into the bigger thing I want to attempt, a fantasy weird West/Age of Steam King's Field-like.
Alternatively my youngest (8) is playing around with Unreal Engine and Blender and supporting him by adding functionality is good fun, no need to stress for feel guilty about the state of my project. Let him be the designer and content creator while I just provide him some basic tech to add to his levels like "Dad I want a spinning platform that also follows a path". So far the requests basically cover everything that has ever been done in all 3D platformers ever made. I even have a list of 20 different types of dynamite that needs to be added, I can blame various minecraft youtubers for making videos that boil down to "Today we are trying TnT mods that do..."
I'm definitely in the camp of having more ideas than I could ever actually make into games, and have to discipline myself to actually work on one thing and get it done, because the ideas in my head are always more fun than the reality of what I'm working on. It helps me to make a todo list of tasks and focus on the enjoyment of checking off the boxes once I finish them. Now I just need to work on not wanting to redo everything I've already done and add more tasks to the list.
Boot up Lunacid to play it for the first time, since I know it's fairly close to the sort of game I want to make, though unlike its maker I've no interest in accurately simulating King's Field idiosyncrasies or (lack of) balance. Immediately realize that's how its melee works. Not sure how common it is, maybe it's weirder that I didn't realize that's common? But it's funny to me.
Not that you shouldn't try but nobody will care how realistic your town is down to the last detail as long as they're having fun.
Index cards
http://www.fallout3nexus.com/downloads/file.php?id=16534
Only two things to mention this week.
I spent an hour or so working on (the start of) the design document for Project Flying Bunny. I'm trying to be as explicit as possible about every aspect of the project, including a bill of materials for e.g. visual and audio content resources, in order to keep an accurate view of what the project is going to require and keep it from sprawling.
Also, as a matter of personal curiosity, I set out to build the Godot engine from source code. As with the rest of my experience with the engine so far-- surprisingly comfortable! On the Windows side, the prerequisites include only having a relatively modern Visual Studio installation, and a Python 3.6 or higher runtime on the PATH. Then you use Python to install scons (the main build tool they use), take a command line to the codebase (cloned from GitHub), and type "scons target=windows".
... and then wait 35 minutes for the build to finish. Golly but C# has spoiled me with its build times. Still, it all worked out of the box exactly as documented, which is a pleasant change from the sort of build-environment hell you encounter when trying to bootstrap someone else's codebase.
My plan for the coming week is further work on the design document, and perhaps a start on the most basic work-- with an emphasis on getting some amount of the content file work done in parallel with the coding, so it starts to feel like a game WIP as soon as possible.
I was thinking I didn't even want to hit RE levels of combat capability, much less RE4+.
Games at the run-and-hide end of the spectrum are just boring to me, even when they manage to be scary it's like...the nature of the tension makes it boring and forgettable overall? If there are no resources but running, nothing is frightening, but if the resource expenditure isn't cathartic it's just frustrating to me--something like Amnesia's lantern gives me the wrong kind of anxiety while also not being scary. I think games past that into the walking simulator side of the spectrum might actually be more effective at scaring me than running games?
I've actually tended to find that games that have a starker divide, with spooky downtime interspersed with non-spooky high action, like FEAR or even Nightmare House 2, work better for me even though you're more powerful, because you're not powerful in all contexts.
Early Silent Hill is pretty solid for spooky imo. It has the radio to tell you that that it's fight time, though there are also often monsters that won't set it off while laying in ambush, so you're incentivized to pay attention. You can kill everything with a katana or whatever but that's fine, the fighting is almost just a tension management thing--the scary stuff happens between fights.
You'd think you could manage tension with 'chase sequence' being the thing you dread instead of 'fight-or-flight sequence' but it's never worked for me. Maybe because there's no decision-making? Checking every dark corner for something I need to shoot before it gets me has worked pretty well to give me the willies in games where you're quite powerful, like Doom 3 or Riddick, more effectively than anything in Outlast or Amnesia.
So I think that I probably want a strong incentive to look around and take in environmental horror, wondering if you'll need to fight or run, resources that make things feel tense without being irritating, and raising and lowering tension to avoid stagnancy. Also a healthy mix of 'threats' and 'spooky shit' that don't necessarily overlap. Things that can't or don't hurt you directly allow for more imagining, maybe?
edit: I guess if I boiled it down, I think horror is most effective when it expects you to switch modes. Don't let you get in a rhythm, because if your character is the world champion of hide and seek and that's always the solution then even a powerless protagonist doesn't feel powerless. Maybe the specifics of how deadly you are or resource management or whatever aren't as important?
This week I turned up another bit of perf trivia from someone's reported experience in a Reddit post.
Area2D (and the associated physics body) has two boolean values of interest: "monitoring" and "monitorable". These determine, respectively, whether the shape will actively check for collisions and fire signals when other bodies enter or exit them (among others, I think), and whether the shape can be detected by other areas performing such monitoring. The commenter was putting together a bullet hell (or at least experimenting with a large number of bullets in play), and found that they could get nearly twice as many bullets in play before the game got framey by disabling monitorable on one side of the interaction and disabling monitoring on the other. Essentially, it was only necessary for the bullets to try to find the player, or the player to try to find the bullets, but not both, and leaving the unnecessary monitoring state on for the other objects was resulting in a huge number of unneeded physics tests.
I think the way Godot's handling its defaults is justifiable; defaulting either value to false would result in cases where the user is surprised by the need to activate some boolean just to get collision detection working. I thought there might be some way to make the is-monitoring state a combination of both the explicit flag and "is there even any reason to monitor if none of my signals have a subscriber", but I think that would ultimately result in more processing for an obscure case. If you've put an Area2D onto your character, presumably you've done so with the expectation of it colliding with something and reacting to it, so "the user added the node but didn't configure any signals" isn't a case you want to optimize for. Plus, since signals are settable at runtime, you might (for whatever reason) have a case where you set the Exited signal after an Area2D starts overlapping your Area, so it still needs to be monitoring before it has any signals. Better to just trust the user to actually disable things if they know they don't need them then try to find out when you can skip a physics check (and add that performance tax to all operations that do eventually wind up performing the check).
All this to say: by default, Area2Ds perform all possible processing, looking for overlapping areas and allowing other areas to look for them. But so long as your interaction rules can be expressed unidirectionally, you can knock an entire block of physics processing off by deactivating monitoring or monitorable on the appropriate shapes.
Need to concoct a scheme with a game where it only takes place in an underground tunnel system, a space station or the prehistoric era.
"A big part of my story is you have to kill a cave man who is trying to invent houses."
It could resolve collisions either by making the moving object bounce off the surface, or by sliding along the surface. I had to set on objects whether they're bouncy or slidey, which is not ideal. Even a simple physics game like Peggle has a ball either bounce or slide depending on the angle of incidence.
I found a solution: calculate both the bounce and the slide and use the one with the higher velocity.
From some brief testing that works well. Although I need to set up a better test level.
What's working less well is that I have balls sometimes going through walls they're sliding along. I really thought I had fixed that previously.
I've never once played a game and though oh, this is just an Unreal game, but is that because it's not something that would be apparent or a drawback, because I'm unobservant, or because no one does that...?
Default lighting and post-processing effects(motion blur) are usually what gives a game engine. It used to be things like texture pop in. Plus there are only so many ways to write a character controller. Unless you manage to pull off something truly never seen before, literally no one is going to care if you wrote your own physics engine or are using Havok/PhysX
The thing that I've personally been picking up for years now are particle effects- around UE4 there was a pretty good looking but also recognisable "whoosh, a thousand sparklies fly out and swirl around!" (what I assume is) effect preset, and I've been noticing it over and over ever since then. So many games where their "I pull my magic sword out" effect was that swirl.
In scrolling UI elements you can go past the end and it bounces back. This is normal on mobile, but Unity also does it on PC when using the scroll wheel where that is weird as hell. If you keep scrolling the UI oscillates rapidly.
I'm on Ritalin now, which has mixed results. My coping mechanism weren't set up to be productive, is part of that. But I think I might be able to eke out a bit more productivity on the gamedev side of things.
Unity map generator:
So, this generates hexagons of variable shape in a hex grid, with canals and water spaces between the hexagons of land. The hexagons have outlines depending on distance from water, for example (beach, trees, tramway, road, frontyard, house, back of house, garden) . All of this with square tiles, and a hexagon can be 48-512 tiles big depending of what you want and how thick the bundles of lines, how offset the hexagons can be and therefore how oddly shaped they are, etc.
I have the map generator working pretty well. It doesn't have all the features I wanted (canals, bridges), but those can be added.
The system is really fast for large groups of tiles. (Setuptime = 0.8871015 for 16384 squares)
Some of the tricks it uses to be faster is to have a list of prime numbers and pi as a random numbers. It also pools a small list of recently generated tiles. It stores the 6 points that define the hexagons permanently to define the lines, those may be used for 'beyond the horizon' generation, and of course those points are shared between hexagons.
Tiling editor:
Once the map is painted you can edit the tiles.
The smart thing about the editor is that early on I had it scan the project folder for prefabs that are named house01, house01, streetstraight, streetdiagonal1, etc. It then automatically creates objects, both a pool to tile the map, and a line of objects as GUI to select them. It also makes a list of these, with the 01-02-03 added together into a single 'prefab' which can have random variations. As visible in the screenshot below, it even does LOD automatically (the purple cubes show this prefab doesn't have that set)
You can click on the map, shown with simple colour square tiles, and that will replace every similar tile with that prefab. You can select levels of similarity either just the tile type itself, crosswise neighbours or complete neighbour set. And you can have exact angles, random angles, or any angle for the placement.
The class that stores information about the combination of a tile on the map and all of the relevant criteria is called a 'tiling'. Tilings are stored in a list.
Editor GUI:
I have the tiling editor now saving tilings to lists, saving those lists to disk, loading them from disk, editing the saves, and starting to work on editing the lists (mostly to go back and delete bad tiling. Parts are in the Unity editor, parts are on-screen. Eventually it'll all be onscreen, as the editing takes place in runtime.
Loading saved tiling lists:
List editing (still WIP):
If all of this sounds boring, well it was and it took a long time. In my defense, the concept I'm working towards isn't really something I can get off the shelve, and procedural generation it makes possible can go really deep. In the time I've spent on the editor, now 1,5 years, I certainly could have hand-built a whole game map big enough for reasonable user expectations. But only up to a specific depth, however.
The next level will allow to have prefabs constructed procedurally as well. So another editor will allow you to combine prefabs to create houses, shops, gardens, streets with cars on them, etc. That's a nice to have for now.
A must-have is to have the tramways running, a-star navigation, and other things I need for even a simple game.
Once you are able to rapidly generate those things, hand-building stops being faster.
So the 'was this a waste of time' formula starts changing, the more intricate the generation is. At this point, it very much was, and for the first game I plan to make the time lost will be substantial compared to hand-building the map. But for the second and third game down the line, this will no longer be the case. Half a year of development (split out) for a procedurally generated map with these features of control really is pretty good.
OR SO I TELL MYSELF
The roll-your-own GUI was probably a bit ott, but then Unity has a shitty base GUI and the new one type is still very iffy. Doing it all in C sharp might turn out fortuitous if I find myself porting to, say, GODOT.
At the moment, I'm implementing a decision to have biome both as a default tile, able to quickly fill large portions of hexagon and water, and a modifier of the tiling, able to show different streets for different biomes for example.
Well, the first game has water as its transport medium, but you can think of that water as navigable terrain between the hexagons. When your characters are going along navigable terrain, your game logic doesn't really care about the bits in between, only the character-facing bits.
So you could have a dirt/grass/heath 'navigable terrain' that has a line of tiles transferring into shrubs, into accessible woods, into inaccessible deep woods. But the hexagon on the other side could have mud, shallow water, deep water. The next one may be a village, with a moat, wall, catwalk, ring road, gardens, and a city center.
The logic is easily flipped, too, with the navigable terrain unnavigable rock with hexagonal valleys linked by passes.
But where does it all come from? The idea was to have a varied terrain with limited categories combined in a complex way, unlimited*, with the express intent of making it non-tiled on a macro scale* and limiting the scope of the algoritms*.
-Ulimited: most procedural generators will take a defined area, and then collapse or fill in in specific ways that do not account for the tiles outside that area. My approach can take any coordinate and generate tiles, then take the next door coordinate and generate tiles that line up, without having to know, remember, or generate the neighbours.
-Non-tiled on a macro scale: Here's an easy trick; most of what I did here can be applied to procedurally generate large tile sections, such as bends in the river, ex: straight, left bend, right bend, etc... at a scale much larger than the actual tiles, allowing randomisation of the composing tiles. Or, you can make those macro-tiles by hand. However, this rapidly leads to repetition in *distance* as they all have to line up. We tend to be particularly sensitive to distance, and so we spot the repetition.
This is the reason my the hexagons are all offset on the y axis (vertical in the screenshot). And the way they are drawn, that offset on the y-axis then creates variation across the x-axis and asymmetry.
-The algorithms have limited scope. All they need to know is what the closest nodes are, which are calculated for their random number to get an offset and the linebundle type and selected navigable terrain width. This allows calculation of the position of the horizontal center line, and the coordinates of the splits in the lines. From those coordinates, you get distance from navigable terrain, which then gives you a red tile or a green or default fill, line-bundle style (red-yellow-green or blue-red-red-green) and its breadth.
In other words, each tile uses only a few math operations to be drawn, and a quick reference to the nodes which can have more complex (computationally expensive) randomizing applied. It's so fast that most pooling methods I tried end up slower than simply calculating on the fly.
Sticking with 45° angles makes it possible to use manhattan distance a lot, but it also reduces the number of prefabs I'll need for tiles with diagonals on them.
...and then I caught myself thinking I'd make my protagonist silent, because maybe dialogue would break immersion or be a distraction from the atmosphere or...
As I was mulling that over, like within the hour of the realization, I was watching a Game Maker's Toolkit video about Dead Space's design across the series where he seemed to think giving Isaac dialogue in Dead Space 2 was a step down from him being silent, which is the first time I've ever heard that opinion from anyone.
So I'll probably not go with a silent protagonist.
A bad voiced protagonist can be an outright game-killer. (Just look at the public reaction to Forspoken!) A bad silent protagonist is... well, mostly just kind of bland. On the other hand, a good voiced protagonist elevates the game while a good silent protagonist mostly just stays out of the way.
It highly depends on what type of game you're writing, of course. If there's back-and-forth dialogue then having a voice is arguably a good idea, while if it's just about narration/monologue while clearing levels it could go either way.
Steam: https://steamcommunity.com/profiles/76561198004484595