Jump to content

  • Log In with Google      Sign In   
  • Create Account

Kylotan

Member Since 08 Mar 2000
Offline Last Active Feb 24 2016 12:27 PM

Posts I've Made

In Topic: Right way to handle people complaining about price?

24 February 2016 - 12:22 PM


But was this really the best way to handle this quite delicate question about perceived value?

 

Personally, I see 2 ways of handling the situation:

 

  1. Compare to similar games: Make a list of games similar to yours. List their prices. If your game falls inside the range, you have made the only point really needed for a customer. Of course only compare features... I wouldn't want to try to gauge quality.
  2. Ask the commenter for more details: see exactly WHY he thinks your game is not worth it. If you have the balls, keep it public. But I personally don't think it would be too much to ask for a private conversation. See why the commenter thinks your game is not worth the asking price. Ask him if he actually bought and played it. If yes, he might have valuable input about your games quality and faults. If not, he might have valuable input about your games marketing and storefront.

 

I would first go with option 2.

 

Personally I don't think it's a delicate question at all. There are 2 aspects here:

  1. People on the internet are seeing prices for entertainment forced down everywhere as a result of various forces - with games we have piracy, emulators, old games being re-released, bundles, mobile competitors, and increased supply generally.
  2. People now have the ability to comment and debate pricing, in the light of the above - and this adds a further downward pressure.

The first combination of problems, we can't do much about - but it will help if developers resist the urge to 'race to the bottom' and underprice everything.

 

The second problem reflects a fact that always existed - i.e. some group of people X think that product Y is not worth the price - but now they get to voice it out loud. Developers talking about the costs they incurred during development, and the relative value of other products available at a similar price, might sway some opinions here, reminding them that when product prices can't recoup product costs, they cease to be viable.

 

Asking for individual feedback seems pointless to me. Yes, data from users is fine. But individual bits of anecdata from cheapskates is rarely going to be worth much. A developer is rarely short of ideas or feedback on how their game could be better, and there are better sources to obtain it from.


In Topic: Best way to store NPC definitions

13 October 2015 - 10:49 AM

The ScriptableObject method will work, if you just want a serialisable lump of data that you can tweak in the editor. That makes it easy to edit simple values, but you still need to write the tooling for more complex edits. (Admittedly easier inside Unity than outside, usually.) I just find that I don't always want my data so tightly joined to Unity and in a form that can't be opened by a text editor or other tool.


In Topic: Best way to store NPC definitions

04 October 2015 - 09:57 AM

No, Unity doesn't really offer much when it comes to data storage. I would argue that you want to keep it in some sort of external format such as XML so that you can make quick changes outside of the editor. But if you really wanted to keep it in the editor, this data could just be public variables on any sort of GameObject, which you'd edit in the inspector like any other. But there are many downsides - renaming fields may destroy the data, the data has to be in a type that C# can serialise (or you write a custom serialiser for it), adding and removing entries in a list is awkward, etc.

 

But, if you really want to be 'artist friendly' then sure, you could insist on having this stuff in the editor. You might want to write some custom inspectors or editor extensions to make it easy. As long as the end result is changing values on game objects that are in the scene, that's much the same as storing it in an external data file.


In Topic: MMOs and modern scaling techniques

16 June 2014 - 02:35 PM


As you said, character/character interaction is N-squared; connections (and web architecture) is all built around scaling out the N problem. No real-time physics simulation engine exists that scales out across machines along the axis of the number of cross-interacting entities, although they exist (expensively, see DIS) for making each separate actor extremely complex.

If your needs match those of Farmville, an EC2 based web solution is great.

 

Right, but I think you're suggesting that games fall into either "real-time physics simulation" or "Farmville", and my MMO experience is definitely more in the middle. For the most part, the only physics being simulated is a position and velocity for each character, and there can be significant lag or even jitter in those cases without any downside to gameplay as there are no aiming mechanics or similar. With that holding true, and movement being fairly easy to progressively degrade (eg. just by sending less frequent updates), the performance constraints are significantly reduced.

 

The main problem I would then face, with a system that doesn't need strong guarantees on physics, is that I don't see any easy way of decomposing functionality across multiple servers without the usual proxy or ghost entities to stand in for multi-entity actions. Changing every action into a 3 or 4 stage state machine working with async messages is unwieldy, especially if you need to lock each actor while a state machine is in an intermediate state. And implementing some sort of attack bonus that is conditional on the current state of an actor on another process... possibly not practical at all.


In Topic: MMOs and modern scaling techniques

12 June 2014 - 04:33 PM

I wouldn't put so much trust on "how web developers approach scalability".


I appreciate that a lot of what used to be considered the state-of-the-art is now not considered best practice. But still, there are sites today deploying technology that services many more concurrent clients than single-shard MMOs can manage. The question is whether it would be possible for MMOs to do the same... or not. From what people are saying, the answer appears to be "Yes, of course... if you can overcome the complexity... which nobody is going to talk about in any detail". ;)

 

But still the problem remains that we have one socket per TCP connection and that sucks hard.

That's not really the problem I am trying to discuss though. Firstly, because you can distribute the front end servers quite easily. And secondly, because you don't necessarily need to use TCP for your main client connection anyway.

My experience of MMOs is that once you've done your optimisation on the I/O level - eg. getting your buffers the right size, perhaps using a proxy so that your game server is not spending half its time servicing network interrupts, etc - you'll hit a CPU cap with the gameplay before you hit a cap imposed by networking delays between the server and the player clients. Character interactions are O(N2) whereas your number of connections is only O(N), and the value of N is greater for character interactions because it includes NPCs. The cap in my experience seems to be around 500-1500 players per process, depending on how complex the computations for each player are.

 

Sure, at a very high level with distributed servers like Amazon EC2, these paradigms work. But beware that a user waiting 5 second for the search results of their long-lost friend on Facebook is acceptable(*). A game with a 5 second lag for casting a spell is not.


Sure. That's the backbone of my suspicion. The argument I had which inspired me to start this thread included the other guy saying that my traditional approach is quite obviously not widely used because it would cost half a million dollars per month on Amazon EC2. Trying to tell him that most MMOs - in the original meaning of the word - do not and will not run on EC2, would probably have been futile.


PARTNERS