Jump to content

  • Log In with Google      Sign In   
  • Create Account

Waterlimon

Member Since 28 May 2011
Offline Last Active Yesterday, 02:58 PM

#5291709 Most important principles of game design?

Posted by Waterlimon on 15 May 2016 - 11:55 AM

Some general goals you want from a game design:

 

* Promotes itself (attractive in words/pics/videos, social aspects so players get their friends in, user-generated content so people post it all over the internets for free publicity, etc)

* Provokes emotions (Details depend on game. If you sell your game as "makes you frustrated and hate the game", thats fine, and people will like it as long as it does what it claims to do)

* Does this effectively (quality)

* Does this for a reasonably long time (the game must either contain, or generate, interesting experiences over time, so its worth peoples money and to keep the community active)

* Does this for a reasonably large audience (familiarity to make it approachable, novelty to make it interesting, choice of platform)

* Does this for a reasonably low effort to implement (you want the design to be efficient. This is one reason why emergence is good, as its about patterns that you didnt have to manually build into the game.)

 

All of those overlap, and you always must make tradeoffs. Overall in game design, everything is interdependent, which is why iteration and other such 'dumb optimization' approaches are necessary (you cannot plan it upfront, because understanding it fully is too difficult). Of course, dumb optimization is dumb, which is why we should seek to understand as much as possible, so we can plan (efficient) more than we test (inefficient) to get the same result.

 

Now, those general goals would be how you evaluate the design at high level.

 

To evaluate the design, you apply your knowledge of human psychology (often relying on the assumption that "what I like = what others" like at first), as well as knowledge of the technical fields (ease of implemention) for the goals not related to player. So you can play it yourself, or imagine whether youd like to play it (or a similar game, to understand what effect the differences between the designs might have). But you can also get feedback from other people, do some proper playtesting, etc.

 

But you need something to evaluate first. Maybe you add something to existing designs and evaluate the result. Maybe you synthesise something original in your head and evaluate that (possibly after making a prototype to be more empirical about it). Then you can apply 'design fragments' that you think might contribute to enjoyable gameplay, to build up the complexity of your design (so you have larger possibility space to work with when trying to locate a particularly good design), which have something to do with following aspects of gameplay:

* Control (do you move a character? interact with things by shooting at them? give orders? tweak numbers? build something? activate things at right time? aim? what parts of the world can the player directly or indirectly interact with?)

Structure (what primitive elements the game is built of, how theyre ordered. Structure is important for implementation efficiency, and player understanding. Pacing.)

* Physics (how do the elements interact, what rules they follow. How does the world change over time. How does it respond to player actions.)

* Valence (objectives, rewards, punishments, anything the player cares about, whether its formal like a 'points' system, or informal like having some cute animal people just care about)

* Communication (things that make the player learn, interpret, understand, feel)

 

And theres some common fragments, known good approaches, either because of momentum (its very easy to do what others do), or because player familiarity with those fragments (so theyre used BECAUSE theyre popular), for example:

-Being able to move a person (movement=control, what results from movement=physics, person=valence because people dont really care to act for inanimate objects)

-Getting points (valence, people like to get things)

-Click to shoot (control, physics for how the 'projectile' works)

-Zombie theme (valence, people care more about their survival when its against zombies, than against grey boxes, also communication, because people understand zombies are to be avoided)

-Map being divided into levels (structure)

-Having items you can pick up and do something with (structure, control, valence because players like to get things)

 

You find such fragments from everywhere, not just other games (any knowledge, pattern, system, behavior can be included in a game).

 

So, given a game, you could look at each aspect of gameplay separately, see what things affect that specific aspect, and then see how those things build toward the general goals of the design (to understand the design).

 

Going the other way, its a difficult problem. Its less like "finding the solution" and more like "finding any solution". So at first, a creative problem. Pick random things, see if you can think of a way to fit them together into something that works (Im not really going to think about 'how to be creative', doesnt really relate to games specifically).

Once you have found a starting point, you can get more systematic, start following rules/policies to extend your game following its structure and goals. Those rules/policies depend on what structure and goals you went with. For example, if you want every playable character to be equally good but also be different from other characters, thats a rule you can follow to produce extra characters.

Kind of like simulated annealing (at first relatively random sampling of possible solutions, then closer and closer examination/tweaking once you have a good general idea).

 

Any general rules will be directly related to the general goals (like adding nice coherent art/animation/effects because they create a more emotional experience, or introduce new things manually or through emergence at steady pace to keep the experience interesting over long time). There will also be more specific rules formed for any particular game or set of games/type of situations, that have been found to be relevant in the specific situation. You would think and explore those once you know the specific context (I guess a general rule would be to research what others did in a similar situation, whenever you have some design fragment you want to perfect, but thats just general design, not specific to games).

 

The general goals can be simplified as:

1. The game produces an experience that enough people want

2. The game does it efficiently and effectively enough




#5289229 Is Making The Player Read Lots of Text Unusual?

Posted by Waterlimon on 29 April 2016 - 07:33 AM

As far as I know, people like reading novels, so whatever you do, it cant be bad.

If its not conventional, at least your game will be more novel (hue hue).

 

So it just comes down to what is a better experience, and as you say, the plot would be better if you didnt force a particular way to show it.

 

(But do keep looking for existing examples for ideas on how to do it well)

 

edit:

Though make sure the gameplay doesnt motivate the player to ignore the text to find some single bit of information, or to skip it entirely. If the players own goals are to "beat the game", theyre not going to read through the story. So design it such that players are primarily interested in the story, or itll just get in the way.




#5286971 Stuck the ball in the board (pingpong game)

Posted by Waterlimon on 14 April 2016 - 11:13 PM

Make the paddle ignore the ball if its traveling away from it.

 

Currently the ball goes a bit inside it, its directions is reversed, its still inside it, so it gets reversed again (which prevents it from ever leaving the paddle)

 

 

To do this, ensure the direction the pad points, and the direction of ball velocity, point away from each other, before reversing ball direction (dot product is how you do this with vectors - but you can just use a simple conditional if you want to)




#5284769 Polymorphic uninvolved parenting?

Posted by Waterlimon on 02 April 2016 - 12:35 PM

Either use a Derived* instead of Base* where necessary (part of the code might deal with a specific derived class, while another part is more generic and only needs base pointer), move it into the base class/interface, or come up with a messy system to ask (through a Base*) what the actual derived type is, and then cast to Derived* and then call the function (if you find yourself needing to do that a lot, theres probably some bigger architectural problem).

 

For example, if both "draw" and "write" actually just draw the thing, they should both be called just that (and not separate names for no reason), and you can then put it in the base class.

 

In some cases, you might find that some base class things are not used by all the derived classes. This can be fine if it allows more flexibility in what kind of derived classes you can create. But remember that increased flexibility often comes with reduced maintainability/readability/performance (compare having 1 god-class that does all the things, and a bunch of specialized classes, or having everything be a global variable vs keeping things nicely local and scoped)




#5283516 tutorials

Posted by Waterlimon on 25 March 2016 - 09:24 PM

Make the UI intuitive (as in, dont make every button an obscure symbol with no tooltip), so, given an objective ("youre thirsty"), the player can easily click on some things and see some water-related stuff and hopefully figure it out.

 

Then you just need some such objectives (either explicit ones or implicit like that "youre thirsty" one) to motivate the player to explore their options.

 

Another thing you should do, is write some checks that activate when the player isnt doing something right (or looks like they have time to work with some advanced feature), and show a hint/mini-tutorial that introduces the concept and gives some advice on how to proceed. With option to never show again, of course (and option to override those decisions for a new game).

 

For example, if the code detects that the player is thirsty, you could show hint that lists possible sources of water (maybe even detect the best options nearby and list those).

 

It of course helps if the first game is in a scenario where everything is guaranteed to be somewhat easy (so the player doesnt have to go on a quest through your most complex features to get a drop of water...). Perhaps even throw in some 'cheats' like free resources to prevent failure when the player is still learning the basics (you could have it opt-out, so player can start playing 'for real' in the same world when they get the hang of it)




#5281252 Efficent Tagging

Posted by Waterlimon on 14 March 2016 - 02:58 PM

Yeah, avoid "stringly typed" code.

 

If your tags are stored as text, parse them into something more computer friendly (assign each unique string, an integer ID).

 

So now you have integers. Using those might already be good enough for you.

 

 

Since the tags are basically memberships in a set with a fixed number of possible sets, you might be able to compress them into a sequence of bits (to quickly do your checks using bitwise ops). std::bitset works if youre using c++ and can set an upper bound on possible tags at compile time (as the size is needed for the template). Or just use plain old integer if you dont have that many and like things simple.

 

You can also make tags that combine several 'fundamental' tags, to reduce the amount of tags you need per object. For a weapon, instead of tags [orc,human,dwarf,...] you might just use [hasHands]. (this will also make it more structured and maintainable, if you suddenly decide that some race has no hands, and no longer can use half of the 5000 weapon types you laboriously defined... good to have that automatically work)




#5281080 how could unlimited speed and ram simplify game code?

Posted by Waterlimon on 13 March 2016 - 01:19 PM


Is this true Waterlimon?

 

I wasnt referring to any particular language, but prolog did enter my mind while writing that (along with all those functional languages there are?)... Note that I dont know anything about prolog, except someone once said that it can solve stuff for you or something :I




#5281053 how could unlimited speed and ram simplify game code?

Posted by Waterlimon on 13 March 2016 - 11:33 AM

We would start writing more declarative code instead of imperative. We dont write how to get to the result, we write what properties a valid result shall have. Then the computer brute forces a perfect solution.

 

For example, when doing pathfinding, we would just say we need a solution in the form of a list of nodes, and the combined cost of the nodes shall be minimal, with first node being specified and every following node being adjacent to the previous one, and no node exist more than once in the list.

 

It would be more like math I guess.

 

 

Though maybe such a language already exists but nobody uses it because it allocates everything on the heap and has weird syntax.

 

 

Of course, we would just make a game that works exactly like our universe, and its so awesome that everyone plays just that, and then we build regular old slow computers inside that world and think how cool and challenging it is to deal with the limitated system resources...




#5281052 no good way to prevent these errors?

Posted by Waterlimon on 13 March 2016 - 11:23 AM

If the x,z things are (mathematical) vectors, I use a vector object instead of independent variables, so I would either do

A.something = B.something

A.mSomething = B.mSomething

 

or

 

for(int i=0;i<2;++i)

{

A[i] = B[i];

}

 

Both of which reduce chance for manual errors when doing repetitive stuff.

 

I guess if you have an y component and want to skip that, and its a common thing, you can write a special function for that:

A.setXZ(B)

 

So whenever I do anything related to vectors/matrices I use loops instead of manually handling every component. It also usually generalizes to any number of dimensions if I care about that.

 

 

For other things, if you cant make the type checker detect the errors, see if you can change your naming conventions to highlight them better. mX instead of mx might be more visible. Also consider adding comments that state what must be done, before actually writing the code. That will force you to think a bit more and also remind if you forget something while writing it out.

 

In the case of using current_location instead of new_location, perhaps you can limit the scope of variables even more (such as by using anonymous scope), so theres less potential wrong choices to make. Some people might also make variables useless by setting some garbage value just after the last use (like setting pointers to nullptr after delete).

 

Then theres tools like assertions and unit tests, which are also a bit like comments, except theyre actually checked. People really care about writing safe and correct code, you could even look into fields where its extra-critical and see what they do.




#5280061 is there an easier way to do this?

Posted by Waterlimon on 07 March 2016 - 02:28 PM

For the basic information that every object needs filled in, you could write a simple editor (if theres a ton of items) that asks the data in efficient way and writes it to all the places necessary.

 

Ensure the common case has a sensible default that allows you to skip providing the data (probably applies to everything there). Make it so, that when adding some entirely new functionality, you can skip all the common data (appearance, physical properties...) and focus on the functionality. So you dont need to finish/decide every aspect of the entire item before it even exists. That should make it less annoying to add new things. Fill in the details later.

 

See if theres any way you can add more templates/helpers to minimize amount of data/boilerplate you need to input. Try to bring all the information in a single place, in correct order (having to jump around multiple places adding stuff is slow). (this is what an editor would do - even if all the data was in code, you could have some text console editor insert the data and write the boilerplate for you)




#5277803 Manufacturing chain for paper

Posted by Waterlimon on 23 February 2016 - 05:12 PM

Toilet paper?




#5277008 New Studio Name, Thoughts?

Posted by Waterlimon on 19 February 2016 - 12:56 PM

 

 

Good Bishop Studios

 

Bad Bishop Studios

 

King's Bishop Studios

 

Queen's Bishop Studios

 

Indian Bishop Studios

 

Bishop Pair Studios

 

 

Pfft

 

C5XfN2C.png

 

I demand 75% revenue share




#5276017 Victory conditions for a 4X

Posted by Waterlimon on 16 February 2016 - 03:28 PM

It might feel better if you have to complete those achievements within limited time (it can be a long time, but still a clear limit)

 

Perhaps, you also need to survive until that limit, even after completing the necessary achievements.

 

So you have to do some time management as well. Maybe you can get all the achievements by going all in, but expend too much resources doing it and fall before the time limit. Or maybe you want to play it safe and leave a difficult achievement toward the end (eg build something big which requires selling most of your army), but something unexpected slows you down and you lose.




#5270205 none issue when near plane = 0.01, is it just matter of time when I see artif...

Posted by Waterlimon on 08 January 2016 - 09:19 PM

The value of near plane is irrelevant on its own - what matters is the relative magnitude of the near and far plane to each other.

 

Set far plane as low as you can without issues. Then near plane as high as you can without issues.

 

If theres no issues, everything is fine.

 

If there still is issues, you need to do something else in addition to simple depth testing to deal with the cases where it isnt working (like doing multiple passes for different depth ranges to increase precision withing each range, or depth biasing like you have).




#5268915 Fun Challenge: Implement Polymorphic Callback

Posted by Waterlimon on 02 January 2016 - 08:11 PM


You are relying on vendor specific behaviour.
Calling conventions are up to the compiler and platform. So calling the member function as a free function with an implicit this argument might fail.
 
But as long as it works...
It's the same trick that the FastDelegate library uses. Only it has compile switches for a dozen compilers or so.

 

I dont specify the calling convention (I never convert the member function pointer to something else and only call it knowing both the class type and member func ptr type)

 

AFAIK the only requirement is that the member function pointer is compile time constant (as its used as template argument to 'wrap' it into normal nonmember function). Shouldnt compile otherwise...

 

Im not sure if the above assumption is true for something like virtual methods (it COULD be?). But yeah I dont feel confident using it for anything else than regular member functions which I can assume are known at compile time (better be, for my performances sake)






PARTNERS