Jump to content

  • Log In with Google      Sign In   
  • Create Account

Servant of the Lord

Member Since 24 Sep 2005
Offline Last Active Yesterday, 11:38 PM

#5287087 My octagon is a circle and my pentagon is wonky :'(

Posted by Servant of the Lord on 15 April 2016 - 01:41 PM

Each cell of the console is not perfectly square. By default, on Win10, for example, my console cells are 8x16. They are twice as large as they are wide.


Also, the asterisk isn't centered properly in the cell, so try outputting a character like this.

#5286778 Where can I hire game writers and designers ?

Posted by Servant of the Lord on 13 April 2016 - 07:09 PM

And where can I find professional ones other than freelance websites ?

Professional literally means they do it for a living, and if they do it for a living, then that means they want to be paid week-to-week (or whatever their contract says) to feed their families. Professionals almost never work on promises of payments, because promises of payments almost never actually result in a finished game.


They usually have their own websites, too, so you can find them on their websites.

You can definitely find inexperienced beginners who'd work for free, or for a promise of payment, but their quality is very hit and miss, and you'll likely find that even if they do great work, that since they aren't being paid, they often end up leaving (when ""life interferes"") halfway through the project, and the next artist you get might not be able to mimic the style of the first artist, giving your game a clumsy mixture of different styles, or else forcing you to scrap all the art you already had. This is really common when you aren't paying real money (promises aren't real money).


I am a programmer and I am about to start developing my first game. I have the basic idea for the game.

You might be jumping the gun a little.

If you are new to game development, and never released a commercial project before, and don't have the money to pay upfront, the "correct" way to go about it (in my opinion) is to work on your game yourself without artists and writers, until you actually have put in enough labor yourself that it proves to other people that their labor won't be wasted on a random person with an idea (of which there are a hundred thousand or more on the internet).


The vast majority of hobbyist/indie projects never make it to completion. So you have to prove yours will, by putting in enough work that the game is already playable before recruiting others.

#5285917 Player Generated Weapon Designs

Posted by Servant of the Lord on 08 April 2016 - 04:01 PM

I'm assuming you're talking about ORPGs or other MMO-ish games.


An interesting point, as a few pointed out I suppose there are a few major issues to resolve with the primary being that the better looking models also need to be more rare/expensive to keep them feeling "special".


Why? That just seems like it'd lead to a escalating war of one-upmanship of making weapons look more and more "impressive", which can rapidly become a downward spiral of tackiness.


I got a sword! Now I have a sword +1 with spikes on it! Now I have a sword +11 with blue energy or fire coming out of the spikes! Now I have a sword +27 that has other swords sticking out of it!!!!!!!!!


And let's not even get started on the bows...


Why are weapons just +1 increments of each other that rapidly get obsolete?

Why not make weapons be more unique gameplay tools with balanced tradeoffs, that have different usages in different circumstances or enable different styles of gameplay?


It seems the war of tackiness is an attempt to try to make players be impressed by the visuals to distract them from realizing the weapons themselves aren't any more impressive. We try to hide the '+1 extra damage' behind fancy glowy effects and intricate designs, so the player doesn't realize that the actual item is gameplay-shallow.


So instead, why not invest the effort into making the weapons gameplay-diverse and gameplay-enabling instead?


If you have 271 different swords, but the player doesn't have to do anything different regardless of which one he has equipped, is it really adding to the gameplay, or is it merely a content grind? And if it's merely a content grind, what do you do when the players run out of that content? Race them to try to create more, despite them always consuming faster than you are creating?


The same can be applied to your dungeons, spells, and many other things. Do players get it, get use it, and discard it? Why? Maybe it's because the 'content' isn't actually adding to the gameplay?


Look at World of Warcraft's dungeons. People play them, beat them, and forever leave them (until they create a new character).

Compare to Call of Duty: Modern Warfare's multiplayer arenas. Players play the same level, over and over, and over and over, for a thousand matches or more.


Look at the wildly popular League of Legends.... they have (basically) one level. One level. That 25 million people have played for more than 100 times each.


It's not the content that's the problem, it's the fundamental design of the game that the content is in.

#5285911 Why learn STL library

Posted by Servant of the Lord on 08 April 2016 - 03:22 PM

I presume you mean "STL" in the sense of the C++ standard library and not the actual STL that eventually influenced/became the standard C++ library.

Seeing that even C++ standard committee members refers to (a specific subset of) the C++ standard library as "STL", that historical footnote really no longer needs to be mentioned, IMO.
(the specific subset is the algorithm-iterator-container chunk, which I'd guess is 70% or more of the overall standard library)


Should people avoid books like these because 'the STL is no longer used'? (edit: okay, bad example, seeing as that book is from 2001. But I hear standard committee members using the term STL in modern conference talks as well)


I think denying that usage brings more confusion than permitting it, though obviously many disagree. Especially 20 years later when a beginner isn't likely to accidentally be using the SGI-STL, and anyone using something like STLport is experienced enough to already know the distinction, I think this programmer-war can be laid to rest.


The C++ Standard Library is not the original STL. But a large part of the C++ Standard Library has also adopted/co-opted (through general usage) that name.


If I know what is function , variable , pointers , template class , classes .... etc in C++ , why is it so important to learn the STL library , and how good will I need to know the STL library ?

You need to learn how to use it, but you don't need to have perfect memory for it. It should be the first tool you reach for, rather than re-inventing the wheel, because the more you understand it, the more you can reinvent the wheel better if you need to, and the better you can communicate with other developers who also understand it.


Shared knowledge is great for communication. I can say "linked list" or "unordered map" and everyone else knows what I mean. They can mentally translate it into their own context (like "unordered map" might be a "hash dictionary" in whatever C++ library they're using for their project, for example).


It's worth learning because it'll stretch your mind; it's worth learning so you can communicate with other developers better; it's worth learning because they are great general-purpose tools that you can replace piecemeal when you require something more tailor-made.

#5285907 Should getters and setters be avoided?

Posted by Servant of the Lord on 08 April 2016 - 03:11 PM

The distinction is that a property/accessors/get-set should not perform a lot of work and should not affect another object.  


Agreed. I explicitly use different words if the function has to do more work.


An example is 'Find'. If a search has to be done, then it's 'FindX()' instead of 'GetX()'.


If something potentially has to be loaded/created/processed before being returned, then I call it 'RetrieveX()'.

For example, "RetrieveAnimation()" returns a fly-weight shared animation handle, but if the animation hasn't ever been loaded (or was freed earlier because of no sharers) then the function has to actually load the animation from disk first (or else return a dummy, pop an async task, and later swap the dummy for the real thing).


Basically, I only use 'Get' as a word if the class already knows exactly where the variable is, and can just return a reference or const reference to it.


Being consistent with your naming scheme is important. I can see how someone might get burned by using 'Get()' to mean virtually anything, and then try to "fix" the problem by radically redesigning their class designs rather than just learning better function naming. Programmers often like to overengineer complex solutions to simple problems. I know I do!  :P


That said, immutable objects are very useful in some contexts, so I don't want to throw out that tool either. And tiny structs that have all their data members exposed publicly are also useful, and shouldn't be wantonly banned because of misuse. Fix the misuse, don't ban the tool. And if one particular person has continued difficulty learning which end of the drill to hold, then you might need to ban the drill for that one person so they don't hurt themselves or others.

#5285902 How to design skylight/starlight for 2d top-down with no skybox?

Posted by Servant of the Lord on 08 April 2016 - 02:52 PM

Here's how one Zelda-esqe game (Hyper Light Drifter) did indoor skylights:



(looks better when zoomed out, IMO)


And here's something I was playing around with for my own game:


#5285694 Typing skills

Posted by Servant of the Lord on 07 April 2016 - 08:28 PM

As others have said, programming isn't just typing as fast as you can on a keyboard. 

Programming is predominately about thinking. Words-per-minute is not a problem.

#5285476 Companions as Combat Mechanism (Mechanic Idea)

Posted by Servant of the Lord on 06 April 2016 - 01:51 PM

Sounds fun. My only critique is that your characters seem like cliches.
I'm not saying your ability choices are bad - I'm saying you are pairing the abilities with over-used personalities.

The major difference is that the main character, let's call her 'Diamond' will not have any significant combat abilities, they'll simply be the Chosen One, or a great tactician/strategist, or some combination thereof.
Ruby, a tempestuous girl with fire powers. [...] Ruby, is able to light up dark places, cut through wooden obstacles, burn dangerous plants and of course spit that hot fire that makes enemies cower and die. She of course, has personality for days to balance your generaly silent protagonist [...] she has a weakness, that she will act in rage if you are hurt at all
O.J. is that big dumb strong gentle giant type and he has the ability to move large objects, hold things open and when he can get close to an enemy, he can hold them or pack a mean punch, as well as is a pro at guarding you against projectiles and throwing you across chasms too big to leap across.
[...] he is an outcast amongst his people for a crime he didn't commit, and in dealing with him you learn of his hesitancy to act because of this experience, so he can be really slow to 'activate' at times.
Other party members may include 'Amber' a shy catgirl who can find/sense invisible enemies and transforms into a huge tiger-thing your whole party can ride on to traverse the overworld;
'Jaden,' a know it all Link-wannabe who does a heap of the expositional narration usually reserved for companions like Navi and Otacon, 'Azure III,' a shapeshifting water creature who can turn into a variety of handy forms as you teach him to
'Amethyst,' a psionic entity who can possess other creatures to recruit them temporarily to your cause.

You seem to be partially aware and/or resigned to this, even from your descriptions:

once you defeat Amethyst and she joins you is very similar to what you feel when you have everything full as Okami or Link
they'll simply be the Chosen One, or a great tactician/strategist, or some combination thereof.
that big dumb strong gentle giant type
an appropriately themed enemy such as "Onyx" and his army "The Quartz" or some such. They want to turn everyone into statues so that they can live in a perfect world without sin or something[

 It feels like you are trying to be unique in gameplay, but then copy+paste your world and copy+paste your characters. Why not innovate in every area?

Designing it is supposed to be fundamentally similar to designing any other puzzle/platformer action/adventure game

Why is it "supposed to be" similar to "any other" game of the same genre?
Or, let me put it like this: Many of the games you love have unique worlds, unique characters, unique gameplay, but have a "lowest common denominator" that they share in common with the other games of the same genre.
If you average those games together, what you are doing is removing their uniqueness, and being left with the cliches. Then you're using that to make your game. i.e. you are starting from cliches and building inward, instead of starting from uniqueness and finding out that your game is similar.
You don't have to be different merely for the sake of being different, but you should try to avoid starting off bland.
Why is the spunky red-head girl the one with fire powers? Why isn't she, say, a water mage who actually hates her own abilities, because her abusive sorcerer father waterboarded her until she learned to master the element?
How come the big buff guy is an idiot? Why is he even big + buff? What if he is normal-proportioned but still muscular and incredibly strong? What if he is intelligent and had a quick wit to boot? What if he uses his humor and sarcasm to establish a faux persona to hide his pain and guilt from blaming himself for his wife's death?

(you don't have to go for such serious blackness as dead wives and abusive fathers, just the first examples that sprang to my mind. Original doesn't exclusively mean dark, nor does 'mature' have to mean violent, occultic, or sexual).
What if the "know it all Link-wannabe" really is a knowledgeable and courageous female, and doesn't act like a know-it-all, but is generally a useful adviser and strong ally, a friend you can rely on, who's not designed to be annoying, but rather designed to be useful and competent?
Why is the catgirl shy? Why's she even a girl? What about someone visually like Lynx? And what if he's malicious and cruel, like a cat playing with his food, but still on your side as a loyal ally who you can trust? No, you don't automatically have to make him do a heel-face-turn... what if he's generally loyal to his friends, but also generally malicious when it comes to his enemies?

Even your villain sounds like an after-thought, and his motives sounds like something from the 60's era batman. Turning everyone to stone?    *yawn*
That automatically lost its significance as a child once you realize that someone "turned to stone" automatically means they'll be un-turned to stone, so it's a lesser alternative to death for children's games and TV shows. Turning them to stone is actually a subconscious promise that those characters will be brought back to life, and thus cannot die (unless you turn them to ice and then shatter them immediately).
And if you intend to invert that trope and make them never come back to life, that means for the vast majority of the game, people will assume your game is cliched, making it less enjoyable, until right at the end they find out after their done playing that you aren't being cliched - but it still damaged all the hours of gameplay leading up to it.

Writing can be simple, complex, mature, or shallow. If you want to target younger audiences with a simpler story, you might stick closer to cliched characters that are easier to understand and categorize.

Even children appreciate new things and interesting characters. Simplifying characters doesn't mean you have to go for the cliches.
You can make things simple and deep. You can make things simple and original (or rather, less-cliched).
Kids may not get all the nuances, but they can still get excited and enjoy something new or someone cool and different.

If you want a mature story that older audiences will be attracted to, don't worry about the impression or complexity of the visuals or the mechanics. If they like your style, they'll like it. The main focus is how much depth the characters and their stories have.

Complexity isn't depth. You can have simple and deep, you can have complex and shallow. Things can be needlessly convoluted and complicated and still end up being shallow.
Adding complexity can be a way to fake depth, but it's the cheap way out.
And yes, you absolutely should worry about the complexity of the visuals even for adults - not necessarily because it'd confuse the adults (though it can!), but to overall make a better product.

The more depth, the more attracted intelligent and mature audiences will be to your game.

Now that, I agree with. Though I wouldn't tie intelligence and maturity too tightly to age - I know several people who as kids, were way more mature and intelligent than many adults.

So, to reiterate: the target audience is determined by the difficulty of the gameplay and the complexity of the characters.

Difficulty doesn't equal 'deep' either. Things can be simple, easy, and deep; complex, difficult, and shallow; simple and hard and deep, and so on. They are different variables.
We might just be using different definitions of the words, but just in case, here's a simple onramp to thinking about this deeper.

#5285376 Stage 2, learning game programming C++.

Posted by Servant of the Lord on 05 April 2016 - 08:48 PM

I agree that working on some (small-ish) projects is the way to go. Study is super important, but it must be paired with actual experience as well.


Also, make sure you don't fall into the trap of trying to memorize API after API - learning to use a library isn't the same as learning to program, and learning 20 different APIs doesn't automatically make you a better programmer. Being a good programmer isn't about what libraries you know how to use, but rather, programming is about learning how to build (and maintain and expand) great programs, regardless of what APIs are in front of you.


APIs and basic language features (like templates, inheritance, etc...) are all "surface level" knowledge. Programming is about building and comprehending complex projects which requires that surface-level knowledge, but is much more than that. You're doing good, but you need to go deeper - and 'deeper' that doesn't mean more of the same.

#5285336 What is the difference between an Critique and a Review?

Posted by Servant of the Lord on 05 April 2016 - 02:02 PM

Am I right in saying that a Critique is not just stating your opinion of what is good and bad, but trying to back up the opinions as well?


That's kinda putting the cart before the horse. You aren't trying to back up opinions (which are subjective). "You're ugly! And, uh, *quickly googles up some out-of-context 'facts'* here's evidence so I can win the argument!"


I don't know much about painting, so I look at a painting and say, "I don't like it, it feels weird, and the colors clash too much, but that pattern on the guy's clothing looks cool."

An artist looks at the painting and says, "Your perspective with this object doesn't match that other object, the shadow there doesn't actually line up with that light source, color A shouldn't be paired with color B because of (color theory magic), those stones look too clean."


It's not trying to gauge quality/worth, it's trying to examine flaws, as a fellow creator, that'll be useful to help the creator improve the work.


Reviews say, "The game is good, here's what I liked/didn't like from the perspective of a consumer, based on my tastes."

Critiques say, "As a fellow designer, here's what you need to remove or improve, based on my experience and knowledge."


Reviews are usually (but not always) more geared toward other consumers, to give other consumers more information to make an informed buying decision.

Critiques are geared toward the developer or other developers, to help improve each other's craft.


Because there is some overlap (they can both be feedback, or they can both not be feedback), the words occasionally get used interchangeably.


Another subtle distinction is that reviews are saying what's good/bad, critiques are saying why it's good/bad.


Here's a quick review of a single screenshot - it's me speaking about what I'm feeling, as a consumer.

Here's a critique of some game mechanics - it's me debating (with explanations) about why I think that's not a good idea, as a fellow creator.

Here's a review of a single music track - it's me speaking about what I'm feeling, as a consumer.

Here's a critique of laying out game worlds - it's me explaining what I think is wrong with the poster's current approach, and what I think a superior approach is, as a creator.


All four of these also happen to be feedback directed at the original creator to help them improve the work, but reviews and critiques can both just as easily be directed at other consumers or other creators. For example, one designer might critique a game to help other designers (not necessarily the original creator) learn from its strong-points and flaws.


Another example is, a few months ago, I was proof-reading a friend's book for them. Not being an author myself, I was reviewing the story as a reader, to give the author feedback on what I thought of the story, and offering suggestions and opinions on the descriptions, sentence-flow, and overall plot. At the same time, I was also critiquing the author's punctuation, grammar, and spelling.

#5284416 Obstacles in a dungeon?

Posted by Servant of the Lord on 30 March 2016 - 09:49 PM

1. Strength - Heavy wooden door to be bashed down

2. Agility

  • Running across a collapsing bridge
  • Running up a heavily sloped ramp
  • Activating two timed switch and running through a door before it closes again

3. Intelligence - Recognizing (via observation) a hidden door that looks like part of the wall

#5284165 C++ RPG books and tutorials

Posted by Servant of the Lord on 29 March 2016 - 09:56 PM

I would steer away from "Book designed for narrowly specific category X".


If you want to learn programming, you ought to learn C++, SDL, OpenGL, and game architectures in general.


The reason for this is because even though books like "Learn to make RPG games using SDL, OpenGL, and C++" actually exist, they tend to spend part of the book teaching C++ poorly (or glossing over it), part of the book teaching SDL poorly (or glossing over it), part of the book teaching OpenGL poorly (or glossing over it), part of the book teaching game architecture poorly (or glossing over it), dump a bunch of source code on your lap, and pretend that everything is obvious and "Now you know how to make games!!!!! Go make your own!!!!", leaving you with a $60 paperweight that you might've learned two or three good things from, a dozen things you could've learned online for free, and two dozen bad poisonous practices that you'll spend years not realizing have harmed you more than they helped. </opinion>


Buying a book on modern C++ is great (if written 2012 or later - almost everything before that is either outdated, or not beginner material anyway). Buying a book on game architecture is great because programming practices and general knowledge can be useful even a decade or two later. Buying a book on OpenGL or SDL or any specific API is bad, because whatever book you get is likely outdated before you even read it. For APIs like SDL and OpenGL, I suggest just using online resources.


In general, APIs change every year or so, languages change every six or seven years or so, and general programming practices change every decade or two. Leastwise, that's my experience in my tiny corner of this vast programming forest I've intentionally gotten lost wandering in.


For the things that change infrequently, a book or two can benefit greatly, coupled with online reading, googling questions, and then forum questioning.

For things that change frequently, skip the (almost always outdated, very often poorly done) books, go strait to online resources/tutorials, googling questions, and then forum questioning.


Yes, you can get some benefit from API-specific books, and some benefit from "Learn to make RPG games using SDL, OpenGL, and C++"-style books, but you can just as easily get that information online, for free, often written by the authors of those APIs, and directly ask questions tailored directly to your information-gaps when still confused.


Another general spot of advice: Don't pay for online videos or online tutorials also. While a few might be good, it seems like most are junk, and you can almost always get the same information through tutorials, articles, and googling and asking questions.


Hopefully that helps. Welcome to the community, btw!  :)

#5284147 trade marked orc design

Posted by Servant of the Lord on 29 March 2016 - 06:23 PM

That said, I'd suggest that you don't use Blizzard's orcs for reference material, that is to say, don't look at Blizzard's orcs while creating your orcs, and don't think about Blizzards orcs.


Make your orcs, yours. Or make your own creature entirely. When designing your orcs, maybe look at real-life bat photos or something, as reference material.

#5283993 Making my game code cleaner/easier to work with

Posted by Servant of the Lord on 28 March 2016 - 10:58 PM

Taking the same chunk of code LSpiro quoted, there's many variables there that aren't needed, and some of the names need to be cleaned up as well:

	sf::RenderWindow GameWindow;
        sf::View GameView;

	//sf::Event event; //<-- This is a temp variable, so why is it persisted? Also, why is it lowercase when everything else is uppercase?
        //Width and heights go together so much, you really ought to have a struct that keeps them together.
        //Further, you don't even need these, because these are either made redundant by sf::RenderWindow's "getSize()" function,
        //or else made redundant by sf::View's "getSize()", depending on whether your "screen" terminology means "Window resolution" or "view resolution"
        //It's also important to try and be consistent in your terminology.
	//int ScreenHeight;
	//int ScreenWidth;

	int Section; //What is 'section'?

        //(A) Make this std::string
        //(B) you are violating const-correctness by pointing a non-const char at a string-literal
        //    (this is only permitted for backwards compatibility, due to archaic rules).
	char *GameTitle; 
        bool Running; //This is redundant with sf::RenderWindow's  "isOpen()"  function
	sf::Sprite PlayerLocation; //This is a sprite... why's it called "Location"? If all you are wanting is the player's most recent global bounds, why not just save that?
	MainMenu Menu;
	CharacterCreator CCreate; //Why's this have some weird abbreviated name? 'CCreate'!?
	Map GameMap;
        //This is another example where you should strive to be consistent in your terminology.
        //Why use both 'Player' and 'Character' if they have identical meanings in your code?
	Player Character;
	Location MapLocation;

It looks like most of your naming is trying to jump around name collisions with the types themselves.
For example, it looks like you want names like "Map Map", "MainMenu MainMenu", and "Player Player", but you can't, so you do "Map GameMap", "MainMenu Menu", and "Player Character".

If you named your class types with an uppercase, but your instances with lowercases, you wouldn't have that problem.
It'd then be: "Map map", "MainMenu mainMenu", and "Player player"


        std::string gameTitle; 
	sf::RenderWindow window;
        sf::View view;

	int section;

	MainMenu mainMenu;
	CharacterCreator characterCreator;
	GameMap gameMap;
        Location location;
	Player player;
	NPC testNPC;

This would be further cut down, by making NPCs and other entities part of the map they are in, and making an array of gamestates that you index into with your enum, instead of manually switch()ing in every location you need to access gamestates.


Instead of doing things like this: (saving things like 'PlayerLocation')

Character.Event(event,GameWindow,GameView,PlayerLocation); //Unnecessarily saving the player's location, now having to keep it in-sync with the actual player...

TestNPC.Show(GameWindow,PlayerLocation); //Passing in an entire sprite when all you want is the global bounds...

You add a function to 'Player', and do this:


TestNPC.Show(GameWindow, Character.getGlobalBounds());

#5283666 Can memory leaks only caused by using the new keyword?

Posted by Servant of the Lord on 26 March 2016 - 10:06 PM

If you are opening Task Manager, and seeing the "memory" usage climb higher, that doesn't automatically mean you have a memory leak. It doesn't mean you don't, but it doesn't mean you do.


Task Manager shows how much memory Windows is making available for your program, not how much memory your program is using.