Sounds to me like Artemis isn't made for concurrent saving. That has nothing to do with what you can do with an ECS pattern - you've just chosen a particular implementation that isn't made for your concurrent saving plan.

Which isn't exactly surprising. Saving concurrently is an uncommon feature.

Damn... :/ Is it really that uncommon ? My saving operations take about 300 ms... Which is a lot and they clearly block the mainthread which causes the player to lag ^^

Is all 300 ms of that spent iterating over the game state data? Or is some of that disc/network I/O?

Since 300 ms is much longer than a frame or a typical server update tick, even the double buffering strategy isn't adequate. You're pretty much forced to snapshot at that point. Then you can take as long as you want saving from that snapshot.

Its basically disc/network/io... :/ Its not even that much, i simply insert like 18 rows... Damn that database stuff is a nightmare

That part doesn't need to block your game update. Queue up the data to be saved, then you're done reading the game state and can unlock it. Now you can continue saving the queued data at your leisure.

Basically, there's conveyance, which is how the game tells you about its mechanics, but play conditioning is how the game conditions you to play it. He explores how Demon's Souls conditions you to play the game in the least fun possible way: turtle up, avoid all risks, avoid healing and so also avoid doing anything that could make you need to heal, etc.

He explores then how Dark Souls conditions you better to play in ways that are more fun, actually encouraging dodge rolls (which Demon's Souls didn't).

And then how Bloodborne conditions you to play the game in ways that players tend to find more fun: take risks, be reckless, dodge like it's nobody's business, intercept attacks. It makes trying to shield up and be as invincible as possible.

His assertion (covered in the first ~15 minutes) is that there's a fun way to play Souls games and an un-fun way, and people have trouble getting into the series because the early games condition you to play the un-fun way... so they don't have fun.

Naturally he extends this to other games—any game may have fun ways to play and un-fun ways—but he's focusing on the Souls series as it's a stand-out example of the phenomenon.

His assertion is also that Bloodborne conditions you to play Souls games the fun way, in ways the Souls games themselves didn't. Early on he talks about his friend having a huge amount of trouble with Dark Souls and just not finding it fun, but once that friend played Bloodborne he loved it, and then he went back to Dark Souls, and loved that, too.

So conveying how your games work is important, but also, paying attention to how you're conditioning the player to approach your game is important—and if you're conditioning them to play in un-fun ways or do un-fun things, it's worth paying attention to how and why you might be conditioning them to do that.

@doppelgreener A couple other good links I've found on this topic of "helping the player find/stay in the fun part" designer-notes.com/?p=369

@doppelgreener oops, meant to say "impossible" at the end of this message

GMTK <3

@DMGregory this is a good video I'm going to refresh myself on soon, now that you've linked it. :D

Yeah, assembling my readings to give students next semester, I found they're like half GMTK. I should probably mix it up more, but he does really great, accessible vids on deep system design topics that fit into my students' attention spans..;)

He really does. There's reasons I've watched so many of his videos.

I was really flattered that he cited some of my work on Splinter Cell Blacklist's scoring system in that video. :)

We didn't publish much about it, but it was designed specifically to be a breadcrumb trail to lead players into the playstyles where the game shines best.

Hllo!

Hihi!

;)

Being a bottlneck at work makes it so that I have to work work work...

Good morning

@DMGregory do you cover paper prototyping in your curriculum?

Yep! Though for remote learning this semester the "paper" is a bit less papery this year.

What's you advice on when / how to switch from paper to pixels?

@Vaillancourt Earwormed me. 😉🎶

In particular, when trying to balance mechanics.

Oooh, intriguing question...

A game designer in my studio is starting up a Facebook community for design discussions - might be an interesting topic to float there. facebook.com/game.designer.handbook

@DMGregory ah?

For myself, I do most of my balancing in Excel. So even when I'm on paper, I'll have an Excel tab open to do quick number checks and such.

That sounds like what I'm wanting to do - I'm trying some paper systems, but wondering about how the mechanics work across many play thrus.

But I'm not sure how I would spreadsheet it out.

@DMGregory Oh!

One thing I like to do is make a simulation, where the first row is the player at the start of the game, and each row below is something the player does or happens to the player after that (like completing a mission or getting through a combat encounter). So reading down the sheet models a player journey. Different columns track the relevant metrics like score, completion counts, etc.

Ah, do you mean the decisions are all on the paper side, but you accumulate the stats in excel?

The event on each row is selected based on either a table laying out the sequence of things like missions, or a random chance based on expected play behaviour.

Then I try tuning the inputs and graphing the outputs with different random seeds, to get an idea of the kinds of trajectories I'm creating.

Looks like a thing I did in prolog at school. "simulating some actions a player could do in Monarchy" to figure out the best course of action for objective X.

Does this apply to "multiple" paths type of games?

Not so well. ;) It really only shows one path at a time. But by changing the inputs, I can try different paths to compare and contrast.

Given what I'm poking at, it seems to me that cutting some prototype code would be easier than making an excel and once written, would churn thru iterations faster. But the what's-being-simulated part is very much in flux, so I'm trying to hold off on the code part for the moment.

E.g. in AC Syndicate, at some point, you can either tackle chapter 5, or chapter 8

twitter.com/D_M_Gregory/status/922945726279274496

What I'm struggling with is smaller scale - more like given a (randomized) combat encounter, is it 'balanced'.

If I'm reading you correctly (and check me if I'm not) you're balancing an arc through multiple encounters?

For a case like that, I might treat it as though combat were turn-based. Each row is a turn, I select an agent to act, select a move for them to do, and apply the change to the relevant health totals.

Though you can get a simpler version just by computing an expected damage per turn or damage per second measure for each character, then compare that against health totals to see who dies first / how many encounters you can survive back-to-back.

My system is turn based, so that helps. The decision space is pretty large though. But applying an averaged damage per turn might be a useful stand-in.

I think mostly I don't have enough design / balance experience to have a sense, or I do have a sense, but I'm reluctant to trust it.

If this were a cooking problem, I would be "adjusting as needed to taste."

To be fair: I always feel out of my depth when starting a new balance pass.

The trick I've found is to just start trying stuff, even if it's clearly a bad approximation or crude/limited. Then add a little more, and a little more...

lol - not sure if that makes me feel better or worse ;)

Along the way I'll discover new inroads, or find new interesting angles to model and examine. Stuff I wouldn't have thought of if I'd just been armchair brainstorming the "right" way to do it.

And bit by bit the sheet grows into an unweildy monster, that actually has a lot of insight into the system dynamics.

Makes sense. I'm probably also being too impatient.

Want to chat about some of your mechanics and riff on modelling strategies together? :)

Thanks, I appreciate the offer - what did you have in mind?

Finally... i managed to find a solution which does not involve locking or cloning... hibernate offers a mechanic where it inserts childs of a parent if hes getting updated... that solved many issues :) Its kinda slow, because it needs to check for the childs first... but thats not that important because it runs multithreaded now

Be wary of saving an inconsistent state that way. A crash isn't the only negative outcome, only the most obvious.

@Pikalek If you wanted to share how your mechanics work, we could discuss how you can model those specific features.

For example, you could save the game just as the player unlocks a door. The door is still locked when your save thread visits it, so it gets saved in the locked state. But by the time the save thread reaches the player's inventory, they've spent the key and unlocked the door. So you save the game in a state where the player has no key, and the door is still locked. If the game hits an error at that point and stops, trying to resume from save leaves the player in an unwinnable scenario.

The core loop I'm playing with is 1v1, I go you go.

Each game piece has 3 attributes (offense, defense & health) along w/ a position.

On a turn, a player selects a not yet used piece & targets an opposing piece.

Offense & defense are essentially pools of d2 or coins.

Coins get flipped, any the number of heads on offense that exceeds the # of heads on defense is applied as damage to the target.

Position gives a bonus to defense - targeting through an opposing piece -> +1 defense.

Right now, there's a ceiling of +1 on positioning.

The system 'works' in so far as it simulates something.

But I think it takes more turns than I'd like.

Today I'm trying it w/ 2x stats. That's helped, but I'm wary of it becoming too swingy.

If it were code, I'd set it up to generate rando encounters apply a basic strats (target least def, target lowest health or something like that), dump it all into CSV & excel it up.

That sounds like a sound strategy.

Yes, and maybe that's the only way to generate enough data to get a sense of it. I was hoping to due more on the table top side first though. I feel like I have a habit of jumping to code before the idea is fleshed out.

You could also make an Excel sheet (or game prototype) that rapidly calculates the expected outcome of a given attack. Then you can playtest by hand, but using the Excel/prototype to accelerate the number-crunching.

True. Looking at that would probably help me see the skew & I suspect I'm not visualizing that part correctly.

And that's a small enough piece of code that it's not likely to become a precious darling.

Thank you for the feedback.

hey

Hello

How are things going?

Pretty well. :) Got a bit nerdsniped by Pikalek's modelling problem...

How are you?

I am meh, just a little bit of stress, but gonna try and get some work done on my game, regardless

@DMGregory Woah. Thanks - certainly wasn't expecting that. Even just seeing the layout is insightful - I hadn't considered some of the side calculations / metrics you set up.

I hadn't either! At first I was thinking "hmmm... can I implement bresenham's line algorithm in a spreadsheet...?" then was very pleasantly relieved when I realized I wouldn't have to! XD

@DMGregory lol!

nice!

I wonder if "Excel Guru 101" is part of any gamedev school programme...!

It's more or less what I'm teaching this year. :)

Systems Design in the fall, where I'll be getting them to build spreadsheet models for systems. Then Data and Design in the winter, where we'll be working on telemetry and analysis. :D

Nice! We did not have that stuff when I was doing my course1

The programme was more oriented toward programming and less on design.

That was fine for me, but some other students were... surprised. I should mention that they did not read well the list of classes offered. As such, we were like 100 students at the beginning, and only about 25% of all actually finished the programme.

Yeah, it's a tough balance. We're a very design-focused program, but we still get folks who want to do art or programming, and we have a lot of work to do in establishing what "design" is as its own discipline.

Yeah, I suspect that when I left, students who wanted to enroll were met and explained to what it was about exactly. I think they might have modified the program name too.

Getting this across seems to be a thing it itself for programs directors :P

And I guess the target audience "doesn't know" that the list of classes is well spelled out and they have to read it. At lest that was the feeling I got when I got there with all those folks.

A lot of folks use the term "game design" as a synonym for "game development", which blurs the lines there too. Students often don't understand the differences when evaluating programs to apply to.

yeah

I mentored a team that thought they didn't need a designer

they didn't get very far

Yeah; you need someone to think about design, someone to think about the story, someone to think about the code, etc... One can do it all by themselves, sure, but... time...

Also, the more specialized your team is, the more it helps to have someone who can go between the silos and translate the needs of one into potential solutions using the others.

Yep!

The nice thing, though, is we you have a team where people know their roles and their own limitations, but are still willing to learn!

Also, we've kind of decided that we'd like to multi-thread our app.

Ooooh, fun™

Oh yeah!

I suspect it's going to be a long hard road. Most likely not going to happen in the next iteration of our software, maybe the one after if we are able to sort all the things.

And kill all the singletons.

🔪

oh no

multithreading

hard

Yes; but we kind of need it now.. We simulate trucks scooping and dumping rocks. That physics phase takes too long because we also need like up to 5 cameras rendering the scene.

I'll try and look for ways to eventually shove that into a DLL and wrap an editor around... just for fun, you know!

:D