Jump to content

  • Log In with Google      Sign In   
  • Create Account

Servant of the Lord

Member Since 24 Sep 2005
Offline Last Active Yesterday, 09:16 PM

#5206792 Why is this taboo?

Posted by Servant of the Lord on Yesterday, 06:00 PM

Players complain alot. Anything they don't like, or think they won't like, or once heard someone else say that they might not like, they'll complain about.

 

Good game designs sometimes include things that players won't like. "If I touch a goomba, I die? That's LAME!"

But hey, Mario is very fun. And successful.

 

Also, it could just be a vocal minority. One game designer gave the analogy of standing in an empty room, with all the players on the other side of a wall. The game designer hears complaints about this and that, but whenever he looks into the other room, what he actually sees is some players complaining, and everyone else silently and happily playing. If you listen to the complaints from the 10% of your players complaining, you need to also make sure you listen to the lack of complaints from the 90% who don't have a problem with it.

 

I'd say, use your intelligence as a designer to think it through. "Do I think it'll actually benefit the game?", then implement it, test it, tweak it, have someone else test it, polish it and release it. If the community complains, let them! Wait two weeks. See how it has actually affected the community and actually changed the gameplay.

 

Don't let the community dictate your designs, or you'll get design-by-committee, which ain't good. Your game needs a cohesive design, not a piecemeal design catering to a hundred different people's personal whims and wishlists. If new players come to the game with the feature already inplace, and they hate it, then give a bit more weight to the complaints.

 

Another designer once said, "Ask players what they want, and they'll give you a laundry list of last year's popular features.". As a designer, you need to know where you are taking your game, and be willing to make decisions that might not be popular, to create a game that is cohesive, polished, and meets your design goals.




#5206644 Trying to create a spash screen (with minimal art skills).

Posted by Servant of the Lord on 25 January 2015 - 10:23 PM

You have two O's in the name, you might try some loops with those... but you don't want it to look like an infinite sign either.

I don't get what that palm tree is doing there.

 

Your font is rather bland - you might consider a more loopy font, and maybe even be making the player-controlled cursor thing be making the loops that spell the name.

 

The clouds are all the same size, I'd vary them slightly, but I'd keep the same number. Three is a good number. They steal too much attention though - they ought to be more subdued.

 

And add some color - maybe in the font name.




#5206634 alpha question

Posted by Servant of the Lord on 25 January 2015 - 06:55 PM

I have tried sending a -= delta_time for that from the main application, but it seems that no matter how large a value i give it it always decreased too quickly, like a -= delta_time * 0.00001f. a is 1.0f.

 
You'll need to adjust your equations from your main application.
 
When you want the effect to start, set 'a' to 1.0f.

a = 1.0f;

Every tick, you do:

a -= (deltaTime / DurationOfEffectInSeconds); //'DurationOfEffectInSeconds' is a constant-like variable.
if(a < 0.0f) a = 0.0f;

This uses math to get the exact result you want.
If you want it to last five seconds, set 'DurationOfEffectInSeconds' to 5.0f. If you want it to last half a second, set it to '0.5f'.
 
Another way to do it is by having a timer and subtracting time from it. You then calculate the alpha by how much time is remaining.
 
When the effect begins, you do:

fadeTimeRemaining = DurationOfEffectInSeconds;

 
Every tick, you do:

fadeTimeRemaining -= deltaTime;
if(fadeTimeRemaining < 0.0f) fadeTimeRemaining = 0.0f;

 
To calculate the alpha you do:

float alpha = (fadeTimeRemaining / DurationOfEffectInSeconds);

 
And then you pass that to your shader.




#5206631 pathfinding on a 2d map

Posted by Servant of the Lord on 25 January 2015 - 06:20 PM

A* star works very well with or without uniform grids, and there is a huge amount of tutorials available online for it.

It's pronounced, and sometimes written, A-star, which can also be googled for.

 

Pathfinding in general is slow, so you'll still want to save the path and only recalculate it when necessary. It's faster than flood-filling though - and kinda similar. It flood-fills but intelligently, hypothesizing what directions are best, saving work.




#5206452 c++ how to detect Enter button input

Posted by Servant of the Lord on 24 January 2015 - 02:17 PM

i mean keyboard button and im just using plain c++

 

There is no "plain" C++. You're always using something. In this case, you are outputting text to a text console that Microsoft Windows creates for you.

Using the standard C++ library, you can't get keyboard presses or mouse movement. However, you can use Window-specific functions from Window's APIs to get keypresses.

 

But it'd probably be better to continue to try to get SFML to work.




#5206416 My 3D textures

Posted by Servant of the Lord on 24 January 2015 - 11:53 AM

post-227031-0-24311400-1422120705.jpg

 

Wow, that's really impressive. I mistook that for a photograph.




#5206305 Designing an Ore Mining Game

Posted by Servant of the Lord on 23 January 2015 - 07:16 PM

I love games like Terraria and Motherload, where players have to dig down and find more and more advance ores. The goal in both games is to dig all the way down, get the best items using the best ores, and beat an end boss.

 

For me, Motherload wasn't about reaching a certain location, or acquiring better items. Rather, it was about surviving in a dangerous while accumulating wealth, and constantly having to make decisions about risks vs rewards. My air tank is just about gone, I need to return to the surface, but there's two diamond ores right there. Do I have enough air to grab them? I can dig over to them, get them, and then beat it back to the surface... but then I have to execute my return trip perfectly, with much less leeway for mistakes if I take the wrong path or bump into a wall.

 

Motherload creates real risk, because death is final - you lose it all. And that risk, and that survival, is where the thrill (in that game) is for me.

 

What's the core strength of your game? Exploration? Survival? Plot? Combat? Collecting? Crafting items? Constructing/shaping the environment?

Just because a game has parts of all these doesn't automatically make it the "core" strength. What is the one (or two) "core" strengths you are wanting to focus on, that every other gameplay feature is supposed to enhance and support?

 

One thing I'm not too fond of is when games basically do "Sword+1","Sword+2","Sword+3". That gets tiresome after awhile. In limited amounts, that's fine - Motherload's better airtanks, thrusters, etc... weren't annoying, because there were only six or seven upgrades in each category, not two hundred. But I found the incremental "quality" of the ores slightly dumb. 
Copper -> Iron -> Silver -> Gold -> Diamond -> Plutonium -> Magiconium -> Incrementonioum -> Tediousonium -> Lackofcreativonium

 

Rather, I'd have liked to see every ore type still being valuable and used for different purposes, rather than just being incrementally more valuable. Different ores should still be rarer than others, but they should have different uses as far as gameplay goes.




#5206298 Constructor gotcha's?

Posted by Servant of the Lord on 23 January 2015 - 06:44 PM

i'm aware that statically declared objects are initialized in an order not under your direct control. other than that, are there any "gotcha!"s to look out for?  IE issues - things you don't want to do for some reason in a custom constructor or destructor?

 

I've had several of annoyances with static variables. Not just initialization order, but also weird issues when trying to use them across library boundaries (if you want to seperate your engine into a library).

Also, it's not just the initialization order of your classes, but also the initialization order of your classes relative to the APIs you might be using. As an example, accidentally loading assets prior to the OpenGL context being created, or trying to output an error message prior to your logger class being initialized. dry.png

 

To enforce an initialization order, you can put them all in a struct - for me, my 'GameStructure' class holds the asset pools and graphics engine and etc... 'GameStructure' being bare-bones owner (composition-wise) of everything except the globals (and I've been removing more and more of the globals, so there's only two or three left).

To enforce a specific initialization time, I explicitly construct the GameStructure after control is actually handed to my program.




#5205348 Starting at Max Level

Posted by Servant of the Lord on 19 January 2015 - 12:58 PM

Progression doesn't have to be power. Can be social, financial, score-ranking, military hierarchy, it can be the amount of the world explored and landmarks visited, it can be progression through huge arching questlines, it can be progression to increasingly cooler looking appearances that "testify" to your skill to other players, it can be access to exclusive gathering halls / drinking holes in the cities. It can sometimes even just be a pat-on-the-back gold-sticker, or a increasingly filled up collection of stamps/achievements, or some level of tiered titling ("Silver member", "Gold member"). Many players ignore the non-gameplay ones though.

 

More importantly, progression can also include new abilities, even combat abilities, as long as it doesn't give an extreme edge. You can look to the more modern Call of Duty games for design inspiration here (don't dismiss their design values out of hand for not being the same genre of game) - In Modern Warfare / BlackOps / Advanced Warfare, players "level up", unlock and choose to equip a large number of different equipment and attachments. Despite this, players with higher equipment don't have an advantage over players with lower level equipment. The different equipment is "unlocked" giving forms of progression, and chosen to be equipped and chosen what accessories giving forms of player customization. It is very incredibly impressively balanced. Everyone thinks their equipment setup (their "loadout") is the best, but everyone has a different loadout, creating a wide variety of different possibilities - and a wide variety of different challenges to overcome from your opponents.

 

While occasionally, players complain that WeaponX is overpowered ("Ugh noobtubers!"), but if this was actually true, alot more people would naturally use the more powerful loadouts. Instead, we see huge differences in loadouts. And even if one weapon is slightly unbalanced (hard to measure), out of 30 weapons and >500 variations, it's still a very impressive design feat.

 

Unlocked upgrades don't have to be better, they can just be different, and provide different styles of gameplay, without creating disadvantages in power. Infact, one might argue that the default WeaponB is 1 point of damage higher than WeaponA is actually the bare-bones lazy way to design equipment.

 

Players need to be challenged. Getting more powerful actually decreases challenge. Players need to unlock gameplay possibilities, not power.

At first, too many choices can be overwhelming. So you have to provide fewer choices to players early on, and introduce more choices gradually. This works hand-in-hand with progression - unlock new ways to play the game, unlock new tools that enable new tactics. Unlock new ways to overcome challenges, don't unlock power that makes the challenges less of a challenge.

 

You can also look to League of Legends (again, don't be dismissive because it's not the same genre). League of Legends currently has 123 different champions. While they do a slightly poorer job at keeping them balanced, they are still amazingly close in balance (and the imbalances only really are revealed at more skilled levels of play). The champions have different play styles coming from their different stats and abilities creating different ways to overcome challenges (and posing different challenges for players who are facing them).

While the champions have alot of overlap and similarities (it'd be hard not to, with over 100 different playable characters), overall there is alot of variation. Most fall into several different styles of play (or roles to fill), but even those styles have subtle variations within them. And players don't have to stick to the standard play styles anyway - but the champions' abilities enable different styles of play, different choices and open up different opportunities when the right circumstances come along.

 

Or take Halo for example. I haven't played any Halo game in years, but think back to Halo 1. You have a rocket launcher, a pistol, a battle rifle, a sniper rifle, shotgun, a few alien weapons, grenades (normal and sticky), etc...

Each weapon isn't necessarily more powerful than the others, though some were unbalanced at higher levels of play (like the pistol in Halo 1), they vary in strengths but their strengths are only fully beneficial in the right circumstances. Your (changeable) weapon compliments your (changing) environment to face changing enemies (other players, also with changing weapons) to create dynamic, interesting, and enjoyable challenges and experiences.

 

While both Halo and Modern Warfare are examples of weapons, I'm not trying to suggest you give players weapons. The exact same concept can be applied to skills/magic/abilities and even other gameplay mechanics. Unlock options, not power. Introduce new choices, don't decrease challenge.

 

Think about "Doom" for a second. Each gun you get varies mostly just by power. Mostly, the only reason why you'd use "weaker" guns is to conserve ammo for your "good" weapons. That's not how you want progression to work.

You ever play the original Thief, or Deus Ex? Those games weren't without gameplay ruining flaws either (Dragon Tooth sword anyone?), but what did they right were give tools to provide choices in how to approach challenges. Thief had: water arrows, noisemaker arrows, rope arrows, moss arrows, mines, as a very clear illustration.

Deus Ex had the "tools" hidden as abilities and weapons: depending how you progress your character, different ways of interacting with the environment (and with enemies) would become unlocked through your abilities, opening up more choices for the player to consider when overcoming the obstacles the game throws at them.

 

Just to be clear: I'm not talking about mechanics, genres, how your combat works or how you should make your gameplay. I'm talking about the common concept behind the examples above: They empower and unlock player choices, not merely boosting player stats.




#5205324 Starting at Max Level

Posted by Servant of the Lord on 19 January 2015 - 10:46 AM

Overall, starting more powerful and decreasing in power is a good way to make the game more difficult and more challenging as the game goes on.

 

However, here, you are not making the game more challenging for people that are succeeding at the game. Instead, you're making the game more challenging for people that are already losing at the game and making it more likely that they'll continue to lose, leading to a spiral of increasing challenge that they can't get out of until they rage-quit.

 

Challenge needs to increase for the players that are no longer challenged, to keep the game enjoyable; not the players that are losing.

 

Losing isn't always "I made a tactically wrong choice". Infact, more commonly, it's "I accidentally clicked the wrong button, I happened to be facing the wrong direction and didn't see the attack coming, I unawaredly walked into the wrong room and was stabbed in the back, I was coincidentally was up against more powerful and more numerous enemies..." So you're punishing players for events that are mostly out of their control.

 

In addition to all this, players do need to see positive progression even while the game gets more difficult. It's also nice to have tactical choices and customizations to make.

What about, for each winning player, he loses a piece of equipment of his choice. Maybe instead of getting rid of it, every piece of equipment starts at level 5, and each victory he chooses one piece to de-level one level. This provides increasing challenge for winning players, keeping the game enjoyable, and also provides tactical choices and customizations (i.e. which equipment do I want to preserve long-term?).

 

Players still need to see positive progression as well, even if it's non-combat related. This can include things like moving up a ranking chart - but with a large amount of players, moving from rank 10017 to only 10016 isn't enough motivation.




#5205129 So I think I'm fairly comfortable with C++ but..

Posted by Servant of the Lord on 18 January 2015 - 03:06 PM

SDL or SFML are excellent APIs to use. They have tutorials available online, good documentation, active communities, and so on.

 

I suggest making two or three very small projects first; things like pong, tetris, connect-four, asteroids, etc... to rapidly gain familiarity with the library you choose, as well as to begin to understand the basics of game architectures.




#5205092 Problem with SDL

Posted by Servant of the Lord on 18 January 2015 - 11:52 AM

Thanks guys, I meant to link to the post here where I explain the underscores, so I wouldn't have to re-type it out. Apparently I failed to add it my post. ph34r.png 
 
The version of the standard I have on my computer says:

"Certain sets of names and function signatures are always reserved to the implementation:
Each name that contains a double underscore__ or begins with an underscore followed by an uppercase letter is reserved to the implementation for any use.
Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace." - (17.6.4.3.2 in draft version N3376)

 

So:

  • Don't start any name with double underscores.
  • If it's in the global namespace, never start names (variable / class / function / macro names) with an underscore.
  • If it's in a class or function or elsewhere, you can start with a single underscore as long as you don't follow it with an uppercase letter.

These three rules can be simplified and generalized as, "don't start variable names (or class names) with underscores".
The OP is technically safe, but unless he knows why he is safe, he's basically walking on a rickety bridge without knowing it.
I had intended to link to the fuller explanation - but I must've accidentally deleted that when I deleted my griping about explicit void parameters. laugh.png
 
Even if you violate the actual rules, 99.99% of the time you won't encounter any problems. I used underscore prefixes with uppercase letters for a long time before I found out it wasn't allowed.
It's just that compilers can potentially generate extra hidden variables and macroes in your classes and functions to help implement or optimize the generated code. If the compiler does this, and if it happens that you accidentally used a variable name that they are trying to use, you can run into problems. Most likely, you'll just get funky compiler-time errors about conflicting variable names (while only being able to see one variable in your code), but even so it's important to be aware of the possibility, as unlikely as it is.
 

im not quite familiar with passing reference, can you show me the code on on both your suggestion? thanks


Are you familiar with pointers? Pointers and references are almost identical in concept.
If I do:

int myVariableA;
int myVariableB;

Both these variables are different variables, holding different data. They are independent of each other. Even if I name them the same, they aren't actually the same.

But you can create a "reference" variable. A reference variable is creating a dummy variable that actually modifies the variable it is refering to. If I do this:

int &myReference = myVariableA; //The '&' sign means it's a reference variable.

This makes 'myReference' point at and represent 'myVariableA'. It is a second way to access myVariableA's data.
Any time you modify 'myReference', you're actually modifying the variable that it is refering to (in this case, 'myVariableA').

When you read myReference's value, it actually reads from 'myVariableA'. References are not copies of the variable, they are another way to access the same variable. References don't hold their own data, they read and write the data of the variable they are referring to.

If it is a const reference, then it can only read, but not modify, the variable they refer to. You may want to learn more about const variables and const member-functions - but I don't want to pile on too much information at once, so below I'll use regular (non-const) references.

To solve your current issue, you don't want two different texture managers holding different textures and not sharing information. Instead, you want one texture manager, and you want to give other classes access to that one texture manager. In this case, we can give other classes references to the real texture manager, and they can access the one texture manager through their references to it.

So Game can have the real texture manager as a member. Player (and other classes) can then take a reference to it in their constructors, like this:

class Player
{
    Player(TextureManager &_textureManager); //We'll pass the variable into the constructor by reference also.
    
    //...etc....

    private:
    TextureManager &_textureManager; //The '&' sign means it's a reference variable, so we'll own a reference instead of a copy.
}

And the constructor's definition can look like this:

Player::Player(TextureManager &textureManager) 
	: _textureManager(textureManager) //Assign 'textureManager' parameter to the '_textureManager' member-variable.
{
    
}

I know that looks kinda funny, because we have to introduce another feature here: member-initializer lists.
It's a special way of writing code that only applies to class constructors, allowing you to initialize the class's member variables before the constructor runs. I only bring it up because references (unlike pointers) must always be initialized when they are created, and can't be initialized after creation.

Game's constructor can now pass in a reference to Game's TextureManager to Player, when Game constructs 'Player'.

Game::Game()
    : _player(_textureManager) //Pass _player our _textureManager, so _player can store a reference to it.
{
   //...etc...
}

Now anytime _player uses its TextureManager reference, it'll really be using the TextureManager that it is referring to (in this case, Game's TextureManager). Player isn't creating an independent TextureManager, it isn't creating a copy either. It is creating a second representation of the same variable data.

 

Even though you use pointers, if you don't yet understand them, pointers and references are basically different ways of doing the same thing. Pointers can be changed to point to different variables later, but once a reference is assigned you never can to reassign them. Pointers can also be null (pointing to nothing) but references must always point to something.

 

There's one other issue I need to mention... (dry.png) Because Player is storing a reference to Game's TextureManager, you have to be absolutely positive that Game's TextureManager is constructed before Player's reference to it (otherwise you'll be referencing something that doesn't yet exist!), and you have to be absolutely positive that Game's TextureManager isn't destroyed before Player's reference is destroyed (otherwise you'll be referencing something that has ceased to exist!).

 

In this case, since Game owns TextureManager and Player, it can control what order they get constructed in.

In C++, classes construct their member variables from top to bottom. So here:

class Game
{
public:
	//...etc...

private:
        //...etc...

	TextureManager _textureManager; //_textureManager gets constructed first.
	Player _player; //And then _player gets constructed.

        //...etc...
};

That's something you need to remember if you reorder your member variables. Because '_player' depends on '_textureManager', '_textureManager' must be higher up the class declaration than '_player' is.

 

That's alot of information to absorb at one time. tongue.png

 

I glossed over and simplified some rules (just like I simplify the underscore rule), but note that everywhere I say "must", "never", "always", then those are code-words that mean that there are times where it is valid to break the "rules" that I mentioned, as you learn more about how C++ actually works, and that the "rules" are merely safe guidelines for the 99% of normal usage.

 

In C++, "never" and "always" are mere suggestions. wink.png

There are always cornercases where you can step outside the rules, for good or bad.




#5205015 Problem with SDL

Posted by Servant of the Lord on 17 January 2015 - 10:39 PM

First minor issue: You shouldn't start your variable names with an underscore. Variable names starting with underscores are reserved for the compiler.

 

Your real issue: You have two separate TextureManagers. smile.png

 

If I create:

int MyIntA;
int MyIntB;

...then those are two separate integers. Even if I give them the same name, that doesn't make them the same instance

 

The TextureManager called Game::_textureManager is not the same as the TextureManager called Player::_textureManager. Even if you name them the same, that doesn't make them the same. 

 

What you need to do is make the Player's TextureManager be a reference to the real texturemanager. Either you can pass Player a reference to the real texturemanager using the Player class's constructor, or you can pass in the reference to the texturemanager into the draw() function, like you do with the SDL_Renderer.




#5204865 What are the possible ways of making a level editor?

Posted by Servant of the Lord on 16 January 2015 - 10:35 PM

Would it be possible to make an image and let the program interpret that from a file

I've done that before, but using MS Paint to make maps for my game was a very annoying process, as it was hard to remember what the different colors meant when I had more than five or six.

or should I make a level editor in game? Is there any other way to make a level editor?

You can use a pre-existing one from the internet (and figure out how to import that editor's map files), create your own polished GUI editor (which can take many months or even years which could otherwise be spent on your game), or you can embed simple editing features in your game directly.

Imagine hitting a button like F12 to go into "editing mode". Then use the mouse to place objects, right-click to remove objects, and use keyboard keys or the mouse wheel to switch the object that you are currently placing.


#5204660 30k concurrent players on a (private) MMO server...is this possible ?

Posted by Servant of the Lord on 16 January 2015 - 02:35 AM

My initial plan was to use a smallish ( 50X50 ? ) maps for each 16-32 people or so, but wondering if I can manage a unified map (500x500 ? 1000x1000?) with a good implementation.

 

I used to be part of a hobbyist team for a small ORPG where we had >10 people on a map at a time (maps being 21x21), all spamming text as fast as possible as part of minigames. I wasn't the programmer, but I'd guess the code wasn't very optimized as we had more pressing priorities. And the server was at times even running off of a weak laptop over WiFi on a home internet connection. ('course we lagged like crazy when the lead developer and host of the game would be streaming live football games at the same time as hosting the server laugh.png)

 

This was 9 years ago. With better and more modern hardware, and intentional and calculated optimizations, I wouldn't be surprised if you could get 50+ players in a single screen without lag.






PARTNERS