I don't think XP is fundamentally broken, it's a great system for drip-feeding new stuff, but I agree it's often implemented in such a way that striving for that new stuff isn't much fun. I think it's just intrinsically hard to get right. XP is a complex game-spanning system, so just about any exploit or imbalance in the game becomes an XP exploit/imbalance.

I think the simplest way to address grinding in systems with endless sources of XP is to make XP more abstract, not less. Rebalance XP income so that most XP in normal play comes not from performing routine actions but from completing larger one-off tasks: quests, challenges, achievements, etc. The optimal path for levelling up will then involve seeing and doing as much stuff in the game as possible.

The games that do best in Early Access seem to be those people can revisit hundreds of times as small updates come out over the months and years until launch; games that are worth replaying a dozen times or more as they improve.

I don't think a conventional single-player campaign or anything story-driven is something suited to being replayed as small updates appear. I know I tend to only play campaigns once or twice, however strong, and if there's something like that on Early Access I'd rather wait until the game's finished to play it. I'd advise starting with the multiplayer and building an active community with regular updates, if possible, or otherwise dropping Early Access entirely.

Generally, the game gets more difficult the further you get. This means that rooms further in will be more difficult, and you're better off doubling back to the earlier room to level up/find items first. The safest way to play, then, is to always double back and explore every single room before moving on.

Fully exploring every little corner can be pretty dull, so there's usually some hard-edged mechanic which limits exploration and forces the player onward to provide tension. Food clocks (ie. starvation) are common in traditional roguelikes; Spelunky has the ghost; FTL has the rebel fleet. Optimal play therefore involves exploring as widely as possible without suffering the consequences of this limiting mechanic.

With this kind of tension between the marginal benefits of exploration and an urgent need to progress before bad things happen, even decisions about which of two equally difficult areas to explore first become meaningful. Players end up learning the typical generated level layouts and exploiting common patterns to explore as much as possible without doubling back.

Haha, I am so familiar with this feeling and it drives me crazy. You're not alone. I mean, how often do we play the same game for a year? It doesn't matter how good a game is, it's gonna wear out its welcome...

The main thing I do is try and keep my exposure to the game fresh. While my game's not changing much and I'm just working through long established to-do lists, I try and "play" it as little as possible. Muting music, adding cheat/debug shortcuts to skip stuff etc is all good - in these periods I basically just do the bare minimum to test stuff, because I already know it's good and playing it just gives me new ideas I don't have time for.

And yeah, when it comes to playtesting, getting other people to play is golden. I find it hard to feel like I've seen something a thousand times over when I'm watching someone else play and discover it for the first time ever, and they can definitely help confirm whether something's fun or not.

Fixing the speed limit: you could bump up your speed limit as the ship approaches gravitational bodies to compensate for the extra speed. I got curious and worked out exactly how much speed you'd need to compensate for. I hope you find it useful.


We can work out the appropriate speed limit for any given point by working out the escape energies involved. The amount of kinetic energy you get from falling towards something down to a given altitude is well understood for regular gravity and, with a few bodges, we can work it out for your model of gravity too.

(This calculation is complicated by the fact that, under your model of gravity, it's impossible to ever truly escape a body's gravitional field; the field will always pull you back in, eventually. So we'll just hack it and look for energies high enough to get far enough away that we don't care any more.)

Here's the solution (ignoring mass, since it cancels out):

• Let g be the gravitational body's gravity
• Let h be the ship's distance from the centre of the gravitational body
• Let d be a constant, large distance; far enough that you don't think the gravitational body should be affecting the ship any more.

Escape energy from this altitude = g*ln(d/h)

(For h > d this calculation will error, so in this case just assume escape energy = 0 instead of working it out.)

Once we have the escape energies for each gravitational body we can add them up and combine the total with the general speed limit to find a speed limit that's right for ships falling through this point in space:

• Let e be the sum of the escape energies from this point for each gravitational body

Local speed limit = sqrt( 2*( e + 0.5*pow(general speed limit,2) ) )

So there you go! Each frame, for each ship, calculate the kinetic energy needed to escape from each gravitational body. Add those escape energies together. Combine this total with your general speed limit for that ship as above to find its speed limit for this frame. Maybe muck around with compensating for the extra speed in your drag formula.

That all ought to fix the speed limit near planets fairly precisely, if you'd like to take this approach.


Slingshot effect: well, how about multiplying the ship's speed by slightly more than one every frame whenever it's close to a big object? Say, work out a "boost" factor for each sun/planet:

boost = g/(h*h)

Then add all of the boosts for the ship together, and multiply them in like this:

speed *= 1 + 0.001*(total boosts) * dt

Sure, this is a total hack and I don't know if it's what you're after. What it'll do is make the zones close to gravitational bodies boost ship forwards along their direction of travel, pushing them to spin outward at a higher speed than they came in. You'll probably need to add or remove zeroes from that "0.001" until it has a sensible/noticeable effect, I have no idea what your units are. :D

I think you have a balance problem. This new feature, the one-time skill... well, you've clearly nerfed it so much that people aren't even factoring it into their strategy. Whatever you do I think you definitely need to make these powers usable more often and perhaps make the game harder to compensate. This'll also help differentiate the classes and make it more replayable. It's cooler if they're using their unique powers as much as possible, right?

I think once per level would be a good minimum. That means players only have to consider the stuff they can see to figure out the cost/benefit of spending their skill.

The Rogue and Amazon powers: if these rely on pressing the button to use, I'd suggest working them into the movement UI instead - so you always get the extra tiles marked as movement options in a different colour (when the skill's available).

For what it's worth, I've noticed people don't tend to think about low-utility options (like one time skills/items) until they have the really important stuff (like movement) completely figured out and can spare the mental capacity. If new players are ignoring side features, part of that may just be your core gameplay being complex enough to take up their full attention.

[The question]

The question
How should I add meaningful death in a permadeath game so that the player is still motivated to continue?

I approach this by treating death as the payoff for the work up to that point - linking rewards and recognition to death itself, so that player death becomes the realisation of everything achieved in life & feeds forward into other systems. It does suck for players so IMO it's worth reassuring them it wasn't wasted time by recording data and giving them something. eg:

- Leaderboards.
- Achievements.
- Class unlocks.
- Some permanent record of that character's story (or ongoing legacy).

Simply recording as much as possible about that character and honouring them can help prevent it feeling like all the time invested in them just disappeared, I think.

(Given that it's online: can you will property to other players, or otherwise make the player's death benefit their friends and allies? Can players build cemeteries in their villages?)

And then there's just giving them something to move onto. If the early game is exciting and varied and responds well to many different early builds/strategies, if players have to specialise so there's no possible way to see everything in a single life, if the game's biased towards skill enough that new characters can contribute/compete, then players may already be thinking about what they can do differently next time and all you'll need to do is nudge them into getting started.

Oh, one more thing. I don't think permadeath should ever be done without respect for "drama". When you die, I believe you should be able to see it coming and it should happen as this gathering crescendo of "oh shit!" moments where you're obviously getting closer to death and the stakes are going up; you should never ever be able to die suddenly from full health etc. or in a completely unexpected or unavoidable way. If death feels fair and narratively satisfying I think that's half the battle.

A single unfair/sudden death, even if it's just because the player didn't realise something or forgot it, might make them walk away from the game forever.

Three lives sounds like a great move in this direction, but I'd still worry that people who have been on one life for a while might start to feel complacent, and then permanent death might come as a nasty surprise to them. And I hope you're super clear to people what might happen once they reach their last life. :D

Hey.

1) This thread ought to give you some ideas.

2) Assuming your tiles are snapped to a grid, put them in a 2D array such that their position in the array corresponds to their position in the world. The character's X/Y location at any given time will then map to a certain position in that array. You'll be able to test the character against just the tiles immediately around them.

If you present your sexual characteristics as a central part of your appearance, yeah, people are likely to think you're interested in and motivated by sex. (Though plenty of men tend to assume women are anyway.)

Sexy fanservice is about objectifying and conveying submissiveness, weakness, vulnerability and a primary interest in sex: it says to the viewer "you could own me". When it's a game protagonist it goes even further - it turns the protagonist into an object whose every move you control rather than an avatar you inhabit.

If you want to create a respectable fanservice character you're basically saying you want the viewer to look up to them and look down on them at the same time. Lay on both thickly and you just end up with an unbelievable character, like a 17-year old army general and expert sniper with her arse hanging out who cleans guns and works out in her spare time and doesn't understand the concept of personal space.

A few things which seem to cover both attractiveness and respectability are making characters smart (ie. witty) and capable.

Video compression can cause ghosting, as can monitors with long response times.

Can you up an uncompressed screenshot which shows the problem?

Here's what I'd do...

Build an A* graph from your level of nodes with different types; floor, wall, ceiling, air, etc. You mention different widths and heights, so you'd want to add minimum and maximum width and height to the nodes, so that for example a narrow gap in the floor can be represented by two "air" nodes for a narrow enemy and by a continuous "floor" node over the top for a wide enemy (both connected into the floor nodes on either side).

Then add connections for special manoeuvres: jump, double-jump, drop-off-edge, drop-from-wall, drop-from-ceiling, etc. You can either go through and add these manually or set up some process to automatically generate them, say by looking for start-end node pairs with defined arrangements which have sufficient patterns of clear nodes between them. eg. found a floor node with a clear drop down one side to another floor node? Add a drop-off-edge connection between the two floor nodes which enemies can use to drop down.

Now, when pathfinding, you ignore all nodes and connections which the enemy doesn't qualify for (eg. ignore wall nodes unless the enemy can climb walls, ignore floor nodes with a low maximum height unless the enemy is short, ignore double jump nodes unless the enemy has that power). You now have pathfinding.

For ceiling climbing enemies, you probably want specialised behaviours which seek ceilings through a specialised heuristic that penalises non-ceiling tiles in the vicinity of the player, forcing them to approach via ceilings if possible.

If enemies can fly but only for a limited time, you can represent that in A* by only allowing them to pathfind through the air up to a limited distance and penalising being in the air in the heuristic; then they'll only fly if necessary.

Something you may not know about A*, you can use it to pathfind away from a point just as you can use it to pathfind towards one. Calculate your heuristic based on a constant minus distance from target, rather than positive distance from target, and it will seek a path away from it. You can mess with the heuristic in similar ways to pathfind clockwise/anti-clockwise around a target, etc, without needing to have any specific goal in mind.

Sexy characters are artificial constructs, pandering to a niche audience, made by people within that niche audience doing what feels good and natural to them.

Reading, learning and thinking can absolutely lead to stronger characters. Not just characters with broader appeal but characters with more definition and individuality, too. See, there's nothing magically special about cultural naivety - it likely just means you'll retread ground others have trodden before you. You have to recognise clichés to move past them.

Been working on this lately myself. Cardinal Quest 2's more about customisation than defined characters, so has male and female characters for each class:



Sure, they're 16x16 sprites, but there's still plenty of room to express character, physique, outfit, etc. The main rule I was going by was: what makes sense from the perspective and culture of the character? How do they need to dress to do what they do, how do they as a person want to dress and how do those two things interact? The character has to come first. Gender is important only to the extent they want it to be important.

I've ended up with two classes strongly gender differentiated, two classes where the genders primarily differ in physique but wear roughly the same outfits and two classes who carefully avoid gender signifiers, each for their own reasons. Still trying out ideas at the moment but it feels good to me so far.

Also, The Boss is one of the best game characters of all time, male or female.

With Box2D way it is easier to optimize checks with tree data structures (like QuadTree), whereas with 1) approach it might be more harder and performance consuming.

There's your answer. This stuff is absolutely necessary to get sensible performance if you have any significant number of objects. Given that requirement it's way better to do broad phase collision detection just once, for all objects of all kinds. You really don't want to be updating multiple spatial data structures for every pair of object types or rebuilding them each frame. Basic RTTI checks/virtual function calls when collisions are detected are much cheaper by comparison.

[NPC]

I like this... you're essentially talking about using game systems to provide a narrative metaphor for disability which lets you explore it without people's preconceptions clouding the issue, right?

agersant's point about diegesis seems relevant. If a character couldn't level up or their HP and MP bars are swapped, would them being aware of it feel plausible? What could you get away with that gives you a sufficiently consistent, relate-able world in which to tell a good story?

In a city populated entirely by heroes, a child like no other is born - with no class or level - an NPC...

It could definitely work. Check out the "Rebuild" series; it's the essential concept you're describing (managing and expanding camp, rescuing survivors, etc) just without the 3rd person stuff or multiplayer.

Can you make it, though? It's practically Day-Z plus Minecraft plus Rebuild. And each of those individually was a long project by experienced devs.

Two things:

1. You're tracing lines from x0/y0 towards the player rather than vice versa. That's why nothing is getting obscured by anything.
2. Your line tracing algorithm is quite, quite mad. It traces vertically until error > 0 and then traces horizontally without writing to rays[][] until it runs out of steps. That's why you're getting a cone below the player - it's only writing visibility at all when error <= 0.

I strongly recommend debugging and stepping through, step by step, checking the co-ordinates it's using against the screen to make sure that it does what you'd expect. Wherever it's going wrong, fix it. Repeat until it works.

[different reads]

Two things.

1. CPUs have caches and queues which insulate them from memory and from each other. The singleton may be allocated in memory which is still in some CPU's cache. It may take a little time for the new data to percolate through and replace the old data; it could arrive long after the new pointer value becomes visible, even though the other CPU wrote it first. The acquire fence will fix this by stalling until pending information from other CPUs has been assimilated.

Have a read of this if you really want to understand the hardware.

2. Have you tried looking at the assembly?

Code:

if (t) return *t;

on VS2010 here, with optimisations off (debug mode), generates

Code:

00AC13ED  cmp         dword ptr [t (0AC8138h)],0  
00AC13F4  je          GetSingletonImp+4Dh (0AC13FDh)  
00AC13F6  mov         eax,dword ptr [t (0AC8138h)]  
00AC13FB  jmp         GetSingletonImp+0BCh (0AC146Ch)  

In other words, the two uses of "t" are different reads - and the CPU could speculatively run the second before the first. Without the acquire fence after if (t) your code could return a null pointer, even though it has just checked that pointer. Optimisations should remove this double load - but you can't guarantee that, and even if you could you've still got a race condition when debugging.

Again, the acquire fence fixes this by strictly ordering the two loads.

Edit to add: admittedly, you could fix problem 2 by changing the code. The first problem is more critical.

Interesting. <atomic> is new to me, but here goes...

Mutexes do indeed acquire when locked and release when unlocked. As such, you don't need memory fences to synchronise code within the mutex to other code within the mutex. Your final statement is inside the mutex, so it's covered.

However, you do still need memory fences to synchronise the write within the mutex to the read outside it. This is what the memory fences do in both the VB/C# example you linked and the Meyers-Alexandrescu paper. The fact that one puts the acquire fence at the start of the procedure and one at the end is just down to differences in implementation. Regardless, you need to release before t is written within the mutex and acquire after it's read outside the mutex.

Finally... no, locking a mutex does not force local variables to reload. Tagging t as volatile would be one approach, and would work in Visual Studio 2005 and up at least. (It's not necessarily portable.) But since we're using <atomic>, why not just use std::atomic and load and store explicitly?

Code:

template <typename T> T& GetSingletonImp () {
 static std::atomic<T*> t;
 
 T* inst = t.load(std::memory_order_acquire);
 if ( inst ) return *inst;

 std::lock_guard<std::mutex> lock(singletonManager.GetMutex());
 inst = t.load(std::memory_order_relaxed);
 if ( !inst ) {
  T* tt = new T;
  singletonManager.Insert(t,SingletonManager::Delete<T>);
  t.store(tt, std::memory_order_release);
  inst = tt;
 }
 return *inst;
}

This isn't the fastest implementation - you could have less stuff inside the mutex, the relaxed read doesn't need to be atomic at all, and see the second code block here for an optimisation using thread_local - but I think it should be robust. Note the release fence to synchronise with the acquire fence outside the mutex. Atomic operations mean we don't have to worry about whether the memory fence goes before or after a load or store. The mutex itself handles all other synchronisation between stuff in the mutex.

A portfolio of prototypes suggests you don't finish stuff and have zero experience with the bulk of the game development process.

If you want to get hired as a designer, talk to some people who hire designers and fill your portfolio with whatever their junior designers do. It largely won't be prototypes.