Wow, video 3 of the Vroid studio turned out to be so long, I had to split it into two. The hair editor is one of those key things that sets the application apart from other modelers. So it's now going to be
Hair editor:
Part 1 - Materials and manual strand design
Part 2 - Hair Guides, object groups, animation rigging, and textures
I am reading ECS as Entity Component System. What ECS are you referring to?
Indeed, Entity/Component/System...
However, I am starting to realize that ECS is *really* about the Burst compiler. There are still BIG changes ongoing in the Unity ECS implementation, and a lot of the motivation behind those has to do with Jobs. So, you can't just dip your toes into ECS as a newb. The feedback of both the alpha users and the team tends to talk about things not much above machine code level; which type of arrays can be fed into a parallel process for example, and what alternative would be quicker.
The strategy is very much on the speed of execution. I've seen a bit of news about taking into account developer needs, for example in reinstating bools in 'Pure' ECS, but in general there is no hesitation in throwing 'ways' of doing things overboard if another approach ends up faster. Mesh components seem to have iterated through two completely deprecated versions in the last month, and the way to add components to entities ditto.
Of course, the speed they are achieving through this is why I'm jumping on ECS. But the question is whether 2019 is the year in which you can ship an ECS-based game. Because half of your code may be deprecated right after shipping, and then have fun with your updates...
For example: here they talk about Chunk Iteration which is supposedly the stable baseline. But the Injection which he mentions was deprecated since November.
All of which is why I'm choosing to roll my own (among other reasons, of course).
***
Kupi's Weekly Friday Status Report
I got into Torna: The Golden Country and played that during basically all of my leisure time this week, so I don't have much to report.
I did, at least, have a mild epiphany about how to design parenting between Entities in my architecture. I'd previously planned to use a ParentingComponent to store the parent and children of the Entity to which they belong, but ran into problems from multiple angles: some types of Entities are only parented to rarely and it's wasteful to make every single one keep references around just in case (my engine doesn't yet support adding or removing Components from Entities and doing so will never be cheap), and there's a nasty coordination problem when an Entity gets deleted but some arbitrary set of Entities may have declared it a parent.
So, the plan now is to move the Entity parenting map into my ComponentStorage class, which is my system's main data-storage type. Individual Entities won't track their parenting state; that belongs to a higher-level view of the data. Which makes sense, I think. Entities know their own data and nobody else's.
My goal for next week is to finish Torna. If I manage that, I'll look into implementing Entity parenting again.
My favorite musical instrument is the air-raid siren.
My recent insight that it took me 6 year of hobbyist dev to realize:
When you are working on a game you are really working on two distinct parts. One is a specific game idea you have bouncing around and the other is a generalized game framework that you will (ideally) be taking into your next game project.
Since I didn't realize this until very recently and I've been re-inventing the wheel every time I've opened a new project. For (unity specific) example I've noticed that I have volume controls for every project. They are all stored in a playerpref. I try to make the sound configurable from both the title settings and the in-game pause menu. I've rebuilt sound controls from nothing at least a dozen times and it never occurred to me to make a unity package that I can import into my next project.
My recent insight that it took me 6 year of hobbyist dev to realize:
When you are working on a game you are really working on two distinct parts. One is a specific game idea you have bouncing around and the other is a generalized game framework that you will (ideally) be taking into your next game project.
Since I didn't realize this until very recently and I've been re-inventing the wheel every time I've opened a new project. For (unity specific) example I've noticed that I have volume controls for every project. They are all stored in a playerpref. I try to make the sound configurable from both the title settings and the in-game pause menu. I've rebuilt sound controls from nothing at least a dozen times and it never occurred to me to make a unity package that I can import into my next project.
I've reused my touch screen control script already a few times, but I hadn't thought about making a Unity package out of it.
My recent insight that it took me 6 year of hobbyist dev to realize:
When you are working on a game you are really working on two distinct parts. One is a specific game idea you have bouncing around and the other is a generalized game framework that you will (ideally) be taking into your next game project.
Since I didn't realize this until very recently and I've been re-inventing the wheel every time I've opened a new project. For (unity specific) example I've noticed that I have volume controls for every project. They are all stored in a playerpref. I try to make the sound configurable from both the title settings and the in-game pause menu. I've rebuilt sound controls from nothing at least a dozen times and it never occurred to me to make a unity package that I can import into my next project.
I've reused my touch screen control script already a few times, but I hadn't thought about making a Unity package out of it.
How are unity packages versioned? I can imagine wanting to add features with new games and needing to edit and reimport libraries.
My recent insight that it took me 6 year of hobbyist dev to realize:
When you are working on a game you are really working on two distinct parts. One is a specific game idea you have bouncing around and the other is a generalized game framework that you will (ideally) be taking into your next game project.
Since I didn't realize this until very recently and I've been re-inventing the wheel every time I've opened a new project. For (unity specific) example I've noticed that I have volume controls for every project. They are all stored in a playerpref. I try to make the sound configurable from both the title settings and the in-game pause menu. I've rebuilt sound controls from nothing at least a dozen times and it never occurred to me to make a unity package that I can import into my next project.
I've reused my touch screen control script already a few times, but I hadn't thought about making a Unity package out of it.
Making a package was pretty easy once I actually tried it: Assets-->Export Package and select the objects you want to export. Scripts in your package should be in a namespace so they can always be imported cleanly. And everything should be in a single root folder.
And, importantly, (though not to discourage reuse), one can easily become so focused on making something usable for many applications that it ceases to be usable for any application.
Said the guy who's spent the last two months doing engine programming.
My favorite musical instrument is the air-raid siren.
+5
KoopahTroopahThe koopas, the troopas.Philadelphia, PARegistered Userregular
edited February 2019
I have an idea for a third person shooter mechanic, and I was wondering if anyone has an example of a game doing this already. What if a player had the option for how to aim with their weapon between auto-aim and manual aiming? Without y'know, the generic auto aim toggle in the controller settings. I was thinking something along the lines of this. RPG TPS, projectile weapons have stats like damage, range, accuracy, recoil, etc... Typical stuff. The player can then either manually aim down sights with L2, and shoot with R2 like normal third person shooters, or they could toggle a lock-on sight on the target with L1 and then shoot with R2.
The differences between the two would be:
L2/R2: Manual aiming would heavily negate accuracy as the player is aiming, could add a damage boost or crit based on where the shots hit.
L1/R2: Allow the game to calculate math on if the shots hit or not based on the stats of the weapon (and possibly the player with level-able traits).
The closest thing I can think of is the VATS system from the Bethesda Fallouts, but that feels incredibly slow due to the animations and slow-mo zooms. Maybe Mass Effect, but again that stops the game to take time to target and queue up your shots and abilities before playing all of them at once. I'm talking like, near-instant triggers which after enough levels or loot grinding could make the player character feel like a twitch shooter god. Single bigger enemies could also be designed to be easier to kill with manual shooting instead of the auto shooting to encourage players to get better with 'classic' shooter play styles, but players could also prefer the auto shooting for hordes of enemies for the fear of being swarmed.
Not to mention the accessibility it provides to both hardcore and casual gamers, I feel like a big reason more casual gamers don't play through games like Gears, Uncharted, Tomb Raider, etc... is because they feel like they're not good enough to be able to aim and shoot enemies as they play through the game. This will allow a smaller learning curve for those kind of players and maybe help break them into the genre of shooters.
And, importantly, (though not to discourage reuse), one can easily become so focused on making something usable for many applications that it ceases to be usable for any application.
Said the guy who's spent the last two months doing engine programming.
For all that ME:Andromeda did wrong, there was some cool stuff with some of the weapon mods that works similarly. Specifically some of the Kett research stuff.
If you wanted, you could trade a bit of damage or fire rate or some other stat to replace your weapon fire with tracking shots. That also let you work with them more strategically (enemy in cover? Shoot as far away as you can while still targeting them!) without needing the aiming mechanics. You'd need to balance it out so that player aiming regularly is vaguely similar in power to player not aiming, but it worked.
Sunless Skies also has a great thing in their difficulty settings about amount of auto-aim. It's not a TPS, but it's got a lot in common. On the hardest difficulty, you can find weapons that track, but cannons don't. One difficulty up and all weapons track a little, but you still need to aim. One level up and all shots track generously, so if you're pointed near the right direction, you're fine.
Also I've seen a lot of more recent games (like 2013ish on) that have shooter mechanics have a slider for "auto-aim", rather than a toggle or just having it. So like, I'm playing through RDR 1 right now, and the auto-aim can be set so generously that you basically sort of point near the enemy, hit LT, and it'll snap right to them.
For that matter, RDRs "Deadeye" presents another way of dealing with the problem. New Splinter Cells have a similar thing also. In RDR, there's a meter you have, that's refreshed over time, and refreshes faster with headshots. When you enter that mode, time slows down, and if you basically pass your reticle over the enemy, you'll lock on for a headshot. You can select up to 6 enemies or so, and when you exit the deadeye mode, Marsten just headshots all of the locked-on enemies.
Splinter cell does the stealth-action version, where you can build up a meter, and you can tag enemies. You can then hit a "kill the tagged enemies" button and headshot all of them (this one would need tweaking, in splinter cell I forget the exact mechanics but the idea is that you use it to stay stealthed, rather than using it in combat).
I have an idea for a third person shooter mechanic, and I was wondering if anyone has an example of a game doing this already. What if a player had the option for how to aim with their weapon between auto-aim and manual aiming? Without y'know, the generic auto aim toggle in the controller settings. I was thinking something along the lines of this. RPG TPS, projectile weapons have stats like damage, range, accuracy, recoil, etc... Typical stuff. The player can then either manually aim down sights with L2, and shoot with R2 like normal third person shooters, or they could toggle a lock-on sight on the target with L1 and then shoot with R2.
The differences between the two would be:
L2/R2: Manual aiming would heavily negate accuracy as the player is aiming, could add a damage boost or crit based on where the shots hit.
L1/R2: Allow the game to calculate math on if the shots hit or not based on the stats of the weapon (and possibly the player with level-able traits).
The closest thing I can think of is the VATS system from the Bethesda Fallouts, but that feels incredibly slow due to the animations and slow-mo zooms. Maybe Mass Effect, but again that stops the game to take time to target and queue up your shots and abilities before playing all of them at once. I'm talking like, near-instant triggers which after enough levels or loot grinding could make the player character feel like a twitch shooter god. Single bigger enemies could also be designed to be easier to kill with manual shooting instead of the auto shooting to encourage players to get better with 'classic' shooter play styles, but players could also prefer the auto shooting for hordes of enemies for the fear of being swarmed.
Not to mention the accessibility it provides to both hardcore and casual gamers, I feel like a big reason more casual gamers don't play through games like Gears, Uncharted, Tomb Raider, etc... is because they feel like they're not good enough to be able to aim and shoot enemies as they play through the game. This will allow a smaller learning curve for those kind of players and maybe help break them into the genre of shooters.
Thoughts?
I think you more described the lock on from ocarina of time. You can either aim at a specific spot with bow/slingshot manually or you could lock on and just shoot center of mass.
For all that ME:Andromeda did wrong, there was some cool stuff with some of the weapon mods that works similarly. Specifically some of the Kett research stuff.
If you wanted, you could trade a bit of damage or fire rate or some other stat to replace your weapon fire with tracking shots. That also let you work with them more strategically (enemy in cover? Shoot as far away as you can while still targeting them!) without needing the aiming mechanics. You'd need to balance it out so that player aiming regularly is vaguely similar in power to player not aiming, but it worked.
Sunless Skies also has a great thing in their difficulty settings about amount of auto-aim. It's not a TPS, but it's got a lot in common. On the hardest difficulty, you can find weapons that track, but cannons don't. One difficulty up and all weapons track a little, but you still need to aim. One level up and all shots track generously, so if you're pointed near the right direction, you're fine.
Also I've seen a lot of more recent games (like 2013ish on) that have shooter mechanics have a slider for "auto-aim", rather than a toggle or just having it. So like, I'm playing through RDR 1 right now, and the auto-aim can be set so generously that you basically sort of point near the enemy, hit LT, and it'll snap right to them.
For that matter, RDRs "Deadeye" presents another way of dealing with the problem. New Splinter Cells have a similar thing also. In RDR, there's a meter you have, that's refreshed over time, and refreshes faster with headshots. When you enter that mode, time slows down, and if you basically pass your reticle over the enemy, you'll lock on for a headshot. You can select up to 6 enemies or so, and when you exit the deadeye mode, Marsten just headshots all of the locked-on enemies.
Splinter cell does the stealth-action version, where you can build up a meter, and you can tag enemies. You can then hit a "kill the tagged enemies" button and headshot all of them (this one would need tweaking, in splinter cell I forget the exact mechanics but the idea is that you use it to stay stealthed, rather than using it in combat).
I totally forgot about RDR, I'm pretty sure RDR2 does the exact thing I'm describing if I recall.
I have an idea for a third person shooter mechanic, and I was wondering if anyone has an example of a game doing this already. What if a player had the option for how to aim with their weapon between auto-aim and manual aiming? Without y'know, the generic auto aim toggle in the controller settings. I was thinking something along the lines of this. RPG TPS, projectile weapons have stats like damage, range, accuracy, recoil, etc... Typical stuff. The player can then either manually aim down sights with L2, and shoot with R2 like normal third person shooters, or they could toggle a lock-on sight on the target with L1 and then shoot with R2.
The differences between the two would be:
L2/R2: Manual aiming would heavily negate accuracy as the player is aiming, could add a damage boost or crit based on where the shots hit.
L1/R2: Allow the game to calculate math on if the shots hit or not based on the stats of the weapon (and possibly the player with level-able traits).
The closest thing I can think of is the VATS system from the Bethesda Fallouts, but that feels incredibly slow due to the animations and slow-mo zooms. Maybe Mass Effect, but again that stops the game to take time to target and queue up your shots and abilities before playing all of them at once. I'm talking like, near-instant triggers which after enough levels or loot grinding could make the player character feel like a twitch shooter god. Single bigger enemies could also be designed to be easier to kill with manual shooting instead of the auto shooting to encourage players to get better with 'classic' shooter play styles, but players could also prefer the auto shooting for hordes of enemies for the fear of being swarmed.
Not to mention the accessibility it provides to both hardcore and casual gamers, I feel like a big reason more casual gamers don't play through games like Gears, Uncharted, Tomb Raider, etc... is because they feel like they're not good enough to be able to aim and shoot enemies as they play through the game. This will allow a smaller learning curve for those kind of players and maybe help break them into the genre of shooters.
Thoughts?
I think you more described the lock on from ocarina of time. You can either aim at a specific spot with bow/slingshot manually or you could lock on and just shoot center of mass.
Yeah, these are all good suggestions. I think OoT might be a little more clunky than what I was thinking, since aiming in OoT was super slow and difficult.
Someone's made a 3d engine in pure CSS. (yes, just CSS, no JS or anything. It works much the way you'd expect, except that he put a bunch of extra effort into get lightmaps and shadows to work, and it looks a lot more impressive as a result):
For all that ME:Andromeda did wrong, there was some cool stuff with some of the weapon mods that works similarly. Specifically some of the Kett research stuff.
If you wanted, you could trade a bit of damage or fire rate or some other stat to replace your weapon fire with tracking shots. That also let you work with them more strategically (enemy in cover? Shoot as far away as you can while still targeting them!) without needing the aiming mechanics. You'd need to balance it out so that player aiming regularly is vaguely similar in power to player not aiming, but it worked.
Sunless Skies also has a great thing in their difficulty settings about amount of auto-aim. It's not a TPS, but it's got a lot in common. On the hardest difficulty, you can find weapons that track, but cannons don't. One difficulty up and all weapons track a little, but you still need to aim. One level up and all shots track generously, so if you're pointed near the right direction, you're fine.
Also I've seen a lot of more recent games (like 2013ish on) that have shooter mechanics have a slider for "auto-aim", rather than a toggle or just having it. So like, I'm playing through RDR 1 right now, and the auto-aim can be set so generously that you basically sort of point near the enemy, hit LT, and it'll snap right to them.
For that matter, RDRs "Deadeye" presents another way of dealing with the problem. New Splinter Cells have a similar thing also. In RDR, there's a meter you have, that's refreshed over time, and refreshes faster with headshots. When you enter that mode, time slows down, and if you basically pass your reticle over the enemy, you'll lock on for a headshot. You can select up to 6 enemies or so, and when you exit the deadeye mode, Marsten just headshots all of the locked-on enemies.
Splinter cell does the stealth-action version, where you can build up a meter, and you can tag enemies. You can then hit a "kill the tagged enemies" button and headshot all of them (this one would need tweaking, in splinter cell I forget the exact mechanics but the idea is that you use it to stay stealthed, rather than using it in combat).
I totally forgot about RDR, I'm pretty sure RDR2 does the exact thing I'm describing if I recall.
I have an idea for a third person shooter mechanic, and I was wondering if anyone has an example of a game doing this already. What if a player had the option for how to aim with their weapon between auto-aim and manual aiming? Without y'know, the generic auto aim toggle in the controller settings. I was thinking something along the lines of this. RPG TPS, projectile weapons have stats like damage, range, accuracy, recoil, etc... Typical stuff. The player can then either manually aim down sights with L2, and shoot with R2 like normal third person shooters, or they could toggle a lock-on sight on the target with L1 and then shoot with R2.
The differences between the two would be:
L2/R2: Manual aiming would heavily negate accuracy as the player is aiming, could add a damage boost or crit based on where the shots hit.
L1/R2: Allow the game to calculate math on if the shots hit or not based on the stats of the weapon (and possibly the player with level-able traits).
The closest thing I can think of is the VATS system from the Bethesda Fallouts, but that feels incredibly slow due to the animations and slow-mo zooms. Maybe Mass Effect, but again that stops the game to take time to target and queue up your shots and abilities before playing all of them at once. I'm talking like, near-instant triggers which after enough levels or loot grinding could make the player character feel like a twitch shooter god. Single bigger enemies could also be designed to be easier to kill with manual shooting instead of the auto shooting to encourage players to get better with 'classic' shooter play styles, but players could also prefer the auto shooting for hordes of enemies for the fear of being swarmed.
Not to mention the accessibility it provides to both hardcore and casual gamers, I feel like a big reason more casual gamers don't play through games like Gears, Uncharted, Tomb Raider, etc... is because they feel like they're not good enough to be able to aim and shoot enemies as they play through the game. This will allow a smaller learning curve for those kind of players and maybe help break them into the genre of shooters.
Thoughts?
I think you more described the lock on from ocarina of time. You can either aim at a specific spot with bow/slingshot manually or you could lock on and just shoot center of mass.
Yeah, these are all good suggestions. I think OoT might be a little more clunky than what I was thinking, since aiming in OoT was super slow and difficult.
Slightly less pronounced, Just Cause (at least 2 and 3, haven't played the others) does this. You have a lock to center mass on things near your reticle, but you can still override it by aiming (as in: if you are aiming outside, it will hit COM, otherwise whatever you're pinpointing.) There's also a button to aim down sights.
Some days you make sprites jump around and bump into each other.
Some days you track down a rare bug in the implementation of your iterator for your custom hash table class that makes it sometimes neglect to return the last item or two, but only after doing a fairly specific sequence of adds and removes.
I hate that it took me five hours to figure this out but I'm glad it's solved.
My favorite musical instrument is the air-raid siren.
Edge case bugs always take forever to find unless you get lucky, especially in your own code where your brain keeps overlaying "this is how the code should work", obscuring actual logic. The only ones worse are race condition bugs.
+2
KoopahTroopahThe koopas, the troopas.Philadelphia, PARegistered Userregular
It's usually worse after the fact.
"What the fucking fuck why doesn't this work, this should work 100% of the time."
*finds error after 4 hours*
"Oh, of couuuuuuuuuurse this wouldn't work. I'm a dummy."
The worst part is that I actually thought that I should write a unit test for exactly the kind of case it wound up being... while nodding off one night. And subsequently forgot entirely.
My favorite musical instrument is the air-raid siren.
"What the fucking fuck why doesn't this work, this should work 100% of the time."
*finds error after 4 hours*
"Oh, of couuuuuuuuuurse this wouldn't work. I'm a dummy."
Immediately followed by, "I can't believe I wasted 4 hours on this!"
"Simple, real stupidity beats artificial intelligence every time." -Mustrum Ridcully in Terry Pratchett's Hogfather p. 142 (HarperPrism 1996)
...and then you undo, and undo, and undo, back like twenty iterations, and find out something you broke earlier in the day but didn't manifest itself until the change you made later in the day. Then you have to go back through all the redos but remember where the hell the original mistake was to correct that too.
"Simple, real stupidity beats artificial intelligence every time." -Mustrum Ridcully in Terry Pratchett's Hogfather p. 142 (HarperPrism 1996)
Which is why even solo devs should use Git (or other preferred source control).
And just so we get to Friday with nothing available for the weekly report, a conversation with my roommate (which left me feeling negged, but that's neither here nor there) made me realize that writing my own collection classes might have created a lot of extra work for me ensuring that they play nice with Newtonsoft.Json, which serializes the built-in list and dictionary types in pretty ways but does scary reflection-y things with custom object types. But it turns out that the Newtonsoft guys are geniuses and anything that implements common collection interfaces like ICollection or IDictionary get the pretty printing treatment with no further effort. So my special pooled-backing-store collections were less a waste of time than they feel!
My favorite musical instrument is the air-raid siren.
My favourite is when you fix a bug only to realize that the bug was covering up a much larger and more structural bug that only looked like it was working because the first bug masked it.
Bonus points if the first bug wasn't even really a bug
My favourite is when you fix a bug only to realize that the bug was covering up a much larger and more structural bug that only looked like it was working because the first bug masked it.
Bonus points if the first bug wasn't even really a bug
It matches both position and velocity, so you can grab (and hold) onto moving objects. I attach the player at four points (bright yellow/red spheres in the video) since that keeps the avatar attached to the wall in a pretty stable way.
This was another slow week, for preventable reasons. When I related the story of the custom hash table's iterator sometimes dropping items off the end of the list to my roommate, he made a remark that was well-intended but could be taken to imply that I was wasting my time, which the enemy within latched onto and blew up into a strong sense that I am, in fact, wasting my time, ought to set fire to my custom architecture and go back to Unity or Unreal if I genuinely want to ever finish anything. That feeling has largely passed now but managed to wipe out a couple days' will to be creative in any way, shape, or form. I'm not going to re-litigate that conversation any further, though, so on to the report itself.
In terms of actual game dev work, the one thing I accomplished this week aside from identifying my enumerator bug was crossing one item off the three-stage operation to make the collision detection system react appropriately to entity parenting. Said first item was transforming the version of each entity's Position component from relative space to world space. This will eventually be mirrored in the clean-up / write-back phase, transforming the world-space positions back into relative positions before the Position components get their new values written back. The final and most troubling phase will be to make sure that changes in the position or velocity of a parent collider (as occurs when a blocking interaction happens) are reflected in their child colliders. After that, though, I think the collision detection system is finally fully implemented and I can move on to something else. (... once I perform appropriate testing, naturally.)
As I was discussing my anxieties with another online friend, I happened to mention Shadows Over Volgadan, which is the only full game that I've ever published (that I'll admit to creating, at least). I realized that I still had an old laptop lying around, and on a vague suspicion decided to boot it up. The startup screen made some kind of complaint about the CMOS, but otherwise it booted up to Windows 7 just fine. And lo and behold, not only was there a copy of "Beta 5" of Shadows Over Volgadan, but the full source code as well. So I spent yesterday evening playing through... two-thirds of it. If you want to injure your audiological sensibilities, take a gander at the trailer I made for it back it was first out:
(Don't visit the site at the end. I don't own it any more and actually have no idea what's even there.)
Some miscellaneous notes about the game:
- It's strange for the son of an IBM mainframe engineer, but I didn't actually do any real programming until I was in college. And somehow, three years into that college education, I still hadn't twigged to the idea that I, myself, could set up a program to accept data from files. Everything in Shadows Over Volgadan that didn't already have a "load from file" interface provided by XNA was hard-coded. The terrain? Hard-coded. The progression of enemy waves? Hard-coded. The frame changes in the sprite animations? Hard-coded. That explains why the animation is essentially nothing but keyframes, because updating the animations was a pain in the ass and it never occurred to me that that could possibly be any easier.
- This reaches a comical extreme in the kicking attack, which is one frame of animation as short-ranged projectiles with two frames of animation are emitted.
- There is nowhere near enough shading on the any of the sprites to create a sense of depth.
- Automatic rotation is a tempting trap, but the fact is that it will never look entirely correct with pixel art. If a character needs to rotate, draw sprites for it.
- The collisions are driven by the sprites themselves, because I saw a technique for doing so described on a blog post and didn't consider that simpler forms could possibly work.
- ... and that makes things difficult when some of the enemy attacks are sprites that are 8 pixels... total.
- The use of parallax scrolling actually creates a neat sense of depth, but then it gets lost because I so aggressively tile everything.
- Every enemy has too many HP, but the bosses are especially egregious because they're timed to last about as long as an entire walking stage.
- The sole sop to criticism I actually let get through my skull during development was to add a checkpoint to the walking stages. One checkpoint, midway through. This was very bad because
- I pegged the difficulty to the following scale: every enemy had to be able to kill you on its own at the Easy difficulty setting if you did absolutely nothing. The hardest difficulty was as hard as it could possibly be to me, the guy who had been playing it for a year and a half, and still complete it... once.
- For some godforsaken reason, I put a teleport maze in the seventh stage. I did not remember what the solution to the teleport maze was and spent fifteen minutes wandering around in it. I eventually had to get a piece of paper out and draw a map. There are multiple spots where the teleports are hard to avoid, at least one spot where all of the teleports are wrong and you actually have to walk off to the left to find the correct teleporter, and one spot where after training you to avoid the wrong teleports you actually have to use the second-to-last obvious booby trap one to proceed. There is a combat segment and an extended "falling through a corridor lined with spikes" segment after this, and if you die, the checkpoint is before the teleport maze.
- One level toward the end is a four-minute-long avoidance autoscroller.
- Notice that there is no UI in the trailer. This was intentional! All character state is conveyed by visual and audio cues. Your health is indicated by a desaturation filter.
- The game had a plot that was about five pages long in the readme and expressed exactly nowhere in the actual game.
- There's a cutscene that I'd entirely forgotten about that actually made me chuckle on seeing it again. In the fifth stage, your character crashes into a mountain, makes a loud battlecry sound, and is abruptly crushed by an avalanche he apparently triggered by so doing. Midway through the stage one of the generic bird minions grows huge, lets out a earth-shaking battlecry-- and gets obliterated by the resulting avalanche.
- Lordy but the music is godawful.
- Every enemy has three or four different attacks, which is good, because it's amazing how fifteen different enemies can feel so repetitive when the game is basically nothing but fighting them over and over.
- There are six different buttons and you have to use them all proficiently from the word go if you want to make progress with any speed, especially the spinning move that makes you invulnerable and the teleport you use to cancel the "taken damage" state. There is a tutorial but it's basically like Cuphead's: "here are the moves you can do. Okay ready GO"
Basically, Shadows Over Volgadan is an absolute embarrassment of a game and the only reason I'm not embarrassed to not have published anything better in the past 10 years is that I haven't published anything in the past ten years. The thing that's keeping me going is knowing that I basically can't do worse.
This week I hope to actually have entity parenting completed in my collision detection system. I am also planning, vaguely, to do some practice in pixel-art and possibly play around with Blender or FL Studio, because one of the things that stuck in my head this week is that I tend to go all-in on the programming work and then stall out when I hit the art side where I'm significantly weaker. In order to maintain enthusiasm over the long term, I think I need to be at least mildly practiced (or at least tangibly improving) by the time I arrive at the "and now, make a game with it" phase.
EDIT: I went around in circles for a while trying to find where the game actually sticks its save file, and it was in some random appdata folder because that was The Right Way To Do It at the time. And evidently I was smart enough to write things to a file by that point, because there's some stuff you unlock by beating the game. And it's a binary format so god only knows what's supposed to be in there, except that it's only a couple bytes long. I was paranoid enough about people hacking the unlockables that I threw some kind of basic encryption scheme on it, which would be fine if the source code I managed to extract from my laptop was current. It is apparently not. If I want to see this game's unlocks again I have to actually beat the game on the hardest setting. Fuck you, Young Kupi!
EDIT 2: Old Kupi knows about ILSpy. Old Kupi has hacked Young Kupi's code, copied the save function, and written a save file that has all the scores maxed out and everything unlocked. This is why Old Kupi is better than Young Kupi.
Kupi on
My favorite musical instrument is the air-raid siren.
My favourite is when you fix a bug only to realize that the bug was covering up a much larger and more structural bug that only looked like it was working because the first bug masked it.
Bonus points if the first bug wasn't even really a bug
I've started working on configurable controls to turn my proof of concept into a game product. This is the worst part of gamedev for me. Drudge programming and engine work that is so far removed from gameplay.
I know intellectually it is necessary but that doesn't stop the devil on my shoulder from whispering "Quit doing this boring shit and go watch some TV".
I've started working on configurable controls to turn my proof of concept into a game product. This is the worst part of gamedev for me. Drudge programming and engine work that is so far removed from gameplay.
I know intellectually it is necessary but that doesn't stop the devil on my shoulder from whispering "Quit doing this boring shit and go watch some TV".
I've been working on *only* engine stuff for about 6 months, and I'm losing my mind. I think I need to take a vacation from my passion project
So I've confirmed that Unity ToggleGroup objectss are implemented in a completely nonsensical manner.
The togglegroup itself has no events associated with it. All it does is turn off every child toggle except for the clicked one. The child toggles have change events but I couldn't find any way to pass the toggle state in that event.
So using my caveman programming skills I brute forced the problem. Every individual toggle has a method that is called by the change event with a parameter being a reference to the toggle itself.
The method tests the toggle that called it to determine if the toggle is on or off and if it is on fire another method with an identifier for the toggle that was changed as a parameter.
public void Player1ToggleChanged(Toggle changedToggle)
{
if (changedToggle.isOn) SetupTheSetupPanel(PLAYER.PLAYER1);
}
public void Player2ToggleChanged(Toggle changedToggle)
{
if (changedToggle.isOn) SetupTheSetupPanel(PLAYER.PLAYER2);
}
Please tell me there is a better way to do this because it hurts my heart knowing this abomination is in my source files.
Does anyone have any experience suppressing the CS0649 warnings in visual studio? You get those when you have private fields with the [SerializeField] attribute, because VS has no way of knowing that Unity will inject serialized values into a private field that otherwise looks like it will never get assigned
Posts
Hair editor:
Part 1 - Materials and manual strand design
Part 2 - Hair Guides, object groups, animation rigging, and textures
Indeed, Entity/Component/System...
However, I am starting to realize that ECS is *really* about the Burst compiler. There are still BIG changes ongoing in the Unity ECS implementation, and a lot of the motivation behind those has to do with Jobs. So, you can't just dip your toes into ECS as a newb. The feedback of both the alpha users and the team tends to talk about things not much above machine code level; which type of arrays can be fed into a parallel process for example, and what alternative would be quicker.
The strategy is very much on the speed of execution. I've seen a bit of news about taking into account developer needs, for example in reinstating bools in 'Pure' ECS, but in general there is no hesitation in throwing 'ways' of doing things overboard if another approach ends up faster. Mesh components seem to have iterated through two completely deprecated versions in the last month, and the way to add components to entities ditto.
Of course, the speed they are achieving through this is why I'm jumping on ECS. But the question is whether 2019 is the year in which you can ship an ECS-based game. Because half of your code may be deprecated right after shipping, and then have fun with your updates...
For example: here they talk about Chunk Iteration which is supposedly the stable baseline. But the Injection which he mentions was deprecated since November.
***
Kupi's Weekly Friday Status Report
I got into Torna: The Golden Country and played that during basically all of my leisure time this week, so I don't have much to report.
I did, at least, have a mild epiphany about how to design parenting between Entities in my architecture. I'd previously planned to use a ParentingComponent to store the parent and children of the Entity to which they belong, but ran into problems from multiple angles: some types of Entities are only parented to rarely and it's wasteful to make every single one keep references around just in case (my engine doesn't yet support adding or removing Components from Entities and doing so will never be cheap), and there's a nasty coordination problem when an Entity gets deleted but some arbitrary set of Entities may have declared it a parent.
So, the plan now is to move the Entity parenting map into my ComponentStorage class, which is my system's main data-storage type. Individual Entities won't track their parenting state; that belongs to a higher-level view of the data. Which makes sense, I think. Entities know their own data and nobody else's.
My goal for next week is to finish Torna. If I manage that, I'll look into implementing Entity parenting again.
When you are working on a game you are really working on two distinct parts. One is a specific game idea you have bouncing around and the other is a generalized game framework that you will (ideally) be taking into your next game project.
Since I didn't realize this until very recently and I've been re-inventing the wheel every time I've opened a new project. For (unity specific) example I've noticed that I have volume controls for every project. They are all stored in a playerpref. I try to make the sound configurable from both the title settings and the in-game pause menu. I've rebuilt sound controls from nothing at least a dozen times and it never occurred to me to make a unity package that I can import into my next project.
I've reused my touch screen control script already a few times, but I hadn't thought about making a Unity package out of it.
How are unity packages versioned? I can imagine wanting to add features with new games and needing to edit and reimport libraries.
Making a package was pretty easy once I actually tried it: Assets-->Export Package and select the objects you want to export. Scripts in your package should be in a namespace so they can always be imported cleanly. And everything should be in a single root folder.
So it's not like you're starting from scratch, even if you're "starting from scratch"
Said the guy who's spent the last two months doing engine programming.
The differences between the two would be:
L2/R2: Manual aiming would heavily negate accuracy as the player is aiming, could add a damage boost or crit based on where the shots hit.
L1/R2: Allow the game to calculate math on if the shots hit or not based on the stats of the weapon (and possibly the player with level-able traits).
The closest thing I can think of is the VATS system from the Bethesda Fallouts, but that feels incredibly slow due to the animations and slow-mo zooms. Maybe Mass Effect, but again that stops the game to take time to target and queue up your shots and abilities before playing all of them at once. I'm talking like, near-instant triggers which after enough levels or loot grinding could make the player character feel like a twitch shooter god. Single bigger enemies could also be designed to be easier to kill with manual shooting instead of the auto shooting to encourage players to get better with 'classic' shooter play styles, but players could also prefer the auto shooting for hordes of enemies for the fear of being swarmed.
Not to mention the accessibility it provides to both hardcore and casual gamers, I feel like a big reason more casual gamers don't play through games like Gears, Uncharted, Tomb Raider, etc... is because they feel like they're not good enough to be able to aim and shoot enemies as they play through the game. This will allow a smaller learning curve for those kind of players and maybe help break them into the genre of shooters.
Thoughts?
Twitch: KoopahTroopah - Steam: Koopah
Its the "pass arbitrary condiments" problem
You are investing actual time now to save time in your hypothetical future.
If you wanted, you could trade a bit of damage or fire rate or some other stat to replace your weapon fire with tracking shots. That also let you work with them more strategically (enemy in cover? Shoot as far away as you can while still targeting them!) without needing the aiming mechanics. You'd need to balance it out so that player aiming regularly is vaguely similar in power to player not aiming, but it worked.
Sunless Skies also has a great thing in their difficulty settings about amount of auto-aim. It's not a TPS, but it's got a lot in common. On the hardest difficulty, you can find weapons that track, but cannons don't. One difficulty up and all weapons track a little, but you still need to aim. One level up and all shots track generously, so if you're pointed near the right direction, you're fine.
Also I've seen a lot of more recent games (like 2013ish on) that have shooter mechanics have a slider for "auto-aim", rather than a toggle or just having it. So like, I'm playing through RDR 1 right now, and the auto-aim can be set so generously that you basically sort of point near the enemy, hit LT, and it'll snap right to them.
For that matter, RDRs "Deadeye" presents another way of dealing with the problem. New Splinter Cells have a similar thing also. In RDR, there's a meter you have, that's refreshed over time, and refreshes faster with headshots. When you enter that mode, time slows down, and if you basically pass your reticle over the enemy, you'll lock on for a headshot. You can select up to 6 enemies or so, and when you exit the deadeye mode, Marsten just headshots all of the locked-on enemies.
Splinter cell does the stealth-action version, where you can build up a meter, and you can tag enemies. You can then hit a "kill the tagged enemies" button and headshot all of them (this one would need tweaking, in splinter cell I forget the exact mechanics but the idea is that you use it to stay stealthed, rather than using it in combat).
I think you more described the lock on from ocarina of time. You can either aim at a specific spot with bow/slingshot manually or you could lock on and just shoot center of mass.
Steam: https://steamcommunity.com/profiles/76561198004484595
I totally forgot about RDR, I'm pretty sure RDR2 does the exact thing I'm describing if I recall.
Yeah, these are all good suggestions. I think OoT might be a little more clunky than what I was thinking, since aiming in OoT was super slow and difficult.
Twitch: KoopahTroopah - Steam: Koopah
Slightly less pronounced, Just Cause (at least 2 and 3, haven't played the others) does this. You have a lock to center mass on things near your reticle, but you can still override it by aiming (as in: if you are aiming outside, it will hit COM, otherwise whatever you're pinpointing.) There's also a button to aim down sights.
Some days you track down a rare bug in the implementation of your iterator for your custom hash table class that makes it sometimes neglect to return the last item or two, but only after doing a fairly specific sequence of adds and removes.
I hate that it took me five hours to figure this out but I'm glad it's solved.
"What the fucking fuck why doesn't this work, this should work 100% of the time."
*finds error after 4 hours*
"Oh, of couuuuuuuuuurse this wouldn't work. I'm a dummy."
Twitch: KoopahTroopah - Steam: Koopah
Immediately followed by, "I can't believe I wasted 4 hours on this!"
"...it's exactly the same! HOW!"
And just so we get to Friday with nothing available for the weekly report, a conversation with my roommate (which left me feeling negged, but that's neither here nor there) made me realize that writing my own collection classes might have created a lot of extra work for me ensuring that they play nice with Newtonsoft.Json, which serializes the built-in list and dictionary types in pretty ways but does scary reflection-y things with custom object types. But it turns out that the Newtonsoft guys are geniuses and anything that implements common collection interfaces like ICollection or IDictionary get the pretty printing treatment with no further effort. So my special pooled-backing-store collections were less a waste of time than they feel!
Bonus points if the first bug wasn't even really a bug
*features*
Steam: https://steamcommunity.com/profiles/76561198004484595
So I fixed up my climbing code. Video is below.
It matches both position and velocity, so you can grab (and hold) onto moving objects. I attach the player at four points (bright yellow/red spheres in the video) since that keeps the avatar attached to the wall in a pretty stable way.
This was another slow week, for preventable reasons. When I related the story of the custom hash table's iterator sometimes dropping items off the end of the list to my roommate, he made a remark that was well-intended but could be taken to imply that I was wasting my time, which the enemy within latched onto and blew up into a strong sense that I am, in fact, wasting my time, ought to set fire to my custom architecture and go back to Unity or Unreal if I genuinely want to ever finish anything. That feeling has largely passed now but managed to wipe out a couple days' will to be creative in any way, shape, or form. I'm not going to re-litigate that conversation any further, though, so on to the report itself.
In terms of actual game dev work, the one thing I accomplished this week aside from identifying my enumerator bug was crossing one item off the three-stage operation to make the collision detection system react appropriately to entity parenting. Said first item was transforming the version of each entity's Position component from relative space to world space. This will eventually be mirrored in the clean-up / write-back phase, transforming the world-space positions back into relative positions before the Position components get their new values written back. The final and most troubling phase will be to make sure that changes in the position or velocity of a parent collider (as occurs when a blocking interaction happens) are reflected in their child colliders. After that, though, I think the collision detection system is finally fully implemented and I can move on to something else. (... once I perform appropriate testing, naturally.)
As I was discussing my anxieties with another online friend, I happened to mention Shadows Over Volgadan, which is the only full game that I've ever published (that I'll admit to creating, at least). I realized that I still had an old laptop lying around, and on a vague suspicion decided to boot it up. The startup screen made some kind of complaint about the CMOS, but otherwise it booted up to Windows 7 just fine. And lo and behold, not only was there a copy of "Beta 5" of Shadows Over Volgadan, but the full source code as well. So I spent yesterday evening playing through... two-thirds of it. If you want to injure your audiological sensibilities, take a gander at the trailer I made for it back it was first out:
(Don't visit the site at the end. I don't own it any more and actually have no idea what's even there.)
Some miscellaneous notes about the game:
- It's strange for the son of an IBM mainframe engineer, but I didn't actually do any real programming until I was in college. And somehow, three years into that college education, I still hadn't twigged to the idea that I, myself, could set up a program to accept data from files. Everything in Shadows Over Volgadan that didn't already have a "load from file" interface provided by XNA was hard-coded. The terrain? Hard-coded. The progression of enemy waves? Hard-coded. The frame changes in the sprite animations? Hard-coded. That explains why the animation is essentially nothing but keyframes, because updating the animations was a pain in the ass and it never occurred to me that that could possibly be any easier.
- This reaches a comical extreme in the kicking attack, which is one frame of animation as short-ranged projectiles with two frames of animation are emitted.
- There is nowhere near enough shading on the any of the sprites to create a sense of depth.
- Automatic rotation is a tempting trap, but the fact is that it will never look entirely correct with pixel art. If a character needs to rotate, draw sprites for it.
- The collisions are driven by the sprites themselves, because I saw a technique for doing so described on a blog post and didn't consider that simpler forms could possibly work.
- ... and that makes things difficult when some of the enemy attacks are sprites that are 8 pixels... total.
- The use of parallax scrolling actually creates a neat sense of depth, but then it gets lost because I so aggressively tile everything.
- Every enemy has too many HP, but the bosses are especially egregious because they're timed to last about as long as an entire walking stage.
- The sole sop to criticism I actually let get through my skull during development was to add a checkpoint to the walking stages. One checkpoint, midway through. This was very bad because
- I pegged the difficulty to the following scale: every enemy had to be able to kill you on its own at the Easy difficulty setting if you did absolutely nothing. The hardest difficulty was as hard as it could possibly be to me, the guy who had been playing it for a year and a half, and still complete it... once.
- For some godforsaken reason, I put a teleport maze in the seventh stage. I did not remember what the solution to the teleport maze was and spent fifteen minutes wandering around in it. I eventually had to get a piece of paper out and draw a map. There are multiple spots where the teleports are hard to avoid, at least one spot where all of the teleports are wrong and you actually have to walk off to the left to find the correct teleporter, and one spot where after training you to avoid the wrong teleports you actually have to use the second-to-last obvious booby trap one to proceed. There is a combat segment and an extended "falling through a corridor lined with spikes" segment after this, and if you die, the checkpoint is before the teleport maze.
- One level toward the end is a four-minute-long avoidance autoscroller.
- Notice that there is no UI in the trailer. This was intentional! All character state is conveyed by visual and audio cues. Your health is indicated by a desaturation filter.
- The game had a plot that was about five pages long in the readme and expressed exactly nowhere in the actual game.
- There's a cutscene that I'd entirely forgotten about that actually made me chuckle on seeing it again. In the fifth stage, your character crashes into a mountain, makes a loud battlecry sound, and is abruptly crushed by an avalanche he apparently triggered by so doing. Midway through the stage one of the generic bird minions grows huge, lets out a earth-shaking battlecry-- and gets obliterated by the resulting avalanche.
- Lordy but the music is godawful.
- Every enemy has three or four different attacks, which is good, because it's amazing how fifteen different enemies can feel so repetitive when the game is basically nothing but fighting them over and over.
- There are six different buttons and you have to use them all proficiently from the word go if you want to make progress with any speed, especially the spinning move that makes you invulnerable and the teleport you use to cancel the "taken damage" state. There is a tutorial but it's basically like Cuphead's: "here are the moves you can do. Okay ready GO"
Basically, Shadows Over Volgadan is an absolute embarrassment of a game and the only reason I'm not embarrassed to not have published anything better in the past 10 years is that I haven't published anything in the past ten years. The thing that's keeping me going is knowing that I basically can't do worse.
This week I hope to actually have entity parenting completed in my collision detection system. I am also planning, vaguely, to do some practice in pixel-art and possibly play around with Blender or FL Studio, because one of the things that stuck in my head this week is that I tend to go all-in on the programming work and then stall out when I hit the art side where I'm significantly weaker. In order to maintain enthusiasm over the long term, I think I need to be at least mildly practiced (or at least tangibly improving) by the time I arrive at the "and now, make a game with it" phase.
EDIT: I went around in circles for a while trying to find where the game actually sticks its save file, and it was in some random appdata folder because that was The Right Way To Do It at the time. And evidently I was smart enough to write things to a file by that point, because there's some stuff you unlock by beating the game. And it's a binary format so god only knows what's supposed to be in there, except that it's only a couple bytes long. I was paranoid enough about people hacking the unlockables that I threw some kind of basic encryption scheme on it, which would be fine if the source code I managed to extract from my laptop was current. It is apparently not. If I want to see this game's unlocks again I have to actually beat the game on the hardest setting. Fuck you, Young Kupi!
EDIT 2: Old Kupi knows about ILSpy. Old Kupi has hacked Young Kupi's code, copied the save function, and written a save file that has all the scores maxed out and everything unlocked. This is why Old Kupi is better than Young Kupi.
We call that a load-bearing bug.
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
Shadows Over Volgadan looked awesome with all the crazy particle effects. I tried it out but it was super hard, so I didn't get very far.
Wacom tablet software does not read pressure, so its basically painting everything
http://www.fallout3nexus.com/downloads/file.php?id=16534
What about MonoGame and FNA?
I feel you though, there is part of me that is having fun with coding, but sometimes it feels like I should just hack it out.
I know intellectually it is necessary but that doesn't stop the devil on my shoulder from whispering "Quit doing this boring shit and go watch some TV".
http://www.fallout3nexus.com/downloads/file.php?id=16534
I've been working on *only* engine stuff for about 6 months, and I'm losing my mind. I think I need to take a vacation from my passion project
The togglegroup itself has no events associated with it. All it does is turn off every child toggle except for the clicked one. The child toggles have change events but I couldn't find any way to pass the toggle state in that event.
So using my caveman programming skills I brute forced the problem. Every individual toggle has a method that is called by the change event with a parameter being a reference to the toggle itself.
The method tests the toggle that called it to determine if the toggle is on or off and if it is on fire another method with an identifier for the toggle that was changed as a parameter.
public void Player1ToggleChanged(Toggle changedToggle) { if (changedToggle.isOn) SetupTheSetupPanel(PLAYER.PLAYER1); } public void Player2ToggleChanged(Toggle changedToggle) { if (changedToggle.isOn) SetupTheSetupPanel(PLAYER.PLAYER2); }Please tell me there is a better way to do this because it hurts my heart knowing this abomination is in my source files.