Jump to content

  • Log In with Google      Sign In   
  • Create Account


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

#5311208 should i have both epic AND mundane quests?

Posted by on 17 September 2016 - 08:30 AM

To create an interesting experience you need variety in that experience.


Epicness is relative to the expectations of the player. If all your quests are epic, none are.


As mentioned, the focus needs to be on quality of quests.

How epic they feel, is just a knob to increase the perceived quality of experience without actually changing the complexity of the content (youre just using bigger numbers and words and so on).


So you can slowly increase the epicness factor, but occasionally you need to recalibrate the players expectations so it doesnt get too crazy. I would accompany this recalibration with particularly interesting content (because obviously going from "epic" to "mundane" is not very fun, so you need to compensate). Like maybe you complete the epic quest and go back to boring life. But from that quest you got some interesting items or skills or knowledge, that keeps you interested enough to tolerate the lowered amount of stimulation for a while (epicness is just one factor of quality of experience, so you are simply switching from relying on rising epicness as a source of quality, to some other factor like new content - overall quality of experience should thus stay constant).


Consider the storytellers of rimworld. They determine how events that happen to you in the game are 'scheduled'. Rising challenge (~epicness), steady, or random.

The existence of options here means that players have different preferences. So maybe you can add an explicit option, or allow players to affect this through gameplay choices.

Maybe some players choose to go on a journey of increasing epicness, while others occasionally go on an epic quest and then return to normal life. And others get themselves in a situation where epic quests are forced on them without much control.

#5303157 How To Create Skins That Look Good For Brightly Colored Objects?

Posted by on 30 July 2016 - 03:22 AM

Avoid using small rectangles, or overall repetitive patterns, within the objects. Doing so interferes with players ability to parse the ACTUAL boxes (which are rectangular and repetitive).

Use something like the curvy shapes of SotLs design. I find those greatly improve my ability to filter/focus on a specific box type, as the pattern is unique (brain doesnt confuse it with the boxes themselves)

#5302463 How To Search A Quadnode Fast?

Posted by on 25 July 2016 - 05:29 AM

If you get the integer position of the node in tree-space, subsequent bits (1 for each axis, 2 total for quadtree) will index into the correct child node (as if it was 2x2 array).

So on nth level, read nth bit of position on each axis (first bit is most significant bit - make sure the zero pos is in middle of integer range like with signed ints)

#5294906 How does Runge-Kutta 4 work in games

Posted by on 04 June 2016 - 12:46 AM



One problem is that I don't understand C++. I don't know how to read it. It's way too different from Python. It's construction is complex. I don't know what's struct, void. Is struct something similar to class in Pyhon and void something similar to def in Python? Also, can you shortly explain what type of changes you made to code? What they actually do? Thank you!


void is basically just a placeholder, when you dont want a function to return anything, for example ("the type of nothing").

struct/class (which are basically the same thing apart from minor syntax differences) describe what variables/properties and methods each object/instance of that class/type shall have.


Ignore the :: in front of names. Its just referring to a global function or such (ctrl+f it).

In parameter list of a function, "&" means the parameter is by reference (if you modify the parameter, the original object that was passed by the caller, is also modified). "const" in the same context means you arent allowed to modify it (in that case, just ignore the & - we only read from the passed in data, not write)


"operator blah" is basically the function name, except its defining an operator ("a + b", where "+" is the function).

The stuff before the function name is the type it returns.

If a function has no body ({ *stuff* }) after the name/params, its a declaration and the body will be defined later in the code.

"this->" means we are accessing member variable of the class instance the method is acting on. Likewise, "return *this" is returning the class instance.


The comments should help understand it. Just start reading through it, you will begin to understand from context once the big picture starts to form in your head. Google the rest.

#5293561 Do you usually prefix your classes with the letter 'C' or something e...

Posted by on 26 May 2016 - 06:18 AM

I use PascalCase for classes and camelCase for methods/functions/variables (with "m" prefix for member vars - not "m_"). Because variables and functions wont really be confused (because of the calling syntax), this works pretty well.


I only prefix member vars because intellisense then easily tells me my options when I press 'm', and I dont have to constantly get confused when the logical name of a parameters happens to match that of a member variable.

#5291709 Most important principles of game design?

Posted by 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 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)



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 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 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 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 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 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 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 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




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:



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 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)