So I implemented save/load because it was getting annoying having to reconnect everything
I also implemented the simplest form of verification: the truth table, which live updates as you do things. Every time a significant change is detected, a new version is produced and all the tests re-run. Incorrect values are also highlighted and you can click the input ports to see how values are produced through the system
Multi-bit wires are in too, which I knew was going to be a pain, but ends up mostly working. Gates dynamically resize if their inputs and outputs allow it. Wire splitters dynamically create output ports, mergers add new ones as needed. This does produce a potential future problem - Verilog doesn't care which end of a wire gets written, it assumes continuous assignment and will re-evaluate everything until it settles. You can technically even write an input wire and it will propagate. However for performance reasons everything I do has directionality and I only ever evaluate any specific wire or gate once, so you can't write to the output of a split wire for example. I am currently disallowing multiple logical writes to one wire though as well as combinatorial loops, so it should be fine for stuff constructed through the GUI
I was hoping the mixed colour display for multi-bit wires would look better, I guess I'll have to find another way to represent it
Not much, but I've settled on a target, at least. Knowing that I need a simple project to exercise my engine and get practical experience with the soup-to-nuts process of building and then publishing a game, I've chosen my concept for a simple shmup starring a squid who fights space aliens evil fish with the lasers it's unaccountably able to shoot from its head as the sacrificial lamb. The core gameplay gimmick is that you can have multiple weapon power-ups at the same time, with duplicates of the same weapon increasing the strength of the weapon. Then, there's a special [?] pick-up which, rather than being any particular weapon, raises all the other weapons in your possession by one level.
Been doing some basic spriting, but that fly-cycle up there is the only thing I haven't thrown out so far. Oh well! Monochrome is easily replaced.
Just to pad this out a bit, an aside on making homing projectiles. When you've got a projectile that you want to move toward a target position without using the "cheaty" way of just flatly resetting its velocity to face the target every frame, the naive approach is to accelerate in the direction of the target. However, in my experience this produces cases where you wind up simulating orbital mechanics, with your allegedly smart missile doing perfect circles around a stationary target. Here's a better way: take the direction vector to your target and multiply it by your projectile's maximum velocity. Then, take the delta between your projectile's current velocity and the desired velocity, normalize it, and multiply by the acceleration rate. Basically, you're applying an acceleration that moves your projectile's current velocity toward a velocity that directly faces the target. There are still cases where you get bad behavior, but I've found that homing projectiles implemented that way feel significantly more accurate without being unavoidable.
My favorite musical instrument is the air-raid siren.
Progress is a bit light this week, I struggled with motivation and ended up playing a lot of Demon's Souls as I recently finally acquired a PS5. I feel like I'm getting to the point where the pieces are coming together and the core game is becoming fully formed, but for me this is the hardest part - now I just have to invest a lot of time in building more content, more progression systems, doing many balance passes, etc. The hard work of truly finishing a project is not nearly as alluring as that satisfaction of executing on a brand new idea for the first time. Nonetheless I'm going to try to stick it out and just focus on making incremental progress over time, not thinking about the end goal too much.
Replaced the placeholder monk sprites with villagers
Added blood particles
Added magic shop panel for things like max mana, mana regen, spell damage, etc.
Added a fireball spell you can spend mana on instead of units. My intent is that making units take priority, but attack spells should be useful mainly for finishing off enemies that are far away from your main forces, plus support spells are used for more difficult encounters.
Brought the uncompressed file size down to 28mb or so. Only so much I can do with Unity.
I completed the process of buying my new house. This has exchanged all the anxieties of buying a house with all the anxieties of owning a house.
In terms of game dev work, I also had a light week because of the above. However, there are still a few bullet points to post up:
- I wrote out a burndown list for the Ike Ika project. Basically just listing out, in vague categories, every individual little thing I will have to do before I can call the project done. That way, if I'm ever bored and listless and not sure what I actually feel like doing, I can go to the list, throw a dart, and just do that, rinse repeat until everything is done.
- Consequently, I drew a lot of the various sprites required to support each individual shot type the squid can emit.
- And then implemented the basic character controller for the squid, along with its basic peashooter shot (though neither the squid nor the shots can interact with anything yet).
- I also worked out the math that drives how the flamethrower weapon will scale with its power level, but that'll be for the whatever post covers when I actually have the flamethrower throwing flames.
So for the ARPG system, I'm at a good breathing point here. I finished implementing the convenience calls to turn databases into Jsons so someone could import/export them back and forth into their favorite text editor to make changes without Unity. There's still things that you can't change without the editor, these are the reference types (referencing sprites, other scriptables, etc.) and that doesn't make much sense to allow someone outside Unity to change, plus it would be too much so that's that.
Some next steps for the ARPG is to make things prettier and to expand on the existing systems. I added a "Deflect Projectiles" weapon buff recently, so I want to do more of that for some generic ability types. Right now Abilities are all timed based, that is, once you hit a button, it fires the ability. Well, technically it first fires a 'delay' (so people can match it up with animations and other reasons), then after the delay it fires the ability, which then fires a cooldown, and after the cooldown it does any end logic. This is all timed based, but I'm going to add the function to allow the delay to be input based, so while the player holds down X button, they delay the ability. This is most useful for charging abilities.
With the type of work changing in ARPG from building out systems to now adding in meat, I've turned my attention also to the Pirate Rammer thing I've been working on.
I ran across some new mind mapping software called milanote. I'm using it to flesh out a GDD for the Pirate game, so I've decided on things like the world, main characters, time period, story, and finished writing out a draft of the 'tutorial' scenerio. The Milanote software is nice, but you can't put much on it with the free version, but that's been a great thing! It's helped me reduce scope by reducing the scope of the GDD itself. Hah! Here's a picture of what it looks like: (spoliered for large)
All the little icons are nested boards, so you click on them a new board opens. It's pretty easy to move things arrange, draw, and arrange in more artsy fashion, which is a nice breath of fresh air over Trello. So I worked on that and also put together a quick Dialogue Manager in Unity to use for the story events. I experimented it with Unity's timeline, so most of the story bits will be linear story bits it seems to work out well.
So I'll leave you with a video of some changes to the crashing, really just trying out a camera shake and also added VFX that I made using Unity's VFX graph. The VFX graph is pretty nice.
Next week, get some placeholder art into the dialogue manager and implement the first story scene in the tutorial scenerio. Once I got that flow down, I'll move onto designing some areas for the tutorial.
Took a week off this time, Bravely Default 2 has eaten a lot of my time and might eat a lot more. Recently I've felt somewhat discouraged by the lack of genuine enthusiasm for working on it that I've had lately, but I think that's just a sign that this is just one of numerous hobbies and it's not always going to be my first choice of activity. I do still have new half-formed ideas for games rattling around in my head but I don't think they're that great and I don't want to get distracted again. It seems to come in phases - there are times when I feel burnt out on playing games and have more free time than I know what to do with, and game dev is a great time sink for times like that. What's important is that I don't let it lapse for so long that I lose my familiarity with the project so I can't just jump in and make progress anymore.
Took a week off this time, Bravely Default 2 has eaten a lot of my time and might eat a lot more. Recently I've felt somewhat discouraged by the lack of genuine enthusiasm for working on it that I've had lately, but I think that's just a sign that this is just one of numerous hobbies and it's not always going to be my first choice of activity. I do still have new half-formed ideas for games rattling around in my head but I don't think they're that great and I don't want to get distracted again. It seems to come in phases - there are times when I feel burnt out on playing games and have more free time than I know what to do with, and game dev is a great time sink for times like that. What's important is that I don't let it lapse for so long that I lose my familiarity with the project so I can't just jump in and make progress anymore.
There's nothing wrong with taking a break.
Also, weird as it sounds, thanks for telling us. Keeping a journal of sorts has kept me honest with how much or how little time I spend doing game dev, so declaring where you're at-- even if it's "taking a break"-- can be useful. Enjoy the time with your games, Zek.
My favorite musical instrument is the air-raid siren.
Yeah I took off a few weeks to try and write up some tutorial programs using Vulkan, which is has lots of boilerplate. But I finally got a triangle on the screen with Vulkan so now I'm taking a break from THAT and going back to my game. I don't remember WTF I was last working on though! Maybe I'll just fiddle with some shaders.
I had what I thought was a pretty brilliant idea a few weeks ago about how to do animated faces for my characters. Each character would have a separate face rig, which was a flat rendering of their facial expression, unlit, parented by its own camera, which rendered to a render texture, which was used for the character's face material. It looks something like this in practice:
I was disappointed when I learned more recently that I am not a genius, and this is in fact exactly how anime vtuber facerigs work (I tried to dig up the image I found, but alas).
However, I'm so happy with the results that I felt like sharing.
Still can’t code passed little doodles, and have had dozens of game ideas come and go. Right now I’m thinking it would be amazing to have a Dwarf Fortress/Rimworld style game where you can only roughly guide your little peeps, rather than setting down each task. Something like lassoing a section and marking it as ‘housing’ and watching them go, and being given choices on what to do about a problem, then they go misinterpret it.
Anyways this post is mostly an excuse to say how awesome you guys are, keep up the good work!
You remember how I mentioned that I'd worked the math out for the flamethrower weapon for my game's squid? I still have the math worked out! It just turns out that the other functions of the flamethrower were non-trivial, at least compared to all the other weapons, so I went and did all of those instead:
As I noted in a previous post, the gimmick of this game is that you have five slots for weapon pick-ups. If you pick up different weapons, then you get to use all of them at the same time, but if you pick up multiples of the same one, then that weapon gets stronger. So, there's a trade-off in terms of whether you want to invest heavily in a single weapon, or have multiple weapons that compliment each other. There's also the wrinkle of the [?] weapon, which instead of being its own weapon, instead powers up all other weapons you possess. So if you have two or three weapons and fill the rest with [?], you'll have something like eight or nine effective weapon levels instead of the usual limit of five.
The five weapons on display here are:
- Laser: Shoots tiny, fast-moving projectiles. Upgrades reduce the refire time, making it shoot even more shots.
- Spread: Shoots spreads of big, bulbous shots. Upgrades increase the number of bullets per arc.
- Pierce: Shoots triangular waves that can damage multiple enemies before disappearing. Upgrades increase the number of enemies they can affect. (I may reduce the flight speed of the projectile so they can linger on the screen for longer.)
- Homing: Shoots pinwheels that home in on enemies. Upgrades increase the time the projectiles live, meaning you lose fewer shots. (I plan to reduce the base lifespan per bullet and increase their acceleration and max velocity, making the weapon more dynamic and the "hit enemies further out" upgrade aspect more significant.)
- Missile: Shoots missiles that have the highest overall DPS, but have an awkward arc that makes it hard to consistently land. Upgrades increase the damage per missile.
And then the final weapon is:
- Flamethrower: Shoots fire that damages enemies at close range and cancels enemy shots. Upgrades improve the ratio of time spent firing to time spent cooling off.
However, rather than focus on the flamethrower for next week, I have once again decided to go off on another architectural big dig. Without going into too much detail, the core of the problem is that due to the way I've set up my "job" classes, which handle parallel execution, they get access to the entity buffers that they operate on in a roundabout way. As a result, there is a lot of extra typing that goes into the creation of even a simple system. For instance, here's my "Basic Movement" system, which just takes everything that has a Position and a Velocity, and adds the latter to the former while recording the movement so that hitboxes can perform their shape-cast along the line generated:
public class BasicMovementSystem : System<BasicMovementSystem>
{
public override Fixed Priority => SystemPriorities.Collision;
[MainQuery]
WriteBackRequiredComponentBuffer<Position> positions = new WriteBackRequiredComponentBuffer<Position>();
[MainQuery]
ReadOnlyRequiredComponentBuffer<Velocity> velocities = new ReadOnlyRequiredComponentBuffer<Velocity>();
[MainQuery]
ReadOnlyRequiredComponentBuffer<BasicMovement> basicMovements = new ReadOnlyRequiredComponentBuffer<BasicMovement>();
[MainQuery]
ReadOnlyRequiredComponentBuffer<Movement> movements = new ReadOnlyRequiredComponentBuffer<Movement>();
public override void Process(ComponentStorage componentStorage)
{
using (var query = BufferedEntityQuery.Execute(componentStorage, MainQueryBuffers))
{
UnorderedJobs.Run(BasicMovementJob.Allocator, this, query.Count);
}
}
class BasicMovementJob : UnorderedJob<BasicMovementJob, BasicMovementSystem>
{
protected override void Process(int index)
{
param.movements.Buffer[index].Log.Clear();
param.movements.Buffer[index].Log.Add(new MovementHistoryEntry { Position = param.positions.Buffer[index].Value, Time = Fixed.Zero });
param.positions.Buffer[index].Value += param.velocities.Buffer[index].Value;
param.movements.Buffer[index].Log.Add(new MovementHistoryEntry { Position = param.positions.Buffer[index].Value, Time = Fixed.One });
}
}
}
The buffers all belong to buffer management objects that you have to manually declare, and then you have to get the buffers out of the system, which has been handed to the job as a parameter. It's a lot of saying the same thing (especially the dereferencing) over and over and over and I'm getting kind of sick of it. I haven't implemented it yet, but I've realized that through some potentially horrifying (mis)use of reflection, I can get my system class to assemble the entity-processing pipeline out of its own public members. The final result, once I'm done, will look something like this:
public class BasicMovementSystem : System<BasicMovementSystem>
{
public override Fixed Priority => SystemPriorities.Collision;
[QueryBuffer(QueryBufferTypes.WriteBackRequired)]
public Position[] positions;
[QueryBuffer(QueryBufferTypes.ReadOnlyRequired)]
public Velocity[] velocities;
[QueryBuffer(QueryBufferTypes.ReadOnlyRequired)]
public BasicMovement[] basicMovements;
[QueryBuffer(QueryBufferTypes.ReadOnlyRequired)]
public Movement[] movements;
[Step(StepTypes.Multithreaded)]
public void AddVelocityToPosition(StepContext stepContext)
{
movements[index].Log.Clear();
movements[index].Log.Add(new MovementHistoryEntry { Position = positions[index].Value, Time = Fixed.Zero });
positions[index].Value += velocities[index].Value;
movements[index].Log.Add(new MovementHistoryEntry { Position = positions[index].Value, Time = Fixed.One });
}
}
So much less typing! Now, mind you, I'm sort of burying the lede here, and there will be a lot more code in the base class's constructor than there used to be, but that's what base classes are for: to absorb all the common behavior and let you write only what you need to extend into new domains. So, the actual game development is on hold once again until I go about re-tooling my engine to support this new structure. Will it work? Who knows! I'll find out, though, and report back next week.
EDIT: If you're thinking that my system class bears an uncanny resemblance to Unity's ECS setup, I will freely admit that I have somewhat cargo-culted my design off what I saw during one of their earliest promotional videos on the system, though I think I might have wound up here independently with the goal of "describe the kind of entity the system operates on and describe the processes which be performed on said entities in as little code as possible" in mind.
Kupi on
My favorite musical instrument is the air-raid siren.
I went back and edited most of the maps/landscapes. I decided to make all the map borders use the same "language" such that when you see a walls of brambles that means "this is the edge of map buddy, turn around".
It looks a little weird because you'll see a big ol' wall of brambles in unusual places but I like the unified signage. Also having piles of brambles isn't THAT strange considering I have giant magenta pyramids just poking out of the ground.
So end of the week again, let's see what we got done.
So the original goal was to get the dialogue sequencing in the Pirate Rammer prototype, and that was a success. I'm using Unity's timeline here since we're keeping it nice and simple, just linear dialogue with a "continue" button being the peak of interaction. With that done, I also brainstormed out the sequences for the tutorial and what the map will require and created a 'gameplay loop' level. The idea is to have a gameplay loop demo shareable and also the prototyp'd tutorial with all placeholder art done by the end of this month.
I also revisited the movement system in the ARPG unity asset I have, and started moving the enemies and player movement over state machines that can plug into existing ability system. This was an interesting journey that lead me into encapsulation 'states' and their trigger condition in a scriptable object, that can be plugged into Unity's editor or removed. The idea here is to allow people to build on this framework and to have it ready to plug in/out for their designers (which, let's be honest, will probably be the same person). It's probably not the most sane approach but it's an approach that's consistent with the rest so we'll stay with it.
I got some examples of roll, slash, and 8 & 4 direction walking in there, so it turned out okay. There's lots of classes that need cleaning and reorganizing, but it's a start. Also added options to the abilities so they can be interruptable by damage, death, collision, and/or another ability. You can sort of see that in the video below where I transition from the sword slash to roll before the slash is complete and when I roll into a wall and stop.
For next week, clean up that movement system and integrate it into the game database. Also, continue with the prototype, hopefully have a gameloop scene built and shared on Itch and the first scene of the tutorial level sequenced (but not shared on itch, just in the editor). The gameplay loop will require me to create a semi-okay spawning system, as it's just going to be the player boat movement and ramming unsuspecting other ships. The game feels better on a joystick than on the arrow or wasd keys, so I may also give an option to use one of those mobile touch joystick nipple things to move the boat as well.
Next week summary
Clean up ARPG movement system
Integrate new movement in game database actor creation
Build a simple core gameloop scene to share on itch.
Sequence out the first scene in the tutorial level (editor).
The COVID vaccine I got is kicking my ass, so I'm going to be brief this week.
I broke ground on the System class rewrite. For now, I've sequestered all the work into a new class which I'm calling "SelfAssemblingSystem", since the goal of the whole exercise is to have Systems build their own query and work-processing pipelines out of their public members. There are two big pieces to that: the queries that assemble the Component streams, and the Steps which are functions that are either run single-threaded or multi-threaded. So far, I've got the query assembly part written, and I've sketched out the outline of the Step handling classes (though the multithreaded ones need much more implementation work).
I also spent some time working on the damage formula for my Phantasy Star knockoff, and had originally planned to type up my thoughts, but, well, see above. Vaccine's kicking my ass.
This week will be more work on the self-assembling System, including getting the Step handlers implemented and then running the whole thing through unit-tests.
My favorite musical instrument is the air-raid siren.
So I tried to fix up my character shapeshifting transitions. Right now when the character switches from one animal form to the next I just swap meshes, which of course looks janky. So I tried to add some FX to make it look better. The solution: a buttload of particles.
1. Spawn a bunch of particles in the shape of the old mesh. These particles hold that shape for a short period of time and then explode outward.
2. Meanwhile, particles are continuously spawning in the shape of the new mesh so it looks like "shapeshift energy" or whatever sloughing off of the new form.
3. Lastly I fade in the new mesh over about 200ms so it doesn't look so sudden.
Works pretty well so far. I need to color the particles using the mesh though, and maybe fiddle with the particle size/quantity. Also looking at the inline video I need to use higher quality video capture.
There's a series on Youtube called New Frame Plus that analyzes game animation; I remember a significant portion of the kid-to-squid-and-vice-versa animations from Splatoon being covered in particle effects. Like for a couple frames your character's model has just completely imploded on itself, but you can't see that because they're spraying ink particles everywhere and then hot-swap you to a completely different model in the middle of it.
My favorite musical instrument is the air-raid siren.
So end of the week again, let's see what we got done.
Next week summary
[*] Clean up ARPG movement system
[*] Integrate new movement in game database actor creation
[*] Build a simple core gameloop scene to share on itch.
[*] Sequence out the first scene in the tutorial level (editor).
Got 2/4 done! Alright, 50%, an F.
This week I plan on the second half, which is the itch demo for the pirate game. And maybe, just maybe we'll also get that sequence for the tutorial working.
Delivered from the parking lot as the Google Fiber technician undoes the disastrous work of his predecessor and I can't get in the door edition
Today is moving day. This report will be terse.
I completed my work on the Self-Assembling System. I am in the process of converting my previous implementations into SASes. This created a new crash bug which I solved when I discovered that I wasn't resetting a particular value to null at the end of a function. I don't know why that fixed it but it did and that scares me. I plan to work on actually understanding that bug when my computer is reconnected and I have a bed to sleep in.
My favorite musical instrument is the air-raid siren.
So this week I tried to add some polish to the pause menu GUI. I hate this sort of work so it takes forever. Anyway I added little portraits to the various choices on the menu because they fit thematically and also add interest to what is a very boring design.
Also I need to add gamepad support for these? A year ago I tried the built-in UE support and it seemed pretty wonky. Maybe it's gotta better since then but I will probably still have to roll my own.
So end of the week again, let's see what we got done.
Next week summary
[*] Clean up ARPG movement system
[*] Integrate new movement in game database actor creation
[*] Build a simple core gameloop scene to share on itch.
[*] Sequence out the first scene in the tutorial level (editor).
Got 2/4 done! Alright, 50%, an F.
This week I plan on the second half, which is the itch demo for the pirate game. And maybe, just maybe we'll also get that sequence for the tutorial working.
Onward!
Well what's better than 50%? If you said 25%, you'd be right.
[*] Clean up ARPG movement system
[*] Integrate new movement in game database actor creation
[*] Build a simple core gameloop scene to share on itch. [*] Sequence out the first scene in the tutorial level (editor).
I guess you can also count that as 50%, but I won't.
So I spent a good amount of time on unplanned things regarding ARPG. I've refactored my player/enemy classes so they are nicer to work with inside unity and I also spent a stupid amount of hours going over different implementations for enemy behaviors. I've eventually landed a simple approach that contains a "blackboard" for variables and keyed behaviors. So, if the blackboard has the string key that matches the behavior, then it does that behavior. This sounds stupidly simple but after trying multiple automated approaches I finally told myself I was just over-complicating shit.
I also created a chain lightning skill, really a chain damage skill but everyone knows it has lightning (but it doesn't have to be!). This was interesting. See, there's the initial shot which is just the projectile, but then if it hits something it tracks if there's anything on to bounce to. The interesting part was that it also has to have some outside tracker (outside the context of the projectile and what it hit) in order to bounce and for that bounce to bounce and for that bounce to bounce and so on. By tracking, I can allow it to hit only a target once during the whole chain's lifecycle. That was the learning moment there.
And I also made one of those magic orbs from like diablo, the ice orb where the wizard shoots that slow moving thing and icicles spiral outward. That wasn't as interseting, it is just a projectile with additional projectile launchers attached to it and a rotate projectile component, that rotates it (and thus the additional launchers).. So more stuff I tangentially wanted to do.
But I also put together a small scene of the pirate game! It's not gameplay but the narrative part, which is similar to visual novels. The art is obviously placeholder but I like to think they symbolize the characters well enough, as I imagine the game having anthropomorphic creatures. I've been collecting art from artstation that represent the characters for weeks now.
I'm using a tool called "Naninovel", which took a minute to learn but afterwards it was pretty quick once I got the flow. I think I'll prototype out all the other narrative scenes for the tutorial level. That should be okay since I have all the scripts already written, just need to transpose them into this new format. Still shooting for the end of this month to have the tutorial narratives done along with the tutorial gameplay, as a slice of the game. Here's hoping!
I've started work on a new game recently. My last game was an RPG, but this one is more of a memory game based on orders from customers. However, it turns out that I can reuse the biome-based random encounter logic from the RPG for biasing random customer orders. At some point I may need to introduce a terrible customer as an homage to Bubble Bass from Spongebob and change the background music to something more fighty to lampshade how this works.
With the SelfAssemblingSystem class completed (less a few border cases I discovered in the course of the events I'll recount next), this week I handled the retrofit of all existing systems into the new SelfAssemblingSystem type. As a refresher, whereas the previous System class was an abstract class with a "Process()" method during which the derived class was permitted to do whatever the hell it wanted to the ComponentStorage that was passed into it. In order to do entity queries, the System had to create a set of "ComponentBuffer" instances and hand them off to a query function. To do multi-threaded processing, you had to create a custom subclass of the Job type and hand it to a work-management class that spread the work out across multiple worker thread instances. The SelfAssemblingSystem technically does the same thing, but it uses reflection to find fields that have been labeled as query buffers and functions within the subclass that have been labeled as processing steps, and then automatically manages executing the queries and running each step in sequence on the worker threads. This avoids a whole bunch of additional typing previously imposed by C#'s scoping rules. Here's a sample System that makes objects oscillate:
public class OscillationSystem : SelfAssemblingSystem<OscillationSystem>
{
static ConfiguredFixed OscillationSystemPriority = new ConfiguredFixed("OscillationSystemPriority", SystemPriorities.Characters);
public override Fixed Priority => OscillationSystemPriority.Value;
[QueryBuffer]
public Oscillator[] oscillator;
[QueryBuffer(QueryBufferTypes.Optional)]
public Velocity[] velocity;
public bool[] hasVelocity;
[QueryBuffer]
public Position[] position;
[Step]
public void Oscillate(int index)
{
oscillator[index].Timer = (oscillator[index].Timer + 1) % oscillator[index].CycleTime;
FixedVector targetPosition = oscillator[index].Center + Fixed.Sin(oscillator[index].Timer * 360 / oscillator[index].CycleTime) * oscillator[index].Delta;
if (hasVelocity[index])
{
velocity[index].Value = (targetPosition - position[index].Value);
}
else
{
position[index].Value = targetPosition;
}
}
}
As part of this project, I went back and fixed up my "stress test" project (the one that makes little bug icons bounce around in a maze) to support all the engine changes that I've made since the last time I looked at it and took some timings. The CPU performance after converting everything to SelfAssemblingSystems appears to be worse by a fraction of a millisecond per frame, which, given that I introduced some new intermediate layers between the raw code and its execution, makes sense and the loss is perfectly tolerable. However, I was alarmed to discover that that drawing method's performance absolutely tanked, taking something like four times as long to run. I spun up the CPU profiler to look at it, and found that no matter what I did it always said "No code ran in the time period analyzed." I googled around for a bit and discovered that, oh, by the way, Microsoft broke some low-level API in Windows 10 that the CPU profiler relies on, and also they did something that fucks with Nvidia graphics drivers that's putting frame hitches in otherwise perfectly-functioning games. So I guess I won't be able to see what the real effect of this change was until Microsoft fixes what they broke.
This week I plan to finalize the conversion, removing all the code I commented out, delete the previous simple System class, rename SelfAssemblingSystem to just System, and then return to work on Ike Ika.
My favorite musical instrument is the air-raid siren.
I fell off the wagon this last month on my dev work, I've been struggling with motivation but lately I've been really bored with games and so I think I need to get myself back into game development as a hobby to fill my time. My challenge is that I really wish I felt a powerful drive to achieve things which would push me forward, but in practice my motivation seems to happen only in retrospect - after I successfully finish something I feel a strong sense of accomplishment, but I also feel a strong resistance against getting started on new things, especially at this middle phase of development where the low hanging fruit are mostly taken care of. Not knowing exactly what difficulties I'll face on my next task makes me imagine that it will be prohibitively difficult and annoying, like something that I could only do if I felt a strong surge of positive energy to push me through it. Rationally I know that it's more about discipline and persistence; I'm sure there are people who are lucky enough to just naturally feel a powerful urge to work on things, but I need to develop the skills to work around my own brain chemistry.
At the risk of being totally off-topic, I saw this video lately and was sort of inspired by it. It's nothing to do with game development but it's worth a watch if you want to be amazed at the power of human persistence.
Things have been kind of psychically enervating at my day job this week, so I've mostly spend the evenings playing Halo and watching Twitch. The weekend prior, though, I got something done: I converted the sprite drawing system's culling algorithm from the previous sweep-and-prune implementation to a grid-based system like what my collision detection system uses. Based on the CPU profiler, this appears to have had the following effects:
- The multi-threaded "update dynamic sprite positions" step takes ten times as long as it used to.
- The single-threaded "obtain all sprites on camera and render them" step takes half as long as it used to.
- The single-threaded step was a hundred times more expensive than the multi-threaded step.
So I lost a whole bunch of multi-threaded performance (proportionately) to locking contention but cut the most expensive part in half by doing so.
Speaking of locking contention, I realized that my collision detection system still had a multi-layered locking system (lock the grid, lock the layer on the grid cell, lock the grid cell on that layer) that had been rendered completely irrelevant by the revisions I did to make the collision detection system more amenable to multi-threading, and I also found a way to cache the grid cells that a particular volume falls into such that it doesn't do any locking at all if the volume hasn't actually changed which part of the culling grid it's on (supermajority case). So I actually took a full millisecond (20%) off my "high number of items in a small space" test case in the stress test, which feels great.
I'm also experimenting with another engine-level change where entity creations and deletions are all deferred until the start of the next frame. The reason for that is to make sure that every entity goes through the full pipeline; for example, if part of a character's state machine involves them shooting out a new projectile, but the animation system has already run this frame, then the projectile will be drawn with whatever its default initial sprite is, not the correct frame of whatever animation it's supposed to be playing. Likewise, if entities are deleted at the end of a particular system's processing ("the missile collided with a target, so it should be deleted"), there might be some subsequent system that requires information from that entity which no longer exists ("the target acknowledges the damage event and tries to find out how much damage the missile did to it"). Granted, for the specific example it would be possible (and idiomatic for the engine) to emit a damage event to the target, but you get the point. Having one point at which entities can enter or exit play means you have access to necessary data with greater confidence.
This week I'm doing some design work on hitboxes and damage events, trying to solve what I'm calling the "two missile problem". If you have two missiles moving in the same direction toward two targets, fast enough that the volumes collide on the same frame, you've got a situation where both targets believe that they're getting hit by both missiles. There's a couple possible solutions:
- Missiles can only damage a target as their first collision event on a given frame. This means that only the first target will be destroyed.
- All collisions a missile has in the same frame cause damage. This means that both targets will be destroyed, but also that the second target believes it's getting hit by the first missile as well.
- Do some heavy processing to find out what order the damage events occur in, rejecting damage events made irrelevant by previous collisions. This means the first missile hits the first target and the second missile hits the second target, but it's a harder solution (for the computer and for me). Naturally, this is the one I'm going for now.
EDIT: Oh yeah, one more thing. I finally got around to a minor feature in the project editor where in addition to being able to assign components to entity templates manually, you can also click on one of the game's System classes and it will automatically add the required components for the entity to be processed by that System. Takes away all the cases where I was going "wait, why isn't that system doing anything?" and it was because, like, I forgot to give the character some obscure component that system uses.
Kupi on
My favorite musical instrument is the air-raid siren.
So for various reasons it's been a while since my last update. I added new textures into the game which are the ones my partner is using on his TV series. Took a lot of work to make an atlas texture for this, perhaps not timewise but it was a boring job.
Then added some new meshes for the hangar holding the player craft, and resized it after adding some human 'peeps'.
Finally just added a Cinemachine camera, two Cinemachine virtual cameras, a Timeline for one of them, an Animator, a state machine, a Cinemachine State Camera and finally some steps I'll have to figure out exactly what later...
But there's an intro!
Kupi's Weekly Friday Sardine-Fueled Fever Dream Descent Into COVID-Vaccinated Mathematical Madness Plus Ultra
Well, it finally happened. Normally when I have a slow week, I muster up the werewithal to spend just one of the week's evenings doing something on the game dev front, so I can report on it and say "there was something". This week, there is nothing. I just had absolutely no desire to do anything with my engine. I did open the project in Visual Studio to try to work on my hitbox-resolution system, but I immediately ran into a design issue that was going to require me to make prerequisite changes, and backed away, so since I didn't actually make any changes, it doesn't count. So, here it is. The fabled "damage calculation post".
The game reviewer Yahtzee once joked that JRPGs are games for people who think spreadsheets are the highest form of entertainment. Fair cop on that; I've basically been playing around in spreadsheets for a while trying to design the damage formula for my Phantasy Star knockoff.
There's no one "right" way to design a stat system for an RPG, but here are the constraints that I worked under for this exercise:
- Like the rest of the calculations in this game, it's driven by what I call the "share of sum" term. I'll define this in the next paragraph.
- All damage calculations will use this formula; it isn't like Dragon Quest that uses one calculation for physical attacks and then has fixed damage ranges for magic.
- The damage formula should be resistant to runaway outputs. In Pokemon, for instance, a high-level Pokemon attacking a low-level one can do in excess of 80,000 damage in one attack. Particularly durable level 100 Pokemon have, like, 400 HP.
- HP and damage should fit in a three-digit display field even on the high end.
- Character stat values range from 0 on the low end to 300 on the high end. It's legitimate for a character to have a value close to 0 at any point in the level progression.
The "share of sum term" (henceforth SoS) is something I previously called "dilutive defense". Basically, it's a multiplier produced by dividing the attacking stat by the sum of the attacking stat and the defending stat. SoS = Atk / (Atk + Def). This produces a value in the range of 0 to 1, where near-0 values occur when Defense greatly exceeds Attack, near-1 values occur when Attack greatly exceeds Defense, and values near .5 occur when Attack and Defense are close to the same value. The bounds on the output from SoS turn into constraints on the output from the damage formula in total. Driving the damage formula with SoS has two potentially-contentious behaviors:
- It's easier to lose damage than to gain it. With character stats constrained to the 0 to 300 range, if the enemy has e.g. 150 Defense, the most that SoS will reach is .66 for an Attack of 300. On the opposite end, if Attack is 0, then SoS drops to 0.
- Related to the above, when either Attack or Defense are 0, increasing the opposed stat is less meaningful. i.e. if the enemy has 10 Defense, then SoS doesn't get much larger if you have 100 Attack (.909), 200 Attack (.952), or 300 Attack (.968).
So, when the damage formula is powered by SoS, your Attack stat functions more as a "which enemies are you able to get normal damage against" as opposed to letting you infinitely raise your Attack for further damage.
So, we have the SoS which scales damage, but what should it scale? I've chosen to crib from the way Pokemon handles it: in Pokemon, the damage formula (sans any more specific modifiers) is Level * Power * (Attack / Defense). The (Attack / Defense) term is the one that permits the massive runaway effects; if you have a Pokemon with 300 Attack and attack a Pokemon with 10 Defense, the base damage is multiplied by 30. The objection to using Level in the damage formula like this is that you can think of Attack as a function of Level; raise your character's Level and their Attack stat goes up. So if Level is part of the damage formula, damage grows as a function of the square of your Level. One option I considered to fix that was to simply have a fixed base damage for each attack; i.e. the basic fire spell has a base damage of 20. However, that approach has what I call "the Dragon Rage problem". In Pokemon, Dragon Rage is a move that causes exactly 40 HP of damage. In the early game, this is devastating and knocks most Pokemon out in one hit; as the game proceeds, this damage eventually becomes trivial. To work around that issue, I considered adding something like AP from Final Fantasy, which you can use to improve the moves that you have. However, that felt like too much bookkeeping to inflict on the player, and ultimately asking them to spend the AP they get from levelling up on powering up their moves feels like tying Level back into the damage formula anyway. In any event, the whole point of the SoS is to reduce the impact of potential runaway effects, and the game has a stamina system where characters' stats degrade over time. So Level provides an "anchor" for your damage, while Attack is allowed to float.
Somewhere along the line I decided to experiment with a different way of calculating SoS: ((Attack - Defense) / (Attack + Defense)) + 1. I thought this would behave differently than the previous SoS calculation, but no, actually, it behaves identically but on a different scale, producing values from 0 to 2. However, the existence of a coefficient in that equation was an aha moment for me. See, I didn't really like the idea of allowing the damage from a particular attack to go to 0. 0 is supposed to be a valid character stat value, and letting a character's attacks do no damage whatsoever felt wrong. But, rather than scale the full base damage off using SoS, we can scale a portion of it instead: Level * Power * (.5 + SoS). This produces damage that ranges from 50% to 150% of the base value based on the relationship between the Attack and Defense stats. You could also use different scaling values if you wanted a more extreme range, like (.2 + 1.6 * SoS). Either way, having this "anchor" value prevents a character from losing all ability to do damage.
So, that's the damage calculation squared away. From there, I found myself wondering how characters should accrue HP as they level up. See, there's two level-related things that reduce how many hits it takes to defeat an enemy: Attack and the base power of the ability you're using. Likewise, there are two level-related things that increase how many hits it takes to defeat an enemy: their HP and their Defense. Attack and Defense mutually negate each other. If HP grows linearly with level, then the increase in the base power of attacks over time will mean that characters die in fewer attacks as the game goes on. Now, that might actually be the correct call, making encounters more deadly with time, but my goal is to keep the same equilibrium through the duration. What this means is that character HP has to grow at an increasing rate with level, to offset the effect of increasingly powerful attacks becoming available.
Arbitrarily, I decided that the first third of character levels (relative to the expected final level you'd reach) would account for X HP gained, the next third of character levels would account for 2X HP, and the final third would account for 3X HP. e.g. if the max level is 90, and a specific character's max HP at level 90 is 900, then that character would have 150 HP at level 30, and 450 HP at level 60. Now, much as I'd like to say that I retained what linear algebra I learned from school, I actually just kind of eyeballed the values and found a formula that produced the right values at the right breakpoints. So, character HP growth involves calculating the rate of HP growth per level and then multiplying it by whatever level you're at: (.25 + .75 * (Level / MaxLevel)) * (HPAtMaxLevel / MaxLevel) * Level. However, just using that formula raw produces MaxHP values of, like, between 1 and 3 at Level 1. So, I added a diminishing "base HP" term to the formula to give low-level characters a small boost: BaseHP * (1 - (Level / MaxLevel)). BaseHP is some small value like 10. Besides making low-level characters more durable than wet tissue paper, it also nicely keeps character HP values from touching cleanly-visible breakpoints.
I'll bore you with one final detail that I observed about how attack power scales. Again, I didn't find this relationship analytically; I just kind of plugged in values and looked at the relationship. Let's say that we have that character whose HP caps out at 900 at level 90. Let's posit that a level-appropriate special move defeats this character in three attacks. So, if this character has 150 HP at level 30 (influence of the base HP term notwithstanding), then a level-appropriate attack does 50 damage. Attack damage scales linearly with level, so that same attack will do 100 damage at level 60. But the character now has 450 HP, meaning a level-appropriate attack should do 150 damage. At level 90, the character has 900 HP, the first-tier attack does 150 damage, the second-tier attack does 225 damage, and the level-appropriate third-tier attack does 300 damage. So, a second-tier attack is about 50% more powerful than a first-tier attack, and a third-tier attack has double the power. This suggests a progression where you start out with the first-tier attacks feeling prohibitively expensive, but become obligatory about a third of the way through the game, which are slowly replaced by the second-tier attacks by level 60, which are replaced by the third-tier attacks around level 90, with a final fourth tier (your Megid, Ultima, Flare, etc.) that always feels like it costs too much SP to use.
So, yeah. If I ever get around to making that JRPG of mine, I've got all the math worked out.
In the meantime, though? Still working on hitboxes. I'll see you next week.
My favorite musical instrument is the air-raid siren.
Gamemaker studio was decent enough to save backups, but I need to import every....last....resource...back into the project.
edit: One idea I had popping around was an edutainment game about language. Growing up in multilingual environments, it was very common to pick up the common bits to get around. Expanding on more and more bits to get by.
The idea would be an expansion on this, you go around to different places and communicate in different languages to people. So you set the language to Spanish, you walk around a simple Spanish speaking fantasy village using Spanish message prompts to buy and sell things, run through conversations. But having (albeit with a lot of writing and research) simple hub where you shop and talk with people.
The kick comes when you ratchet up locations and places, and learning new languages while still engaging with old ones. Then you get something from say, fantasy France, take it back to Fantasy Spain, and have to sell it using language.
Just, the idea would be gamifying not just language, but understanding.
Just kinda messing around, but I like this concept.
The idea would be a simple twin-stick shooter, potential rogue-like, but equally interesting as a classic arcade game, where you are in a constantly evolving arena. There’s no other areas, no shops, no time to stop, just see how far you get by adapting to the environment. Kill all enemies in a wave to start the next one early, allowing for speed running.
Nothing all that unique I suppose, but I’d add a i-frame dash, a melee attack that reflects shots away and definitely enemy friendly fire.
As a rogue-like the player truly has to adapt. Game mastery is most important. As an arcade game, death still brings you back to the start, but by memorising the environmental changes and enemy waves you gain genuine usable experience to build towards success.
Finally, I’m thinking there must be unlockable characters (which are simple palette swaps more or less) which each have a single passive thing to shake up the game.
A. Kill streaks (not taking damage while killing enemies) increases damage.
B. Kill streaks increase speed.
C. Dashing creates fire.
I really like how Smash Bros allows for multiple ways to unlock stuff, so to get a new character you either get a milestone high score, put in enough time or by meeting some requirement during a particular wave (shatter all crystal statues during wave 45 before they sink back into the floor).
I might call it amas amadan. Which is just “fool’s goal” in Gaelic.
I decided to have my daughter playtest my game to see what is confusing or broken. She figured out things like climbing and digging easily and talking to NPCs follows the usual conventions so there was no problem there. The thing that got her was climbing. I think this is because in BotW-clones like Fenyx Rising or Genshin Impact you can basically climb anything, but I have specific walls marked as "climbable". I thought that slapping on an extra bump map would be good enough to distinguish but she was still getting confused.
So now I'm going back and thinking about how to make the distinction more obvious. Probably non-climbing walls are smooth and single color, while climbing walls are textured and bump-mapped. Maybe I need to add a non-realistic highlight or rim-lighting to mark climbing surfaces? I don't want to go down the "detective vision" route where you click to scan the area and highlight interesting things because I personally hate that mechanic.
I decided to have my daughter playtest my game to see what is confusing or broken. She figured out things like climbing and digging easily and talking to NPCs follows the usual conventions so there was no problem there. The thing that got her was climbing. I think this is because in BotW-clones like Fenyx Rising or Genshin Impact you can basically climb anything, but I have specific walls marked as "climbable". I thought that slapping on an extra bump map would be good enough to distinguish but she was still getting confused.
So now I'm going back and thinking about how to make the distinction more obvious. Probably non-climbing walls are smooth and single color, while climbing walls are textured and bump-mapped. Maybe I need to add a non-realistic highlight or rim-lighting to mark climbing surfaces? I don't want to go down the "detective vision" route where you click to scan the area and highlight interesting things because I personally hate that mechanic.
Have you considered the yellow tape/bird poop route that's popular right now?
Yeah, making it almost too obvious would be my bet if I had a climbing mechanic that only worked in certain areas. Here I’ve made any traversal object yellow, so even if it’s not immediately obvious you can climb, the player knows that wall isn’t just a wall.
It depends on the game’s setting, but instead of flat signifying non-climb, you could throw in some brutalist anti-human architecture.
I was all ready to make up for last week with some work on the aforementioned hitbox resolution system, and then my day job was like "but what if your on-call rotation had incidents come up right after normal business hours that lasted until bedtime... twice?" so I kind of spent most of the spare time I did have not thinking about computer software. I took today off because I'd already hit my salary-mandated hour count, most of which I spent on Dragon Quest XI but at least a small part I dedicated to breaking ground on the Hitbox and Hurtbox components.
In this, I'm reminding myself to be careful not to over-design the system, because how damage propagates through game systems is highly dependent on the specific rules of each particular game, and while it would be neat to build, say, damage filtration by specific damage type into the core engine, I don't think I actually have any extant game concepts in my backlog that even want elemental resistances. So, my core feature set for now is:
- Multiple trigger volumes can contribute to the entity's combined "hurtbox".
- Different trigger volumes can be associated with different amounts of damage.
- Trigger volumes can also be associated with a priority level-- this is to enable something like Marth's "tipper" mechanic from Smash Brothers, where you only get bonus damage if you only hit with a specific hurtbox on a given frame.
- Hurtboxes can be configured to either operate in "single" or "broadcast" mode, with the former halting damage event generation as soon as a damage event is accepted by a hitbox and the latter sending damage events to every hitbox with a collision on that frame.
- Hurtboxes can be configured to be "non-recurrent", such that they set a reference to any Hitbox they successfully emit a damage event to, and will not do so (all other conditions allowing it) on any subsequent frame.
- Hitboxes have mirrors of the above; some trigger volumes used as hitboxes may have higher priority or a damage multiplier (to enable "headshots" or "hit the enemy only in its vulnerable zone").
- Hitboxes also manage the invulnerability timer for an entity, and can shut themselves off for a period of time after accepting a damage event.
I've got what I think is a workable design for the system that handles these, but you know what they say about battle plans and first contact with the enemy. We'll find out next week if my design works out! See you then.
My favorite musical instrument is the air-raid siren.
Posts
I also implemented the simplest form of verification: the truth table, which live updates as you do things. Every time a significant change is detected, a new version is produced and all the tests re-run. Incorrect values are also highlighted and you can click the input ports to see how values are produced through the system
Multi-bit wires are in too, which I knew was going to be a pain, but ends up mostly working. Gates dynamically resize if their inputs and outputs allow it. Wire splitters dynamically create output ports, mergers add new ones as needed. This does produce a potential future problem - Verilog doesn't care which end of a wire gets written, it assumes continuous assignment and will re-evaluate everything until it settles. You can technically even write an input wire and it will propagate. However for performance reasons everything I do has directionality and I only ever evaluate any specific wire or gate once, so you can't write to the output of a split wire for example. I am currently disallowing multiple logical writes to one wire though as well as combinatorial loops, so it should be fine for stuff constructed through the GUI
I was hoping the mixed colour display for multi-bit wires would look better, I guess I'll have to find another way to represent it
Next up is probably sequential logic
Not much, but I've settled on a target, at least. Knowing that I need a simple project to exercise my engine and get practical experience with the soup-to-nuts process of building and then publishing a game, I've chosen my concept for a simple shmup starring a squid who fights space aliens evil fish with the lasers it's unaccountably able to shoot from its head as the sacrificial lamb. The core gameplay gimmick is that you can have multiple weapon power-ups at the same time, with duplicates of the same weapon increasing the strength of the weapon. Then, there's a special [?] pick-up which, rather than being any particular weapon, raises all the other weapons in your possession by one level.
Been doing some basic spriting, but that fly-cycle up there is the only thing I haven't thrown out so far. Oh well! Monochrome is easily replaced.
Just to pad this out a bit, an aside on making homing projectiles. When you've got a projectile that you want to move toward a target position without using the "cheaty" way of just flatly resetting its velocity to face the target every frame, the naive approach is to accelerate in the direction of the target. However, in my experience this produces cases where you wind up simulating orbital mechanics, with your allegedly smart missile doing perfect circles around a stationary target. Here's a better way: take the direction vector to your target and multiply it by your projectile's maximum velocity. Then, take the delta between your projectile's current velocity and the desired velocity, normalize it, and multiply by the acceleration rate. Basically, you're applying an acceleration that moves your projectile's current velocity toward a velocity that directly faces the target. There are still cases where you get bad behavior, but I've found that homing projectiles implemented that way feel significantly more accurate without being unavoidable.
I completed the process of buying my new house. This has exchanged all the anxieties of buying a house with all the anxieties of owning a house.
In terms of game dev work, I also had a light week because of the above. However, there are still a few bullet points to post up:
- I wrote out a burndown list for the Ike Ika project. Basically just listing out, in vague categories, every individual little thing I will have to do before I can call the project done. That way, if I'm ever bored and listless and not sure what I actually feel like doing, I can go to the list, throw a dart, and just do that, rinse repeat until everything is done.
- Consequently, I drew a lot of the various sprites required to support each individual shot type the squid can emit.
- And then implemented the basic character controller for the squid, along with its basic peashooter shot (though neither the squid nor the shots can interact with anything yet).
- I also worked out the math that drives how the flamethrower weapon will scale with its power level, but that'll be for the whatever post covers when I actually have the flamethrower throwing flames.
Video:
So for the ARPG system, I'm at a good breathing point here. I finished implementing the convenience calls to turn databases into Jsons so someone could import/export them back and forth into their favorite text editor to make changes without Unity. There's still things that you can't change without the editor, these are the reference types (referencing sprites, other scriptables, etc.) and that doesn't make much sense to allow someone outside Unity to change, plus it would be too much so that's that.
Some next steps for the ARPG is to make things prettier and to expand on the existing systems. I added a "Deflect Projectiles" weapon buff recently, so I want to do more of that for some generic ability types. Right now Abilities are all timed based, that is, once you hit a button, it fires the ability. Well, technically it first fires a 'delay' (so people can match it up with animations and other reasons), then after the delay it fires the ability, which then fires a cooldown, and after the cooldown it does any end logic. This is all timed based, but I'm going to add the function to allow the delay to be input based, so while the player holds down X button, they delay the ability. This is most useful for charging abilities.
With the type of work changing in ARPG from building out systems to now adding in meat, I've turned my attention also to the Pirate Rammer thing I've been working on.
I ran across some new mind mapping software called milanote. I'm using it to flesh out a GDD for the Pirate game, so I've decided on things like the world, main characters, time period, story, and finished writing out a draft of the 'tutorial' scenerio. The Milanote software is nice, but you can't put much on it with the free version, but that's been a great thing! It's helped me reduce scope by reducing the scope of the GDD itself. Hah! Here's a picture of what it looks like: (spoliered for large)
So I'll leave you with a video of some changes to the crashing, really just trying out a camera shake and also added VFX that I made using Unity's VFX graph. The VFX graph is pretty nice.
Next week, get some placeholder art into the dialogue manager and implement the first story scene in the tutorial scenerio. Once I got that flow down, I'll move onto designing some areas for the tutorial.
There's nothing wrong with taking a break.
Also, weird as it sounds, thanks for telling us. Keeping a journal of sorts has kept me honest with how much or how little time I spend doing game dev, so declaring where you're at-- even if it's "taking a break"-- can be useful. Enjoy the time with your games, Zek.
I was disappointed when I learned more recently that I am not a genius, and this is in fact exactly how anime vtuber facerigs work (I tried to dig up the image I found, but alas).
However, I'm so happy with the results that I felt like sharing.
Anyways this post is mostly an excuse to say how awesome you guys are, keep up the good work!
You remember how I mentioned that I'd worked the math out for the flamethrower weapon for my game's squid? I still have the math worked out! It just turns out that the other functions of the flamethrower were non-trivial, at least compared to all the other weapons, so I went and did all of those instead:
As I noted in a previous post, the gimmick of this game is that you have five slots for weapon pick-ups. If you pick up different weapons, then you get to use all of them at the same time, but if you pick up multiples of the same one, then that weapon gets stronger. So, there's a trade-off in terms of whether you want to invest heavily in a single weapon, or have multiple weapons that compliment each other. There's also the wrinkle of the [?] weapon, which instead of being its own weapon, instead powers up all other weapons you possess. So if you have two or three weapons and fill the rest with [?], you'll have something like eight or nine effective weapon levels instead of the usual limit of five.
The five weapons on display here are:
- Laser: Shoots tiny, fast-moving projectiles. Upgrades reduce the refire time, making it shoot even more shots.
- Spread: Shoots spreads of big, bulbous shots. Upgrades increase the number of bullets per arc.
- Pierce: Shoots triangular waves that can damage multiple enemies before disappearing. Upgrades increase the number of enemies they can affect. (I may reduce the flight speed of the projectile so they can linger on the screen for longer.)
- Homing: Shoots pinwheels that home in on enemies. Upgrades increase the time the projectiles live, meaning you lose fewer shots. (I plan to reduce the base lifespan per bullet and increase their acceleration and max velocity, making the weapon more dynamic and the "hit enemies further out" upgrade aspect more significant.)
- Missile: Shoots missiles that have the highest overall DPS, but have an awkward arc that makes it hard to consistently land. Upgrades increase the damage per missile.
And then the final weapon is:
- Flamethrower: Shoots fire that damages enemies at close range and cancels enemy shots. Upgrades improve the ratio of time spent firing to time spent cooling off.
However, rather than focus on the flamethrower for next week, I have once again decided to go off on another architectural big dig. Without going into too much detail, the core of the problem is that due to the way I've set up my "job" classes, which handle parallel execution, they get access to the entity buffers that they operate on in a roundabout way. As a result, there is a lot of extra typing that goes into the creation of even a simple system. For instance, here's my "Basic Movement" system, which just takes everything that has a Position and a Velocity, and adds the latter to the former while recording the movement so that hitboxes can perform their shape-cast along the line generated:
public class BasicMovementSystem : System<BasicMovementSystem> { public override Fixed Priority => SystemPriorities.Collision; [MainQuery] WriteBackRequiredComponentBuffer<Position> positions = new WriteBackRequiredComponentBuffer<Position>(); [MainQuery] ReadOnlyRequiredComponentBuffer<Velocity> velocities = new ReadOnlyRequiredComponentBuffer<Velocity>(); [MainQuery] ReadOnlyRequiredComponentBuffer<BasicMovement> basicMovements = new ReadOnlyRequiredComponentBuffer<BasicMovement>(); [MainQuery] ReadOnlyRequiredComponentBuffer<Movement> movements = new ReadOnlyRequiredComponentBuffer<Movement>(); public override void Process(ComponentStorage componentStorage) { using (var query = BufferedEntityQuery.Execute(componentStorage, MainQueryBuffers)) { UnorderedJobs.Run(BasicMovementJob.Allocator, this, query.Count); } } class BasicMovementJob : UnorderedJob<BasicMovementJob, BasicMovementSystem> { protected override void Process(int index) { param.movements.Buffer[index].Log.Clear(); param.movements.Buffer[index].Log.Add(new MovementHistoryEntry { Position = param.positions.Buffer[index].Value, Time = Fixed.Zero }); param.positions.Buffer[index].Value += param.velocities.Buffer[index].Value; param.movements.Buffer[index].Log.Add(new MovementHistoryEntry { Position = param.positions.Buffer[index].Value, Time = Fixed.One }); } } }The buffers all belong to buffer management objects that you have to manually declare, and then you have to get the buffers out of the system, which has been handed to the job as a parameter. It's a lot of saying the same thing (especially the dereferencing) over and over and over and I'm getting kind of sick of it. I haven't implemented it yet, but I've realized that through some potentially horrifying (mis)use of reflection, I can get my system class to assemble the entity-processing pipeline out of its own public members. The final result, once I'm done, will look something like this:
public class BasicMovementSystem : System<BasicMovementSystem> { public override Fixed Priority => SystemPriorities.Collision; [QueryBuffer(QueryBufferTypes.WriteBackRequired)] public Position[] positions; [QueryBuffer(QueryBufferTypes.ReadOnlyRequired)] public Velocity[] velocities; [QueryBuffer(QueryBufferTypes.ReadOnlyRequired)] public BasicMovement[] basicMovements; [QueryBuffer(QueryBufferTypes.ReadOnlyRequired)] public Movement[] movements; [Step(StepTypes.Multithreaded)] public void AddVelocityToPosition(StepContext stepContext) { movements[index].Log.Clear(); movements[index].Log.Add(new MovementHistoryEntry { Position = positions[index].Value, Time = Fixed.Zero }); positions[index].Value += velocities[index].Value; movements[index].Log.Add(new MovementHistoryEntry { Position = positions[index].Value, Time = Fixed.One }); } }So much less typing! Now, mind you, I'm sort of burying the lede here, and there will be a lot more code in the base class's constructor than there used to be, but that's what base classes are for: to absorb all the common behavior and let you write only what you need to extend into new domains. So, the actual game development is on hold once again until I go about re-tooling my engine to support this new structure. Will it work? Who knows! I'll find out, though, and report back next week.
EDIT: If you're thinking that my system class bears an uncanny resemblance to Unity's ECS setup, I will freely admit that I have somewhat cargo-culted my design off what I saw during one of their earliest promotional videos on the system, though I think I might have wound up here independently with the goal of "describe the kind of entity the system operates on and describe the processes which be performed on said entities in as little code as possible" in mind.
It looks a little weird because you'll see a big ol' wall of brambles in unusual places but I like the unified signage. Also having piles of brambles isn't THAT strange considering I have giant magenta pyramids just poking out of the ground.
http://www.fallout3nexus.com/downloads/file.php?id=16534
Edit: Looks like it’s time to figure this out.
I hope you didn't lose anything important.
So the original goal was to get the dialogue sequencing in the Pirate Rammer prototype, and that was a success. I'm using Unity's timeline here since we're keeping it nice and simple, just linear dialogue with a "continue" button being the peak of interaction. With that done, I also brainstormed out the sequences for the tutorial and what the map will require and created a 'gameplay loop' level. The idea is to have a gameplay loop demo shareable and also the prototyp'd tutorial with all placeholder art done by the end of this month.
I also revisited the movement system in the ARPG unity asset I have, and started moving the enemies and player movement over state machines that can plug into existing ability system. This was an interesting journey that lead me into encapsulation 'states' and their trigger condition in a scriptable object, that can be plugged into Unity's editor or removed. The idea here is to allow people to build on this framework and to have it ready to plug in/out for their designers (which, let's be honest, will probably be the same person). It's probably not the most sane approach but it's an approach that's consistent with the rest so we'll stay with it.
I got some examples of roll, slash, and 8 & 4 direction walking in there, so it turned out okay. There's lots of classes that need cleaning and reorganizing, but it's a start. Also added options to the abilities so they can be interruptable by damage, death, collision, and/or another ability. You can sort of see that in the video below where I transition from the sword slash to roll before the slash is complete and when I roll into a wall and stop.
For next week, clean up that movement system and integrate it into the game database. Also, continue with the prototype, hopefully have a gameloop scene built and shared on Itch and the first scene of the tutorial level sequenced (but not shared on itch, just in the editor). The gameplay loop will require me to create a semi-okay spawning system, as it's just going to be the player boat movement and ramming unsuspecting other ships. The game feels better on a joystick than on the arrow or wasd keys, so I may also give an option to use one of those mobile touch joystick nipple things to move the boat as well.
Next week summary
Just time, i had right idea to curate and upload my protypes, should have followed through
http://www.fallout3nexus.com/downloads/file.php?id=16534
The COVID vaccine I got is kicking my ass, so I'm going to be brief this week.
I broke ground on the System class rewrite. For now, I've sequestered all the work into a new class which I'm calling "SelfAssemblingSystem", since the goal of the whole exercise is to have Systems build their own query and work-processing pipelines out of their public members. There are two big pieces to that: the queries that assemble the Component streams, and the Steps which are functions that are either run single-threaded or multi-threaded. So far, I've got the query assembly part written, and I've sketched out the outline of the Step handling classes (though the multithreaded ones need much more implementation work).
I also spent some time working on the damage formula for my Phantasy Star knockoff, and had originally planned to type up my thoughts, but, well, see above. Vaccine's kicking my ass.
This week will be more work on the self-assembling System, including getting the Step handlers implemented and then running the whole thing through unit-tests.
1. Spawn a bunch of particles in the shape of the old mesh. These particles hold that shape for a short period of time and then explode outward.
2. Meanwhile, particles are continuously spawning in the shape of the new mesh so it looks like "shapeshift energy" or whatever sloughing off of the new form.
3. Lastly I fade in the new mesh over about 200ms so it doesn't look so sudden.
Works pretty well so far. I need to color the particles using the mesh though, and maybe fiddle with the particle size/quantity. Also looking at the inline video I need to use higher quality video capture.
Got 2/4 done! Alright, 50%, an F.
This week I plan on the second half, which is the itch demo for the pirate game. And maybe, just maybe we'll also get that sequence for the tutorial working.
Onward!
Delivered from the parking lot as the Google Fiber technician undoes the disastrous work of his predecessor and I can't get in the door edition
Today is moving day. This report will be terse.
I completed my work on the Self-Assembling System. I am in the process of converting my previous implementations into SASes. This created a new crash bug which I solved when I discovered that I wasn't resetting a particular value to null at the end of a function. I don't know why that fixed it but it did and that scares me. I plan to work on actually understanding that bug when my computer is reconnected and I have a bed to sleep in.
Also I need to add gamepad support for these? A year ago I tried the built-in UE support and it seemed pretty wonky. Maybe it's gotta better since then but I will probably still have to roll my own.
Well what's better than 50%? If you said 25%, you'd be right.
[*] Clean up ARPG movement system
[*] Integrate new movement in game database actor creation
[*] Build a simple core gameloop scene to share on itch.
[*] Sequence out the first scene in the tutorial level (editor).
I guess you can also count that as 50%, but I won't.
So I spent a good amount of time on unplanned things regarding ARPG. I've refactored my player/enemy classes so they are nicer to work with inside unity and I also spent a stupid amount of hours going over different implementations for enemy behaviors. I've eventually landed a simple approach that contains a "blackboard" for variables and keyed behaviors. So, if the blackboard has the string key that matches the behavior, then it does that behavior. This sounds stupidly simple but after trying multiple automated approaches I finally told myself I was just over-complicating shit.
I also created a chain lightning skill, really a chain damage skill but everyone knows it has lightning (but it doesn't have to be!). This was interesting. See, there's the initial shot which is just the projectile, but then if it hits something it tracks if there's anything on to bounce to. The interesting part was that it also has to have some outside tracker (outside the context of the projectile and what it hit) in order to bounce and for that bounce to bounce and for that bounce to bounce and so on. By tracking, I can allow it to hit only a target once during the whole chain's lifecycle. That was the learning moment there.
And I also made one of those magic orbs from like diablo, the ice orb where the wizard shoots that slow moving thing and icicles spiral outward. That wasn't as interseting, it is just a projectile with additional projectile launchers attached to it and a rotate projectile component, that rotates it (and thus the additional launchers).. So more stuff I tangentially wanted to do.
But I also put together a small scene of the pirate game! It's not gameplay but the narrative part, which is similar to visual novels. The art is obviously placeholder but I like to think they symbolize the characters well enough, as I imagine the game having anthropomorphic creatures. I've been collecting art from artstation that represent the characters for weeks now.
The little slice is here in visual novel form
https://ventedpennies.itch.io/pirate-test
I'm using a tool called "Naninovel", which took a minute to learn but afterwards it was pretty quick once I got the flow. I think I'll prototype out all the other narrative scenes for the tutorial level. That should be okay since I have all the scripts already written, just need to transpose them into this new format. Still shooting for the end of this month to have the tutorial narratives done along with the tutorial gameplay, as a slice of the game. Here's hoping!
With the SelfAssemblingSystem class completed (less a few border cases I discovered in the course of the events I'll recount next), this week I handled the retrofit of all existing systems into the new SelfAssemblingSystem type. As a refresher, whereas the previous System class was an abstract class with a "Process()" method during which the derived class was permitted to do whatever the hell it wanted to the ComponentStorage that was passed into it. In order to do entity queries, the System had to create a set of "ComponentBuffer" instances and hand them off to a query function. To do multi-threaded processing, you had to create a custom subclass of the Job type and hand it to a work-management class that spread the work out across multiple worker thread instances. The SelfAssemblingSystem technically does the same thing, but it uses reflection to find fields that have been labeled as query buffers and functions within the subclass that have been labeled as processing steps, and then automatically manages executing the queries and running each step in sequence on the worker threads. This avoids a whole bunch of additional typing previously imposed by C#'s scoping rules. Here's a sample System that makes objects oscillate:
public class OscillationSystem : SelfAssemblingSystem<OscillationSystem> { static ConfiguredFixed OscillationSystemPriority = new ConfiguredFixed("OscillationSystemPriority", SystemPriorities.Characters); public override Fixed Priority => OscillationSystemPriority.Value; [QueryBuffer] public Oscillator[] oscillator; [QueryBuffer(QueryBufferTypes.Optional)] public Velocity[] velocity; public bool[] hasVelocity; [QueryBuffer] public Position[] position; [Step] public void Oscillate(int index) { oscillator[index].Timer = (oscillator[index].Timer + 1) % oscillator[index].CycleTime; FixedVector targetPosition = oscillator[index].Center + Fixed.Sin(oscillator[index].Timer * 360 / oscillator[index].CycleTime) * oscillator[index].Delta; if (hasVelocity[index]) { velocity[index].Value = (targetPosition - position[index].Value); } else { position[index].Value = targetPosition; } } }As part of this project, I went back and fixed up my "stress test" project (the one that makes little bug icons bounce around in a maze) to support all the engine changes that I've made since the last time I looked at it and took some timings. The CPU performance after converting everything to SelfAssemblingSystems appears to be worse by a fraction of a millisecond per frame, which, given that I introduced some new intermediate layers between the raw code and its execution, makes sense and the loss is perfectly tolerable. However, I was alarmed to discover that that drawing method's performance absolutely tanked, taking something like four times as long to run. I spun up the CPU profiler to look at it, and found that no matter what I did it always said "No code ran in the time period analyzed." I googled around for a bit and discovered that, oh, by the way, Microsoft broke some low-level API in Windows 10 that the CPU profiler relies on, and also they did something that fucks with Nvidia graphics drivers that's putting frame hitches in otherwise perfectly-functioning games. So I guess I won't be able to see what the real effect of this change was until Microsoft fixes what they broke.
This week I plan to finalize the conversion, removing all the code I commented out, delete the previous simple System class, rename SelfAssemblingSystem to just System, and then return to work on Ike Ika.
At the risk of being totally off-topic, I saw this video lately and was sort of inspired by it. It's nothing to do with game development but it's worth a watch if you want to be amazed at the power of human persistence.
@Zek :bro:
Things have been kind of psychically enervating at my day job this week, so I've mostly spend the evenings playing Halo and watching Twitch. The weekend prior, though, I got something done: I converted the sprite drawing system's culling algorithm from the previous sweep-and-prune implementation to a grid-based system like what my collision detection system uses. Based on the CPU profiler, this appears to have had the following effects:
- The multi-threaded "update dynamic sprite positions" step takes ten times as long as it used to.
- The single-threaded "obtain all sprites on camera and render them" step takes half as long as it used to.
- The single-threaded step was a hundred times more expensive than the multi-threaded step.
So I lost a whole bunch of multi-threaded performance (proportionately) to locking contention but cut the most expensive part in half by doing so.
Speaking of locking contention, I realized that my collision detection system still had a multi-layered locking system (lock the grid, lock the layer on the grid cell, lock the grid cell on that layer) that had been rendered completely irrelevant by the revisions I did to make the collision detection system more amenable to multi-threading, and I also found a way to cache the grid cells that a particular volume falls into such that it doesn't do any locking at all if the volume hasn't actually changed which part of the culling grid it's on (supermajority case). So I actually took a full millisecond (20%) off my "high number of items in a small space" test case in the stress test, which feels great.
I'm also experimenting with another engine-level change where entity creations and deletions are all deferred until the start of the next frame. The reason for that is to make sure that every entity goes through the full pipeline; for example, if part of a character's state machine involves them shooting out a new projectile, but the animation system has already run this frame, then the projectile will be drawn with whatever its default initial sprite is, not the correct frame of whatever animation it's supposed to be playing. Likewise, if entities are deleted at the end of a particular system's processing ("the missile collided with a target, so it should be deleted"), there might be some subsequent system that requires information from that entity which no longer exists ("the target acknowledges the damage event and tries to find out how much damage the missile did to it"). Granted, for the specific example it would be possible (and idiomatic for the engine) to emit a damage event to the target, but you get the point. Having one point at which entities can enter or exit play means you have access to necessary data with greater confidence.
This week I'm doing some design work on hitboxes and damage events, trying to solve what I'm calling the "two missile problem". If you have two missiles moving in the same direction toward two targets, fast enough that the volumes collide on the same frame, you've got a situation where both targets believe that they're getting hit by both missiles. There's a couple possible solutions:
- Missiles can only damage a target as their first collision event on a given frame. This means that only the first target will be destroyed.
- All collisions a missile has in the same frame cause damage. This means that both targets will be destroyed, but also that the second target believes it's getting hit by the first missile as well.
- Do some heavy processing to find out what order the damage events occur in, rejecting damage events made irrelevant by previous collisions. This means the first missile hits the first target and the second missile hits the second target, but it's a harder solution (for the computer and for me). Naturally, this is the one I'm going for now.
EDIT: Oh yeah, one more thing. I finally got around to a minor feature in the project editor where in addition to being able to assign components to entity templates manually, you can also click on one of the game's System classes and it will automatically add the required components for the entity to be processed by that System. Takes away all the cases where I was going "wait, why isn't that system doing anything?" and it was because, like, I forgot to give the character some obscure component that system uses.
Then added some new meshes for the hangar holding the player craft, and resized it after adding some human 'peeps'.
Finally just added a Cinemachine camera, two Cinemachine virtual cameras, a Timeline for one of them, an Animator, a state machine, a Cinemachine State Camera and finally some steps I'll have to figure out exactly what later...
But there's an intro!
It's $30... seems awesome if the Mario Maker community takes to it.
Twitch: KoopahTroopah - Steam: Koopah
Well, it finally happened. Normally when I have a slow week, I muster up the werewithal to spend just one of the week's evenings doing something on the game dev front, so I can report on it and say "there was something". This week, there is nothing. I just had absolutely no desire to do anything with my engine. I did open the project in Visual Studio to try to work on my hitbox-resolution system, but I immediately ran into a design issue that was going to require me to make prerequisite changes, and backed away, so since I didn't actually make any changes, it doesn't count. So, here it is. The fabled "damage calculation post".
The game reviewer Yahtzee once joked that JRPGs are games for people who think spreadsheets are the highest form of entertainment. Fair cop on that; I've basically been playing around in spreadsheets for a while trying to design the damage formula for my Phantasy Star knockoff.
There's no one "right" way to design a stat system for an RPG, but here are the constraints that I worked under for this exercise:
- Like the rest of the calculations in this game, it's driven by what I call the "share of sum" term. I'll define this in the next paragraph.
- All damage calculations will use this formula; it isn't like Dragon Quest that uses one calculation for physical attacks and then has fixed damage ranges for magic.
- The damage formula should be resistant to runaway outputs. In Pokemon, for instance, a high-level Pokemon attacking a low-level one can do in excess of 80,000 damage in one attack. Particularly durable level 100 Pokemon have, like, 400 HP.
- HP and damage should fit in a three-digit display field even on the high end.
- Character stat values range from 0 on the low end to 300 on the high end. It's legitimate for a character to have a value close to 0 at any point in the level progression.
The "share of sum term" (henceforth SoS) is something I previously called "dilutive defense". Basically, it's a multiplier produced by dividing the attacking stat by the sum of the attacking stat and the defending stat. SoS = Atk / (Atk + Def). This produces a value in the range of 0 to 1, where near-0 values occur when Defense greatly exceeds Attack, near-1 values occur when Attack greatly exceeds Defense, and values near .5 occur when Attack and Defense are close to the same value. The bounds on the output from SoS turn into constraints on the output from the damage formula in total. Driving the damage formula with SoS has two potentially-contentious behaviors:
- It's easier to lose damage than to gain it. With character stats constrained to the 0 to 300 range, if the enemy has e.g. 150 Defense, the most that SoS will reach is .66 for an Attack of 300. On the opposite end, if Attack is 0, then SoS drops to 0.
- Related to the above, when either Attack or Defense are 0, increasing the opposed stat is less meaningful. i.e. if the enemy has 10 Defense, then SoS doesn't get much larger if you have 100 Attack (.909), 200 Attack (.952), or 300 Attack (.968).
So, when the damage formula is powered by SoS, your Attack stat functions more as a "which enemies are you able to get normal damage against" as opposed to letting you infinitely raise your Attack for further damage.
So, we have the SoS which scales damage, but what should it scale? I've chosen to crib from the way Pokemon handles it: in Pokemon, the damage formula (sans any more specific modifiers) is Level * Power * (Attack / Defense). The (Attack / Defense) term is the one that permits the massive runaway effects; if you have a Pokemon with 300 Attack and attack a Pokemon with 10 Defense, the base damage is multiplied by 30. The objection to using Level in the damage formula like this is that you can think of Attack as a function of Level; raise your character's Level and their Attack stat goes up. So if Level is part of the damage formula, damage grows as a function of the square of your Level. One option I considered to fix that was to simply have a fixed base damage for each attack; i.e. the basic fire spell has a base damage of 20. However, that approach has what I call "the Dragon Rage problem". In Pokemon, Dragon Rage is a move that causes exactly 40 HP of damage. In the early game, this is devastating and knocks most Pokemon out in one hit; as the game proceeds, this damage eventually becomes trivial. To work around that issue, I considered adding something like AP from Final Fantasy, which you can use to improve the moves that you have. However, that felt like too much bookkeeping to inflict on the player, and ultimately asking them to spend the AP they get from levelling up on powering up their moves feels like tying Level back into the damage formula anyway. In any event, the whole point of the SoS is to reduce the impact of potential runaway effects, and the game has a stamina system where characters' stats degrade over time. So Level provides an "anchor" for your damage, while Attack is allowed to float.
Somewhere along the line I decided to experiment with a different way of calculating SoS: ((Attack - Defense) / (Attack + Defense)) + 1. I thought this would behave differently than the previous SoS calculation, but no, actually, it behaves identically but on a different scale, producing values from 0 to 2. However, the existence of a coefficient in that equation was an aha moment for me. See, I didn't really like the idea of allowing the damage from a particular attack to go to 0. 0 is supposed to be a valid character stat value, and letting a character's attacks do no damage whatsoever felt wrong. But, rather than scale the full base damage off using SoS, we can scale a portion of it instead: Level * Power * (.5 + SoS). This produces damage that ranges from 50% to 150% of the base value based on the relationship between the Attack and Defense stats. You could also use different scaling values if you wanted a more extreme range, like (.2 + 1.6 * SoS). Either way, having this "anchor" value prevents a character from losing all ability to do damage.
So, that's the damage calculation squared away. From there, I found myself wondering how characters should accrue HP as they level up. See, there's two level-related things that reduce how many hits it takes to defeat an enemy: Attack and the base power of the ability you're using. Likewise, there are two level-related things that increase how many hits it takes to defeat an enemy: their HP and their Defense. Attack and Defense mutually negate each other. If HP grows linearly with level, then the increase in the base power of attacks over time will mean that characters die in fewer attacks as the game goes on. Now, that might actually be the correct call, making encounters more deadly with time, but my goal is to keep the same equilibrium through the duration. What this means is that character HP has to grow at an increasing rate with level, to offset the effect of increasingly powerful attacks becoming available.
Arbitrarily, I decided that the first third of character levels (relative to the expected final level you'd reach) would account for X HP gained, the next third of character levels would account for 2X HP, and the final third would account for 3X HP. e.g. if the max level is 90, and a specific character's max HP at level 90 is 900, then that character would have 150 HP at level 30, and 450 HP at level 60. Now, much as I'd like to say that I retained what linear algebra I learned from school, I actually just kind of eyeballed the values and found a formula that produced the right values at the right breakpoints. So, character HP growth involves calculating the rate of HP growth per level and then multiplying it by whatever level you're at: (.25 + .75 * (Level / MaxLevel)) * (HPAtMaxLevel / MaxLevel) * Level. However, just using that formula raw produces MaxHP values of, like, between 1 and 3 at Level 1. So, I added a diminishing "base HP" term to the formula to give low-level characters a small boost: BaseHP * (1 - (Level / MaxLevel)). BaseHP is some small value like 10. Besides making low-level characters more durable than wet tissue paper, it also nicely keeps character HP values from touching cleanly-visible breakpoints.
I'll bore you with one final detail that I observed about how attack power scales. Again, I didn't find this relationship analytically; I just kind of plugged in values and looked at the relationship. Let's say that we have that character whose HP caps out at 900 at level 90. Let's posit that a level-appropriate special move defeats this character in three attacks. So, if this character has 150 HP at level 30 (influence of the base HP term notwithstanding), then a level-appropriate attack does 50 damage. Attack damage scales linearly with level, so that same attack will do 100 damage at level 60. But the character now has 450 HP, meaning a level-appropriate attack should do 150 damage. At level 90, the character has 900 HP, the first-tier attack does 150 damage, the second-tier attack does 225 damage, and the level-appropriate third-tier attack does 300 damage. So, a second-tier attack is about 50% more powerful than a first-tier attack, and a third-tier attack has double the power. This suggests a progression where you start out with the first-tier attacks feeling prohibitively expensive, but become obligatory about a third of the way through the game, which are slowly replaced by the second-tier attacks by level 60, which are replaced by the third-tier attacks around level 90, with a final fourth tier (your Megid, Ultima, Flare, etc.) that always feels like it costs too much SP to use.
So, yeah. If I ever get around to making that JRPG of mine, I've got all the math worked out.
In the meantime, though? Still working on hitboxes. I'll see you next week.
Gamemaker studio was decent enough to save backups, but I need to import every....last....resource...back into the project.
edit: One idea I had popping around was an edutainment game about language. Growing up in multilingual environments, it was very common to pick up the common bits to get around. Expanding on more and more bits to get by.
The idea would be an expansion on this, you go around to different places and communicate in different languages to people. So you set the language to Spanish, you walk around a simple Spanish speaking fantasy village using Spanish message prompts to buy and sell things, run through conversations. But having (albeit with a lot of writing and research) simple hub where you shop and talk with people.
The kick comes when you ratchet up locations and places, and learning new languages while still engaging with old ones. Then you get something from say, fantasy France, take it back to Fantasy Spain, and have to sell it using language.
Just, the idea would be gamifying not just language, but understanding.
http://www.fallout3nexus.com/downloads/file.php?id=16534
The idea would be a simple twin-stick shooter, potential rogue-like, but equally interesting as a classic arcade game, where you are in a constantly evolving arena. There’s no other areas, no shops, no time to stop, just see how far you get by adapting to the environment. Kill all enemies in a wave to start the next one early, allowing for speed running.
Nothing all that unique I suppose, but I’d add a i-frame dash, a melee attack that reflects shots away and definitely enemy friendly fire.
As a rogue-like the player truly has to adapt. Game mastery is most important. As an arcade game, death still brings you back to the start, but by memorising the environmental changes and enemy waves you gain genuine usable experience to build towards success.
Finally, I’m thinking there must be unlockable characters (which are simple palette swaps more or less) which each have a single passive thing to shake up the game.
A. Kill streaks (not taking damage while killing enemies) increases damage.
B. Kill streaks increase speed.
C. Dashing creates fire.
I really like how Smash Bros allows for multiple ways to unlock stuff, so to get a new character you either get a milestone high score, put in enough time or by meeting some requirement during a particular wave (shatter all crystal statues during wave 45 before they sink back into the floor).
I might call it amas amadan. Which is just “fool’s goal” in Gaelic.
So now I'm going back and thinking about how to make the distinction more obvious. Probably non-climbing walls are smooth and single color, while climbing walls are textured and bump-mapped. Maybe I need to add a non-realistic highlight or rim-lighting to mark climbing surfaces? I don't want to go down the "detective vision" route where you click to scan the area and highlight interesting things because I personally hate that mechanic.
Have you considered the yellow tape/bird poop route that's popular right now?
http://www.fallout3nexus.com/downloads/file.php?id=16534
Yeah, making it almost too obvious would be my bet if I had a climbing mechanic that only worked in certain areas. Here I’ve made any traversal object yellow, so even if it’s not immediately obvious you can climb, the player knows that wall isn’t just a wall.
It depends on the game’s setting, but instead of flat signifying non-climb, you could throw in some brutalist anti-human architecture.
I was all ready to make up for last week with some work on the aforementioned hitbox resolution system, and then my day job was like "but what if your on-call rotation had incidents come up right after normal business hours that lasted until bedtime... twice?" so I kind of spent most of the spare time I did have not thinking about computer software. I took today off because I'd already hit my salary-mandated hour count, most of which I spent on Dragon Quest XI but at least a small part I dedicated to breaking ground on the Hitbox and Hurtbox components.
In this, I'm reminding myself to be careful not to over-design the system, because how damage propagates through game systems is highly dependent on the specific rules of each particular game, and while it would be neat to build, say, damage filtration by specific damage type into the core engine, I don't think I actually have any extant game concepts in my backlog that even want elemental resistances. So, my core feature set for now is:
- Multiple trigger volumes can contribute to the entity's combined "hurtbox".
- Different trigger volumes can be associated with different amounts of damage.
- Trigger volumes can also be associated with a priority level-- this is to enable something like Marth's "tipper" mechanic from Smash Brothers, where you only get bonus damage if you only hit with a specific hurtbox on a given frame.
- Hurtboxes can be configured to either operate in "single" or "broadcast" mode, with the former halting damage event generation as soon as a damage event is accepted by a hitbox and the latter sending damage events to every hitbox with a collision on that frame.
- Hurtboxes can be configured to be "non-recurrent", such that they set a reference to any Hitbox they successfully emit a damage event to, and will not do so (all other conditions allowing it) on any subsequent frame.
- Hitboxes have mirrors of the above; some trigger volumes used as hitboxes may have higher priority or a damage multiplier (to enable "headshots" or "hit the enemy only in its vulnerable zone").
- Hitboxes also manage the invulnerability timer for an entity, and can shut themselves off for a period of time after accepting a damage event.
I've got what I think is a workable design for the system that handles these, but you know what they say about battle plans and first contact with the enemy. We'll find out next week if my design works out! See you then.