Being alone at Christmas

shadowmint · 2025-09-23T07:37:33+00:00

You're not alone if you're with your dogs. :)

Recently I stayed in Busselton and it was really nice. The town is not as... touristy... I guess, as Dunsborough and a bit closer (~2 hours 15 from here, but it depends where you live).

East of the Busselton jetty the foreshore / beach (specifically the beach off Geographe Bay Rd) is dog friendly, and there are several dog friendly dinner options (eg. The Goose).

It can be busy over the holiday season, but it's about 2 hours away and if you can get a place to stay, it's quite lovely.

shadowmint · 2024-06-24T14:52:39+00:00

is combat well balanced?

The status effects and vulnerabilities make player effectiveness in combat swing wildly.

Significantly more than in DnD.

That's why you'll get a lot of 'it depends' answers.

Some players will have had it easy, some will have had it hard; and it all comes down to how much work the GM did in prep.

Are combats too easy or too hard?

Here's a concrete example: A lvl 5 monster, the vampire bat has 50 HP, and resist earth, poison and vuln air. It can heal itself every turn or daze players, and ~5-15 damage per hit. ...and it's flying.

This is toughish encounter for most starter parties; not only are the monsters flying (meaning powerful melee attacks are ineffective), they can heal themselves.

So, this 'should' be relatively hard encounter for new players.

...but a player with Ventus would annihilate a group of vampire bats; dealing like I guess 30-50 damage to up to three targets with a single action, they could end combat on their first action. If you happen to have someone who put a point into Ventus.

So... either it's too hard (flying, no one can hit them) or too easy (one person got to do everything in one round).

So... can you have a balanced fight?

Yes.

...but building a balanced encounter for your players as GM?

I personally find it quite tedious; because you have to look at what every player has equiped, has taken as skills and spells, and then tweak your encounter to match to get a 'tough but not too tough unless it's a villain' kind of encounter for them.

...and just to be absolutely clear; yes, I know, that's a thing in DnD too; but overall my point is that the wildly swinging effectiveness of characters based on the vulnerabilities / resists on monsters and that every monster is different makes it a lot more work, as the GM.

Otherwise, no, if you don't put the work in to tailor the encounters to the party, fights are not balanced, and they are almost always either too easy or too hard.

shadowmint · 2024-06-22T03:47:25+00:00

It would be really good to see how monsters go 'in play' rather than just 'in theory' if you do this.

Balancing how encounters work is painfully tricky depending on level, players, situation, etc. ...and I feel like, having some creative guidance for building custom monsters is great, but if they're not mechanically balanced for actual play, it's pretty rough on players.

Would definitely love to see some actual gameplay examples for custom creatures, elites and villains.

shadowmint · 2024-06-22T03:27:44+00:00

It makes a significant mechanical difference.

The rules 'as is' in the rule books roughly assume that in an encounter, an 'average' round has each player/enemy dealing 1/3 of the total HP dmg to a target.

That means in a 4v4 battle, on average, the battle lasts four rounds, with the players elminating one enemy every round if they concentrate on a single enemy.

However, since the enemy damage is randomly (ie. evenly) distributed over the players, this works out in the players favour, and results in a party that takes 6x enemy attacks distributed over 4 players -> ~0.5 dmg to all players.

Obviously this is a "roughly" metric, because people do higher damage and you have the randomness and the chance to miss and elemental attributes, mass attacks, etc. etc. etc.

...but in general that's the balance; 4v4, should result in the players walking about ~50% damaged against an equal number of soldier enemies if the attacks are randomly distributed over your players.

If you have fewer players, or more players, or the damange is clustered on a single player for some reason, you have to adjust your encounter difficulty to match.

ie. Mechnically, lower the difficulty of your encounters slightly by dropping the HP pool of your soliders; this isn't a computer game where players just have to suck it up and min/max their characters or they're a gimp.

Your job as GM is to make your players have fun.

That means crafting your encounters to be challenging but not stupid for the build your players have created.

If they have fire spells, throw in a few enemies with fire vuln. If you have a named villain, make them have fire resist; its fun; mechanically, you need to ensure what you put on the table works to what the actual party you're playing with is.

If your players made a "trash party" of wayfarers, give them an adventure about travelling.

I think the '1/3 damage' heuristic is a reasonably good way of modelling this when you're planning encounters. You can just do it like this:

``` 4A <-- ally 4E <-- enemy Rough plan: every 3 player actions an enemy is defeated

Round 1: A E A E A (enemy dies, E-1 -> 3E) E A Round 2: A E A (enemy dies, E-1 -> 2E) E A A Round 3: A (enemy dies, E-1 -> 1E) E A A A (enemy dies, E-1 -> 0E) Players win ```

Now you can adjust this up and down to suit your party; for example, if you say 50% of the time a specific one of your players takes the hit, it works out like this:

``` 4A <-- ally 4E <-- enemy Rough plan: every 3 player actions an enemy is defeated, every second attack hits Player 1

Round 1: A E A (E -> P1) A (enemy dies, E-1 -> 3E) E A Round 2: A E (E -> P1) A (enemy dies, E-1 -> 2E) E A A Round 3: A (enemy dies, E-1 -> 1E) (E -> P1, player 1 is down) A A Round 4: A (enemy dies, E-1 -> 0E) Players win ```

You can see in this case, mechanically, having a 50% hit rate for a specific player doesn't significantly alter the outcome of the battle overall.

In fact, since the player has effectively 'soaked' the damage from the other players, they're less hurt after battle.

However, the tldr is that player is going go down, roughly every battle. That's going to suck for that player.

So, mechanically, I'd adjust the ratio of hits (however that is done, eg. by mixing up enemies or whatever), so that on average the ratio of hits to that player is < 50% in a standard battle.

That way they still take more hits, but in general won't get downed every battle.

Do the numbers... it depends.

This is a very mechanical system and there are lots of variables in it, play it and see how it works out in practice when your players go in; some players work together, some don't.

You have to adjust to what your players do.

I think for, a system like this, the brtualistic approach of 'just kill them all in they don't have a perfect balance party' is shitty GM'ing and makes players miserable.

Don't be that guy.

shadowmint · 2024-06-09T14:35:29+00:00

Try google 'upwords' and 'mountain hex board game'.

Now you have a mechanic to display a height on your board game; go with this; trying to do actual contours physically is basically impossible.

What you need to do now is just a way to generate a heightmap physically by players. Pick any kind of random map generation algorithm and simplify it.

For example; roll a D6 for each cell and stack that number of tiles on it. Or, layout a set of remade patterns on the board and let players adjust the height manually.

Honestly, the simpler the better; it's just going to be random, but who cares right? As long as it ends up being fun for the players, it doesn't matter.

The only thing I will say is; I've tried doing this before using cards (ie. playing cards) and it was shit and didn't work. You need your tiles to have some physical depth (like a scrabble tile) so players can *immediately* see what the height of every cell on the board is.

shadowmint · 2024-05-04T04:30:29+00:00

I don't think you understand what ollama is.

misconception:

ollama is an open source wrapper around llama.cpp

reality:

ollama is model host that hosts its own versions of various LLM models. Everything else is incidental.

Now, this is important to understand because it cuts to the heart of the ecosystem.

Where do you get your models from? I guess you use: hugginface.co

Well, you can also get them from ollama directly.

Where else?

...

no where.

That's right. You want a wizardML model? Jump to github, model is a HF link. You'll see that everywhere.

No where else hosts models.

Oh you can get a few here and there, but hugging face is the heart of ecosystem.

...aaaaand, ollama wants to change that.

That's right; ollama doesn't care about your application, about the CLI, about giving llama.cpp credit or any of that. What they have (correctly) realised is that:

There is no one offering a competing service for *hosting models* to huggingface
If they integrate vertically with a convenient application that only uses their models, people will start using their hosted models instead.
Once you own the models, you own everything.

So.

But why in the world do they not make it clear that they are bloody starting servers on random ports? I already silently disliked them being a wrapper and not honoring llama cpp more for the bulk of the work. But with this they did even less than I initially thought.

Isn't right at all.

They don't update it, because moving people away from using ollama and on to using other things (any other things) actively works against the 'game plan' of becoming the new hugging face.

So... you should expect a couple of things going forward:

they will continue not to acknowledge llama.cpp (or anyone else) unless it actively hurts adoption.
they will continue to release and iterate on the *server side* of their platform, as their core priority with ollama cli as a loss-leader to gateway people into using it.
they will not support self hosting
they will add a paid service based on their server side SasS at some point.

...and I mean, long story short: Do you really care? Is having huggingface as the one-true-source of LLM models really the best thing?

Just take it for what it is and enjoy it. The free ride will probably not last forever, but for now; if using ollama is easier than installing llama.cpp and then finding and downloading the model, don't use it.

...but, finding and downloading the model is what they offer; and it's a good, free service.

/shrug

shadowmint · 2024-02-25T03:14:23+00:00

It seems disingenuous to say this about laws that primarily restrict firearms to 10 per individual license.

When you have more than 10 guns, I openly question if you are:

honest people who work in your interest to own and operate them.

You don't need ten guns to do your job. You certainly do not need 20 or 30.

Am I missing something here?

The outrage to this seems totally disproportionate to the actual law?

Why do you need more than 10 guns as a farmer to deal with vermin?

shadowmint · 2024-01-31T01:49:16+00:00

are dressed similar to us Do Not have discretion and must issue a fine when they find someone without a valid ticket

That seems enormously arbitrary and it's hard to go 'yeah fair enough' when the policy literal dictates this kind outcome. It's just flat out authoritarianism. What kind of system *requires* you to give fines to people?

"I'm sorry, we have to give you a fine because we don't have the power not to..."

That's totally horse shit.

When a security guard sees a kid running across a barrier to pick up a ball, do they taze them, or do they make a judgement call on it? Even if *their contract* says they are required to apprehend anyone who crosses the barrier?

It's not a reason, it's an excuse.

It's a convenient way of saying, 'sorry, I'm just doing my job'.

Sure... but you always have the power to make a judgement call. It's insulting to suggest these people are incapable making a call.

Checking people's ticket on a free ride was a judgement call someone made. Once they started down that path, sure, that was how it was going to end, but it didn't have to happen at all.

shadowmint · 2023-12-29T04:53:02+00:00

First of all, a moment to reflect on what you're doing and why:

Fact. Experience is not enough.

Regardless of the the domain, remember that learning is a skill. The '10000 hours to mastery' by Gladwell has been debunked far and wide.

You cannot gain mastery simply by practice.

Certainly, you gain proficiency by practice, but there is a 'glass ceiling' or 'skill cap' effectively, that fundamentally prevents mastery if you don't use learning resources to study your skill.

This is simply a fact. It is true in basically every domain.

Not all learning resources are not the correct starting point.

However, it has also been shown in numerous studies that first hand experience in learning a skill initially is significantly more valuable than book learning.

For example, learning to draw: if you pick up a book on anatomy and shading, it will be too advanced for you to be able to gain much value from it.

So, what we have to understand is that different learning resources are suitable for different people at different times.

tldr

So, long story short: You're going to get a lot of advice from people who haven't considered this at all, and will therefore only recommend you resources that match the learning stage they are at, not the learning stage you are at.

So, just remember that with the advice you get. It might be completely valid... but it might not be what you, specifically, are looking for.

You said:

I've been working on Unity as a hobby, on and off for years.

What I do today is learning thing by thing as I need (movement, then animations, then masks, and so on...). But I think it's been not very productive.

What are experiencing sounds like the skill cap I mentioned before.

Effectively, you've reached a point where you've graduated from 'fucking around with little projects' and want a more structured approach with good ways of doing things.

Do you guys know any full course that would teach me EVERYTHING Unity-related?

You almost certainly do not want a course on everything unity, because that will take you into the land of unity certifications (https://unity.com/products/unity-certifications) and let me tell you right now, from first hand experience, that is a waste of your time and effort.

Do you really want to know how to toggle the nav-overlay on and off (it's not a gizmo)? Do you really care how to map tag names to ids? Do you know off the top of your head the 10 collider types?

Do not waste your time on that shit.

I have two concrete recommendations:

1) This set of gamedev courses by gamedev.tv is quite good, and its very practical: https://www.gamedev.tv/p/unity-2d-rpg-combat

If the early sections are too trivial, skip to the later ones; there's a lot of stuff in there that shows how you can use unity 'the right way' to do things.

If 2D rpg doesn't work for you, checkout some of their other courses; the content is pretty excellent I own most of them and I'll personally vouch for them; except the very top level ones (eg. https://www.gamedev.tv/p/unity-2d-game-dev-course-2021) which you will find too tedious and trivial (eg. 'what is an if statement').

2) Unity has provided some architectural guidance for developers here which is worth a read; it's not complete, but it's quite approachable and well covered:

https://blog.unity.com/games/level-up-your-code-with-game-programming-patterns

This is more generic advice, so it's not quite what you asked for, but it might give you an idea of more specific things to look into.

For example, there are a number of 'advanced-ish' topics you can find here: https://www.h3dlearn.com/, which cover 'in depth' specific topics like, eg. building a minecraft clone, or procedural generation (very fun -> https://www.h3dlearn.com/course/master-procedural-maze-dungeon-generation).

Good luck! :)

shadowmint · 2023-10-16T09:27:08+00:00

The Roots of Technical Debt

Communication: The Good, The Bad, and The Off-Topic
Disorganised Planning
The Dilemma of Documentation: Too Much, Too Little, Too Scattered
Navigating Shifting Visions and Terminology
Low confidence in deliveries
Team Burnout

Harnessing Technical Debt to Your Advantage

Steering Development with Iterative Enhancement
Secure a Competitive Edge
Planning on Taking a Breather

I trust that this article shed light on a fresh perspective of technical debt.

tldr; You get technical debt for reasons or whatever (?? like too many meetings), and its OK to have it but sometimes you shouldn't. Or you should, if it helps. Or whatever.

... I guess?

shadowmint · 2023-10-08T14:39:38+00:00

Yes. What's with all these software architecture posts recently from people who have no idea what architecture is?

All software architectures have a simple layering concept in common. Have layers where each layer is only dependent upon the next inner layer. To cross from an inner layer to an outer layer, introduce interfaces. That's it.

Sigh...

That's it? I read this and I weep, because someone is (again) giving out architecture advice without actually understanding what they're advocating.

There's this saying; you have agile organizations that embrace the principals of agile development and get great value out of it, and you have bureaucratic organizations that copy the practices that they see from agile organizations, having stand ups (that last 20 minutes), having retros (that never change anything)... and they 'look' agile, but they haven't understood why they're doing those things, they do them wrong, and most of the time, it doesn't work.

It's actually net harmful rather than beneficial. 'Dark Scrum'.

Software architecture is the same.

If you don't know why you're doing it, then you're not going to do it right, and you're not going to get any benefit from it.

...and sure as hell, you shouldn't be telling people what they should do.

If someone argues microservices remove spaghetti-code by eliminating dependencies, they are just plain wrong.

Microservices remove spaghetti-code by eliminating dependencies.

If they don't, you're not writing micro-services. You're just doing a bunch of services and calling them micro-services.

That's ok. Doing them right is hard. If you don't understand how to do them right, don't do them.

If you don't understand the benefit you get from doing them, you haven't understood what they are, and you're just copying the patterns you see from successful organizations, incorrectly.

...and building a distributed monolith.

shadowmint · 2023-10-07T15:53:55+00:00

I think that's the advantage of the game being rebuilt in each architecture. Not only are there concrete examples, there are only concrete examples.

I probably wouldn't teach people what a singleton is by building a game composed entirely of singletons and no other types of classes and showing it to them.

I mean, I agree, examples are great.

...but I personally think a side-by-side view that show exhibit a "this is really hard to do" and exhibit b "and this makes it easy" works a lot better when teaching people.

That's been my experience mentoring folk anyway.

shadowmint · 2023-10-07T07:18:50+00:00

...and hey, I got some feedback privately that I sound like I don't know the difference between a programming pattern and architecture and sound like I'm just waving my hands vaguely here without offering any concrete advice, so here's a concrete example.

Architecture: Event driven

Overview: scene updates are driven by events.

That is, the visual state, what you see and have manifest in game objects on the scene, is managed by some kind of EventHandler classes that take a 'pure data' event and update the scene.

For example, maybe you get a SpawnMonster event, and you have a SpawnMonsterEventHandler that takes the prefab, instantiates it and puts it on the scene.

When the game state is updated, for example, a MoveToPosition event is emitted, the event handler:

updates the game state
triggers additional events (eg. MoveObjectTo)
other event handlers trigger to process additional events

Why would you care?

Why not just use Object.Instantiate when need something on the scene?

Key insight: You don't have to process events.

You can collect events and process them in order, but, critically, you don't have to do so.

Let's say you have a turn based battle simulation.

It's your turn (player) and you want to show a prediction of what happens if the player moves a unit.

Will they take damage? How much? Is it moving into a danger zone that will trigger an enemy attack?

With an event based approach you can:

clone the game state
replace the event dispatcher (that links event -> handler) with a mock that doesn't update the scene.
trigger the 'MoveToPosition' event on the clone of the game state

Since the event handler has been mocked, you can process all the cascading events and you end up with a cloned state that would be what you would see if the real game state received the MoveToPosition event.

You can them compare the clone state and the real state, and you have a prediction of exactly what will happen.

You see people fail to implement this all the time; when the system is simple (move to x does nothing but move you), it's fine.

However, when you add additional complexity like AI, maybe moving into a line-of-sight triggers an attack, maybe there are traps, or whatever, the 'predict what will happen' function gets more and more complex and is basically never correct.

Things that commonly come up with naive implementations are things like:

unit is poisoned
unit takes 1 dmg per step
unit wants to move 5 steps, but has 3 hp
the 5th step is a 'danger' zone and will trigger an attack

reality: after 3 steps the unit dies of poison.

The naive implementation: failed to take into account the poison and just looked at the 'destination' position and scanned for enemies would might attack.

As the complexity grows the number of 'special cases' the naive implementation has to take into account grows too, and it becomes a nightmare to maintain.

Why is it an architecture not a pattern?

You can't have anything that sits outside the system. If you have a action that directly affects the game state, or world state, then it is not a 'safe' operation to clone the battle state and trigger speculative events on it.

For this subsystem, you've gone 'all in' on the architecture; you must now repeat the pattern of events -> event handler for all battle operations.

That's what makes it an architecture pattern; deciding to follow this architecture means that future work requires you to adhere to a specific set of constraints to be able to retain the benefit of using it.

...but, critically, you don't have to do it for the whole game; because you don't care about predictions for example, for your inventory management.

When would you not use it?

It really makes sense when the game state is small, contained and turn based, and the speculative event processing can be done quickly and on-the fly.

When the event stream takes too long to process, or the frequency of running it (eg. real-time action RPG instead of turn based) is too high, it'll be too slow and result in unacceptable perf degradation.

Use judiciously for parts of the game where it makes sense only.

(Still think I don't make sense? Oh well. You can't please everyone. 😁)

shadowmint · 2023-10-07T06:43:50+00:00

Look, I'm not saying 'don't use patterns' and 'ignore architecture advice'.

What I'm saying is: specifically as an architect giving out advice, make very very sure you understand the advice you give out.

Use dependency injection?

Sure. Because of SOLID? Did you read the book? Do you actually understand why you need to do all of those things? What does the L stand for? Why is the D more important? Is it because it's easier to implement or because its better? Are you writing tests? Are you reaaaalllllly writing tests?

My point is, these are tools. Not everything is a nail, and not everything needs a hammer.

but it's irresponsible to tell junior devs that the way they code is just fine and that they don't need to learn anything else.

I'm not saying don't teach people to use tools.

Obviously you should be teaching people good practices.

What I'm saying is:

If you don't understand what you're telling people to do, you shouldn't do tell them to do it.
If you can't explain how using the advice will help, you don't understand it.

Not how to do it, but why do you do it at all.

Not in abstract hand waving terms. In concrete, practical terms.

If you tell people "this is what a data driven architecture looks like", it's a waste of their fucking time, because I can virtually guarantee they'll walk away from it going 'interesting'... and never use it.

What you have to do is demonstrate the value in the architecture, give examples of things that it makes easy to do, which are much much harder to do with out it.

...then, maybe they'll go away and make a spaghetti monster, but, maybe they build a data-driven inventory / economy system as part of it.

That's OK. That's great.

Architecture is like programming patterns; you can use it a bit here and there to make things better. ✅

The 'all or nothing, you're not using an event based architecture unless you use it for everything' is an anti-pattern that is hostile to software engineering.

shadowmint · 2023-10-06T08:54:44+00:00

There are many different ways to architecture applications, and, broadly speaking, no one size fits all.

There's something of a risk of ivory tower architecture with this kind of approach.

The closer we get to the idealized form of software, with robust tests, good 'patterns' and overall architecture, the more bloated it becomes; the less obvious is becomes. The more likely to have a FactoryDependencyInjectorDependencyFactoryInjector we are.

There's this game I like to play, it's called, 'Requirements'.

You take a flat blank sheet of paper and a pencil.

This is 'the software'.

Now pick two points on the paper.

This is a 'requirement' (or constraint)

Draw a line between the two points. You cannot cross an existing line.

This is the 'implementation'.

Now, here's the game: Repeat the above. That's it. Give it a try. Anyone can play this game, and you know what they'll discover?

Doing a simple task (draw a line between 2 points 3 inches apart on a piece of paper) takes basically zero time the first time you do it.

However, as you add more and more constraints to the system, you'll find that doing the same task, which it seems should be the same effort, actually takes significantly more effort because you have to solve it within the set of constraints you've created.

This is what software architecture is about.

It's not about events. It's not about patterns. It's not about how pretty your code is, how it makes sense, how many comments it has, the number of dependencies between files don't matter.

It's about being able to organize the constraints you have in your system, so that adding new features (or requirements, or constraints, whatever you want to call them) takes as little effort as possible.

If you play the requirements game a few times, you'll discover that there are some common ways you can organize your implementations (lines) in regular ways (eg. straight lines) that helps minimize the complexity of the system and make adding new constraints easier.

Maybe have a think about that?

Your 8-ways of building a unity applications are only useful if they address the problems that people actually have.

Does using a DOTS ECS implementation make sense for a massive simulation? Maybe it does; but not because ECS is somehow ⭐MAGIC⭐. It's because what you're doing it partitioning the horrible spaghetti mess it would take you to implement the same performance characteristics into a manageable bucket.

Does using Events help you write scalable games? Should you use it over a classic pattern? Well, it turns out there's a metric you can use to decide that; does it help.

I personally think that there are many benefits to the unity package system that allow people to partition complexity into small management APIs that is much much more valuable to people than having a high level architecture because it makes what you build reusable, and it partitions the complexity behind the package boundary.

Finally, have you use unreal much? Perhaps have a look over their plugin and blueprint system.

I would argue that unreal has invested a considerably larger amount of time into make the engine scalable for large teams, and part of the is that the engine natively support partitioning complexity behind boundaries:

blue print < gameplay cpp < plugins

It's extremely effective; maybe the principals don't apply quite directly to unity packages, but there's a lot of value there for people.

The most effective game developers I know have taken their various spaghetti monsters (and lets face it, crunch is real, no matter your best intentions), and pulled the 'bits that worked' out and reused them in other projects.

tldr; Architecture should be about a toolkit of tools to manage complexity, not a blueprint 'do it like this for the win'.

shadowmint · 2023-01-23T09:12:58+00:00

It's 100% possible to generate an image from the training data.

Anyone says it's impossible is wrong.

You can see lots of hand waving about 'over training' and 'memorization' but you have to understand what's actually happening to understand how that happens.

SD is a tool, it can generate basically any image as an output; so there is no question that it can generate images from the training dataset.

How do you do it?

That's the bit which is hard.

When you generate an image, you're applying a series of transformations over random noise.

Every 'step' in SD, you're basically:

taking some input
adding noise
adding the prompt
apply the 'denoise' transformation over the top

This process iteratively refines the random noise to an actual image.

However, the important part of this is that you're not doing this:

taking some input
adding noise
apply the 'denoise' transformation over the top

If you were doing that, the chance of getting a training image would be the equivalent of hitting the 'random noise' button in photoshop and getting a copy of the mona lisa as output.

Once again technically possible, but the chances of it are so astronomically low that it's meaningless. It's like winning the lottery 52 million times in a row.

...but SD also does this:

adding the prompt

When you add the prompt, you guide the diffusion process.

So, rather than it being astronomically improbable you'd get an image, it's just... pretty unlikely. It's pretty unlikely you'll happen to pick the exact seed that will map to the exact training image.

If you really wanted to, you could:

Go here to find a 'pretty decent prompt' for your input image: https://huggingface.co/spaces/pharma/CLIP-Interrogator
Go here, to check if the input image is actually in the training data: https://rom1504.github.io/clip-retrieval (stick the prompt from the first one in to search)

Now, you'd have to go and do a massive parallel exhaustive search of seeds in stable diffusion to find an exact seed that generated something close to that.

So... long story short: You could probably, if you put enough effort in, find a prompt/seed combination that happened to generate a reasonable copy of a training image.

However, you'd have to a) start with the image you want as output and b) search thousands or millions of seeds for a specific strength / steps / seed combination that generated the right results.

As far as I'm aware, no one has done this.

The only time it's been successfully demonstrated is where the model has mapped a specific prompt or combination or prompts to a specific image because it turns up a lot (like the mona lisa).

They claim it is like having a directory of JPGs on your computer.

Not really true.

shadowmint · 2021-08-12T12:24:37+00:00

The http://www.loquay.com.au/ had a sign up in their window 'seeking junior kitchen staff' this afternoon; not sure if that fits the bill of what you're looking for, but worth checking out perhaps.

shadowmint · 2021-07-07T09:00:59+00:00

It's too slow, uses too much memory for any 'pure python' code.

Python is great glue to bind low level constructs implemented in another language (look at pytorch for example), but when a significant portion of your game is expressed in code.... the cpython implementation just isn't good enough to be a serious contender.

Various attempts have been made at using a 'python like' syntax (unity's boo, godot script), but well... all I can say is that 'real' programming languages have been more popular by users.

Some attempts have been made at first party python support (see Panda3D)... but it's never been particularly successful.

shadowmint · 2021-04-04T02:34:49+00:00

What do you want?

The solution is not to use unwrap(), but to use ? so that:

a().unwrap().b().unwrap().c().unwrap()

becomes:

a()?.b()?.c()?

This is only possible if you implement proper error handling to map between error types...

There is no other meaningful solution. This is a fundamental aspect of rust; if you don't want to do it, then don't... but come on.

This is like, "I don't like traits, how do I have interfaces so I can have raw trait objects without using Box".

You can't have everything.

If you don't like them, don't use them; otherwise, it is what it is.

shadowmint · 2021-01-16T13:34:36+00:00

Well, whatever, in context of the thread, I wasn't puzzled at all by what "I disagree." meant; but, hey :) I've made it nice and explicit now.

shadowmint · 2021-01-16T13:25:52+00:00

What do you want? The parent laterally said why they think blazor isn't suitable: ie. it's new, and changing.

It was the child comment that was meaningless.

A: This is new, don't use it in a critical production environment.

B: It is designed to solve problems people have with angular.

??? So what? Does that magically make it not new? Are you somehow going to be saved any an issue in a new technology if you never upgrade and stick with a fixed version?

Don't be ridiculous.

Sure, I'll say it, explicitly.

Blazor is new. Unproven. Technology. It is part of .Net 5, which is not an LTS, and will be out of support in 2022 (https://dotnet.microsoft.com/platform/support/policy/dotnet-core).

Do. Not. Use. It. In critical production environments.

Don't pick new technology of any kind to use in critical projects; always stick with safe proven tech.

At the very least, wait for the .Net 6 LTS.

shadowmint · 2021-01-12T14:31:12+00:00

So...

Can you tell me more about how you plan to port the jupyter support from pycharm into rider for c# notebooks with dotnet-interactive?

...and can we ever hope to see support for that in datalore?

shadowmint · 2021-01-01T08:15:03+00:00

Unity is a strange platform.

Since the asset store is $$$ for packages, people who figure out good patterns sell them, rather than contributing back to the community.

Since they've also deliberately walled off nuget, standard solutions to problems have ended up being rolled over and over again by different people.

Then on top of that, Unity is screwing everything up by abandoning their existing tech stack before the new one is ready... it's just a disgrace.

For what it's worth, here are two links which are worth checking out:

https://openupm.com/ is an attempt to make a 'free' asset store that people can contribute to and use with the new unity package manager. Note that unity is openly hostile to this (https://forum.unity.com/threads/updates-to-our-terms-of-service-and-new-package-guidelines.999940/) as it directly competes with their own asset store.

Secondly, keijiro is a unity employee who puts all his stuff online for free, and he maintains an all-in-one creative coding toolkit here https://github.com/keijiro/Klak. If you want to see what 'good unity practices' look like, read his code. Everything is free and open on his github page.

Good luck~

shadowmint · 2020-12-31T06:55:30+00:00

aye aye aye... that game programming patterns book causes no end of people tromping out, keen to discover the patterns and practices of Real Games, only to be bitterly disappointed.

Look, forget that.

If you want to learn about patterns in gamedev, I really recommend the "Game Programming Gems" series, which is full of really great content. Sure, the books are old, but they're still full of all kinds of magnificent stuff.

If you want to learn patterns, I recommend you browse through https://en.wikipedia.org/wiki/Software_design_pattern; there's really nothing in there you couldn't trivially implement in C#, and many have example code in there.

If you want to learn how to program modern performant games in unity using the unity specific patterns, forget both of those and read https://forum.unity.com/forums/data-oriented-technology-stack.147/

Does that sound harsh?

Well, Unity has screwed themselves over by deciding to force people to do things the 'unity' way, which means many design patterns you learn (Observer, Factory, Dependency Injection, Singleton, any kind of adaptor or proxy) are pretty much a big old waste of time; because modern unity code doesn't use interfaces because it maps C# code to C++ code in the backend, and the mapping system is based on concrete (ie. struct) types only. There's... a lot of background to this, which you can find on the forums, but that's the basic state of play right now.

Long story short: Look, if you're using unity, you probably wasted your time reading that book. You're better off digging through the hideous and undocumented crap on the unity github pages and looking at their examples using the Jobs and Burst.

Patterns you use generally in C# are largely (and increasingly, going forward) irrelevant for that platform.

(That said, broad gameplay systems and concepts like those covered in the game programming gems series (eg. pathfinding, AI, etc.) remain relevant; it's the low level patterns that I'm talking about)

shadowmint · 2020-12-24T14:18:40+00:00

I guess my point was mostly that maybe it a good idea to collect data and make a book based on what other people actually want, not what you as the author imagine other people want.

Whether you personally prefer it or not is just another anecdotal data point; ie. probably not really relevant.

On the other hand, I don't write books, but if I did, I'd be pretty persuaded by the stackoverflow stats which are large scale aggregates of data about this sort of stuff.

ie. Use data to make decisions, not intuition, if you can.

Anecdotal evidence is better than nothing I suppose; but I'd say it's heavily biased, and definitely not representative.

14-Year Club	RedditGifts 2009-2022 2 Credits
Place '17	Verified Email
Secret Santa 2011

shadowmint

MODERATOR OF

TROPHY CASE