Jump to content

  • Log In with Google      Sign In   
  • Create Account

Servant of the Lord

Member Since 24 Sep 2005
Online Last Active Today, 07:54 PM

#5182301 New trends in gaming: voxels are the key to real-time raytracing in near-term...

Posted by Servant of the Lord on Yesterday, 08:46 PM

Outcast (game) was released 15 years ago (1999), and uses a heavy mix of early ray tracing with their height-mapped based terrain being treated by the rays as voxels, and it ran fully in software.


Raytracing is a very interesting technology, and developers have been integrating it into their polygon-based engines (with octrees also) for many years, doing it more and more as the hardware allows.

#5180609 What keeps players...

Posted by Servant of the Lord on 15 September 2014 - 09:14 PM

I'm in agreement with SunAndShadows on alot of MMO design-related issues (though with some differences in tastes about some aspects).


However, I want to highlight two of his her statements here as especially important, design-wise:


and limited initial customization because customizations should be earned within the game, and no classes because classes are evil and icky...

Sun and Shadow is coming at this from a different angle than I am, but I want to underline the significance of these two for other reasons. 


Pre-boxed classes have both pros and cons (for example, limiting diversity by forcing people into a limited number of pigeon-holes), one of the issues with classes is that it forces players to make important, long-lasting decisions (infact, the single most important decision of their character) before they even begin playing the game, guaranteeing that when faced with the decision, they are entirely lacking in the knowledge necessary to make an informed decision, unless they spend hours and hours reading details online before even starting the game.


When a player begins playing a game, the more important and permanent a decision is, the longer it should take before the game forces them to make that choice. And yes, you can use the choices as rewards for in-game progression if you want.



Mod edit: fixed your pronoun for me. wink.png

#5180168 What keeps players...

Posted by Servant of the Lord on 13 September 2014 - 09:43 PM

Thanks for that, I took a brief look... I'll read it later.  What should I search for to find the 8 role breakdown?

Wikipedia has a list of the categories, without much description.


I read the write-up about it in a book, and I can't find an online article talking about it.


Here's the graph though:



#5180125 What keeps players...

Posted by Servant of the Lord on 13 September 2014 - 05:12 PM

What keeps players coming back to an MMOG.

In order of importance: Community and Content (and potentially any Creations you make within the game).

Different players are interested in different things:

Hearts, Clubs, Diamonds, Spades: Players who Suit MUDs

(Note: 'MUD' (Multi-User Dungeons) is the term used for text-based online virtual worlds that MMOs developed from)


There's also more advanced Bartle MMO-player social categorization scheme that subdivides a cube into 8 chunks, rather than a square into 4 chunks, because it adds a third axis. 


To every suit of players, people you know in a game become one of the motivations of staying with a game even past it's normal 'enjoyability' factor, but it might not be the primary factor.


To socializers, other humans are content. Whether guild socializing, or just chatting with strangers in the town square. The more people are willing to talk with them (and especially, listen to them), the more valuable the game is.

To achievers, challenges are content. Both number-based achievements ("Reached 1542 strength!"), and skill-based achievements ("Finally beat that boss, without wearing any armor, while it was raining outside, and got my Grinder Of The Year achievement unlocked")

To killers, prey is content. The more the prey gets irritated or upset, the better.

To explorers, the world is content. Not just geographically ("Reached the mountain top, and found some cherry blossom trees"), but also mechanically ("I found if you mix cyanide with orange juice, it nullifies most of the toxins.").


Players can be a mix; they don't have to be one extreme or another, and they may have other interests as well.

#5180120 c++ smart pointer question

Posted by Servant of the Lord on 13 September 2014 - 04:32 PM

Speaking of pointers (and references) in general, when not pointing at dynamic memory:

Even in my more complex games, with dozens of classes and vectors of classes interacting with each other, I seem to be able to work around them just fine.
I'm happy enough to avoid them, but I'd prefer to avoid them knowing why I'm not using them

Pointers shouldn't be avoided, but they shouldn't be used just for the sake of using them.

By default, a variable shouldn't be a pointer; it's not a matter of knowing when not to use them, but knowing when to use them.

I'm going to admit, I'm still a little fuzzy on when exactly I would need to use a pointer (of either sort).
I'm mostly trying to learn more about them to figure out when exactly it would be appropriate and necessary (or even just more efficient) to use them.

Here are three situations where you might want a reference or pointer:
Usage #1: You use a pointer or reference when you need more than one variable to point to the same data (either for read-only or read-write usage), rather than trying to keep two or more variables in-sync with each other.
Usage #2: You also use a pointer/reference when you need to pass around a large variable to functions, but you don't want for to copy that memory when you aren't actually needing a copy.
Usage #3: Another use of pointers and references is when you want a function to modify an existing variable.

(There are other situations as well, these are just three common ones)

struct ButtonAppearance
   Font font; //Font for the button.
   Texture background; //Appearance of the button.
   Color defaultFontColor;

class Button
   Button(const ButtonAppearance &sharedButtonData)
      : sharedButtonData(sharedButtonData)
   {    }
   //We don't want to COPY the screen, we want to modify the original screen. (See Usage #3 above)
   //So we use a non-const reference.
   void DrawTo(Screen &screen) const
      //Draw the button background on the screen.
      DrawTexture(screen, sharedButtonData.background);
      //Draw the button text, using the shared font, but the local text color and the local text.
      DrawText(screen, sharedButtonData.font, textColor, text);

    const ButtonAppearance &sharedButtonData; //Const references are read-only.
    Color textColor;
    std::string text;

//We don't want to modify OR copy a huge number of buttons. We want to draw them in a way that doesn't
//change the buttons themselves (only changes the screen). So we pass the buttons by const reference. (See Usage #2)
void DrawAllTheButtons(const std::vector<Button> &buttons, Screen &screen)
   for(...every button...)
      buttons[0].DrawTo(screen); //We don't want to copy the screen, only modify the original screen.

int main()
   ButtonAppearance buttonAppearance;

   std::vector<Button> alotOfButtons;
   for(...however many...)
      //Every button is sharing the 'buttonAppearance' data, instead of copying it. (See Usage #1)
      Button newButton(buttonAppearance);

   Screen screen;
   DrawAllTheButtons(alotOfButtons, screen);
   return 0;

Passing by reference or pointer is roughly the same in size and performance as passing a large integer. This is instead of passing thousands of bytes of data for large arrays of data.


[Edit:] I should mention, smart pointers aren't just for extra safety (preventing human programmers from making really common mistakes), they also also for self-documenting code. Smart pointers show the intent of the code, both to yourself when you need to read or modify the code a few months later, and to others reading your code. They document the intent when used in a consistent way; they don't actually enforce intent 100%, because, while they use compile-time errors to say, "hey, you are accidentally violating your agreements to be read-only (const) or to be the sole-owner (unique_ptr)", you can actually tell the compiler to allow you to violate the intent (by, for example, removing 'const' from a variable in certain functions, or by manipulating the unique_ptr to take ownership from it).


So smart pointers are also about providing tools for programmers to make their code be less mistake-prone by allowing programmers to make promises that, yes, can be broken, but that are less likely to be broken by accident. These promises can be read by the compiler so it can make better optimizations, as well as read and comprehended by other programmers so they can make more informed decisions when editing code.


Smart pointers show greater intent (reveal more information) than raw pointers do.

#5180107 c++ smart pointer question

Posted by Servant of the Lord on 13 September 2014 - 03:07 PM

First, smart pointers don't replace regular points. They provide a safer subset of regular pointer features with addition bonuses like keeping track of how many smart pointers are referring to the memory and knowing when to delete the memory.

Typically, one could make a pointer and have it equal a reference object like:

int firstNumber = 10;
int *pointer1;

pointer1 = &firstNumber;//*pointer1 is the value located at memory of firstNumber.
I've been trying to get the same functionality with  std::unique_ptr and am failing to really understand how to initialize them and use them.


Objects on the stack, like 'firstNumber', automatically deallocate themselves when they go out of scope. You never* want to give an object created on the stack to a smart pointer, because after it goes out of scope, then the smart pointer will later go out of scope, and it'd get double-deleted and crash your program (if you're lucky). ohmy.png 

*Almost never. 99.999% of the time.

You don't want to take smart pointers and just use them to wantonly replace existing pointers wholesale. That's not what they are for. Only when you are manually allocating dynamic memory, do you want to use smart pointers to automatically do the allocating (std::make_shared()) and de-allocating (when the pointer goes out of scope) for you. smile.png


When you aren't managing dynamic memory, you don't need smart pointers. References are preferred, and raw pointers otherwise*.


*Or std::reference_wrapper(), but I don't want to toss too many new classes at you at once.


When you do create dynamic memory (when you actually need dynamic allocation), you do it like this:

std::shared_ptr<MyClass> myPtr = std::make_shared<MyClass>("arguments to pass to MyClass's constructor");

Some general guidelines:

  • std::unique_ptr is if there is a sole owner/observer.
  • std::shared_ptr is if there are one or more owners, and one or more observers.
  • std::weak_ptr is for the non-owning observers of a shared_ptr's memory.
  • References are for variables where you know the lifetime of the variable will outlast the reference.
  • Raw pointers are for variables where you aren't owning the memory, and the memory will outlast the pointer, and you want the pointer to either change later in its lifetime or else be optional (i.e. nullptr).

There are other uses for things like raw pointers, but these are just an example of the most common cases.

#5180001 VPS/Low-Cost dedicated hosting for in-house testing suggestions

Posted by Servant of the Lord on 12 September 2014 - 08:30 PM

I haven't used it myself, but Amazon.com's servers are cheap, and you aren't paying by monthly usage or anything, you're paying by actual usage. So you can have your stuff running for only a few hours a day, only on the days you need it. Apparently they have a free tier, even, if you're using less than a certain amount of resources.


Supposedly it's harder to get things set up though, because they do alot less hand-holding. If you do manage to get it setup, then it's a good long-term host as well, because of Amazon's economy of scale and intense competition with Google and Microsoft, their up-time and costs and supposed to be really good.

#5179924 Names for medieval tournament skills

Posted by Servant of the Lord on 12 September 2014 - 11:12 AM

Not sure I get what you are looking for, but here's an attempt:



Downward Swing

Backhanded Swing

Foward Lunge

#5179106 Other Uses for Graphic Libraries

Posted by Servant of the Lord on 09 September 2014 - 10:24 AM

Level editors, simulators, 3D modellers, CAD architecture programs, anything that needs information to be displayed in 3D.


I also enjoy making non-game desktop applications (in addition to games); it has a different "flavor" to it than game programming, and both are enjoyable in a different way.

#5178548 Is Unreal Engine 4 easier than Unity for mobile game development by an artist...

Posted by Servant of the Lord on 06 September 2014 - 10:58 AM

I will be programming the harder aspects of my game by following advanced tutorials on those specific topics (purchases from sites like DigitalTutors, etc) and asking questions on boards like this.


There are copious amounts of free tutorials; I personally wouldn't pay for online programming tutorials. <off-topic> Especially not (ugh) video programming tutorials. Programming, unlike 3D modelling (a predominantly visual medium, best taught through visuals), is best taught through text and diagrams - not through watching someone slowly explain it verbally. </off-topic>


And even if you are into video tutorials (to supplement, not replace, articles and text tutorials) there's plenty of free ones on YouTube. 

#5178367 GOTO, why are you adverse to using it

Posted by Servant of the Lord on 05 September 2014 - 12:28 PM

At the asm level, everything is a goto, so they're obviously not the devil. The argument is that certain uses have a structure -- if/then/else, for/break/do/while, switch, call -- and that this structure makes programs easier to reason about. Without any structure, programs are just spaghetti.

This is obvious at the time, but it was something that actually had to be explained back then -- structured flow control is better than spaghetti. High level flow control patterns are a good thing.


Goto usually isn't required in high-level programming because we've formalized all the useful uses of it into flow control keywords already.


I agree with this, and just want to add that the same can be said for other parts of programming languages that are considered harmful. Depending on that section of code's abstraction, you stop using some features to use other higher-level features.


malloc() is considered harmful in C++ when dealing with classes, if you aren't writing at a really low level, so use new and delete instead.

new and delete is considered harmful in C++ if you aren't writing low-level code. Use containers (like std::vector) and smart pointers (like std::unique_ptr) instead.


Goto is considered harmful... if you're working at with real basic languages lacking more advanced flow control.


For example, I've used GOTO in VBA and also in a custom game scripting language someone wrote I had to use for a hobbyist team project. It made sense and was the cleanest solutions in those circumstances. I've used it very few times in C++, but the C++ usages usually turned out to be because the code wasn't structured right in the first place.

#5177978 Beginners Observation: Fundamental Lack of Source Code Examples?

Posted by Servant of the Lord on 03 September 2014 - 11:47 PM

The third problem is, that your solution is often embedded in a quite complex program which will most likely not help any noob at all. A week ago someone asked me to show off my behavior tree implementation. Even if I have provided my 5000 lines of code, it would communicate with so many other sub-systems, that a noob coder would most likely not understand a single piece of code.

^^^ This ^^^
I frequently run into this, wanting to share small or even large chunks of my code library to help others, but then realizing I have to rip out and write replacements for alot of pieces.
Sure, I'd love to share my level-loading code! Oh wait, that depends on my Serialization library. Which depends on my ByteBuffer class. dry.png 
I can no longer just share a 15 line piece of code.
My code doesn't really exist in isolation - it's built up in layers. Code ideas (in theory and in actual practice) is built up in self-contained functions and classes that are built from other self-contained functions and classes to make complex code easy to reason about at high or low levels.
I'm most pleased with my programming, when I realize a complex function can be written in only a few lines of higher level code.
I wrote this today:

//Returns the diameter needed for a circle centered at [a rectangle's center] to contain all four corners of this rect.
unsigned cRect::GetBoundingDiameter() const;

 I was pleased when I realized I could write it as:

unsigned cRect::GetBoundingDiameter() const
	//The diameter of the circle needed, is equivalent to the diagonal of the rectangle it is containing.
	//The diagonal of the rectangle is equivalent to splitting the rectangle into two triangles and getting the hypotenuse of either triangle.
	//So, we just use pythagorean's theorem.
	return this->TopLeft().DistanceFrom(this->BottomRight());

Which I used to write:

//Returns a new rectangle that is large enough to contain all four points of 'rect', no matter how much 'rect' is rotated.
static cRect cRect::GetRotatedMaxBounds(const cRect &rect)
	//If a rectangle is rotated, all the rotations together form a circle.
	//The diameter of that circle is also the width and height of the square needed to contain that circle.
	int size = static_cast<int>(rect.GetBoundingDiameter());
	return cRect::CreateFromCenter(rect.Center(), cSize(size, size));

My goal isn't to cram code into a single line - often I spread out even simple equations over several lines just to help me understand them better.
My goal is to abstract ideas into their own functions, and make them easy to re-assemble as needed to accomplish tasks.
Tasks like this:

How do you load a file of lines like: "blah = 117" and "green = 35"

Into a std::map<string, int> that's case-insensitive?

Can then be solved like this:

auto myMap = StringToMap<std::string, int, case_insensitive>(LoadFileAsString("file.txt"), '\n', '='); 

That's a simple line of code, but to share it, I'd have to share the implementation of 'StringToMap()', and case_insensitive, and LoadFileAsString(), which depend on other functions.
For a quick example, StringToMap() is:

template<...bunch of template args...>
std::map<...> StringToMap(...)
	return StringListToMap<...>(String::Seperate(str, ...), ...);

(Using StringListToMap() and String::Seperate())
And StringListToMap() is:

std::map<...> StringListToMap(const StringList &elements, ....)
	std::map<...> map;

	for(const auto &element : elements)
		map.insert(StringToPair<...>(element, ...));

	return map;

(Using StringToPair())
And StringToPair() is:

std::pair<...> StringToPair(const std::string &str, ..., toKeyCallback, toValueCallback)
	auto pair = String::Split(str, ...);
	Key key = toKeyCallback(pair.first);
	Value value = toValueCallback(pair.second);

	return std::make_pair(key, value);

It's a useful piece of code. I'd like to share it with others... but it also is built on yet more parts of my library.

In this case, it'd require some string to int conversion functions and also is dependant on some functors I use that validate whether characters are certain symbols or not. I can swap them out with other functions before I share them, but many times it takes thirty minutes or more (sometimes much more) to get the code sharable enough that people can compile and run it. Sharing code has much more than a zero-cost in labor.
To share what is simple code, I have to either share five or so other functions or classes which might be built on five more which might be built upon five more, or actually make the function more complex by removing the dependencies and in-lining it in the function. The very purpose of those dependencies is to make it easier to code, and to make the use of the code more simplified and easier to read.
Neither solution is ideal, because either I'm now code-dumping dozens of pages of code and twenty or thirty functions, or I'm code-dumping a monolithic function that is poorly coded in a hurry just to share it, and hasn't been tested or debugged, neither of which is really helpful to a beginner, and both of which are very burdensome for me to do when trying to help a beginner.
So instead I make a mental todo note: "Seperate out your string parsing and conversion functions into their own self-contained library and release it as public domain.". Yeah, that's a month-long project of it's own, and I'd have to take time away from my real project to do it. I'd have to spend several weeks re-writing and re-organizing it to make it less dependant on other parts of the library, so I could release it in self-contained libraries instead of one giant library. It's something I'd like to do, but I don't want to take significant time away from my actual game development to do so.

#5177096 Little Combat Layout Question

Posted by Servant of the Lord on 30 August 2014 - 01:08 PM

I'd try to be consistent with other popular games in the genre. What to they do?
I vaguely recall FF4 having the player's party on the right, and doing a quick google search pulled up these results:
I'm pretty sure the second screenshot is when you get "ambushed", but I'm not positive.
Looking at both of those images, which one feels more 'correct' to you? Personally, the first one, only very slightly, just because I'm vaguely more familiar with it, seems more correct to me. I'd be fine either way.
HOWEVER! Having the player's team slightly lower down the screen compared to the enemy's team I think is even more "correct" for me, personally. I'm guessing, it's because psychologically, the team is "nearer" to me (with the camera angle of the tilted floor), or maybe just because many RPGs have your party at the bottom fighting up.

(Enemies moved slightly up, allies moved slightly down)
In your screenshots, it's also hard for me to tell which people are mine, because they all look like monsters. Maybe make the player's monsters slightly brighter colors than the enemies? Or put indicators over their heads or under their feet?
 (The yellow circle with the arrow indicator is the selected monster, any monster with a ring under it is an ally)
Further, simply as visual polish, you can dynamically scale the more distant enemies just slightly, to give a better illusion of depth.

(Enemies "farther away" shrunk down just slightly)


[Edit:] Plants vs Zombies has the good guys on the left.

#5176995 Starting out

Posted by Servant of the Lord on 29 August 2014 - 06:38 PM

If you already know the basics of C++, I suggest sticking with C++ and going deep in it. If people bounce from language to language too much, they run the risk of only learning the basic syntax and never learn the strengths of the languages.


I would suggest not using an engine, and using SFML or SDL, both which I can personally recommend as great libraries (though I haven't used the latest SDL, but I hear it's only improved since I used it - and I already loved it back when I used it. I currently use SFML, which is also really fantastic). I also hear that box2D is good for 2D physics, and if I was starting your project, I'd go with either SFML+box2D or SDL+box2D.


Good luck on your project! happy.png

#5176988 Starting out

Posted by Servant of the Lord on 29 August 2014 - 05:54 PM

If you haven't ever programmed before, then you ought to even start with text-output before doing 2D graphics (potentially - others may disagree with that). You need to learn the basics of the language before writing games. wink.png


Most 2D games don't use "engines", though they can; usually they are just written. They almost always use APIs though. I go into more detail about what I mean in this post.


Even if you decide to use an engine, different engines are better suited to different types of games, and you don't want to have to fight against the engine to make your game, so I'd have to know more details about the game before suggesting a specific engine. But it doesn't matter, because any game complex enough that I'd actually suggest an engine for, is not a game I'd recommend as a first project. ohmy.png


The difficulty is, how can you write good game code architecture, if you don't yet know how to program? It's kinda like trying to build a house when you've never even held a hammer before. (or more like, trying to write a book in spanish at the same time as trying to learn spanish itself! A tad difficult). So you may want to spend at least a few months learning the bare basics of programming before starting on even a small game. (And maybe your brother, if he's never done graphics design before, could spend the same few months learning the basics of digital game art, that way the two of you can hit your game running, instead of stumbling)


Neither Lua nor C++ is "best" - different languages serve different purposes; and there are many other languages besides those two. happy.png

What are your long-term goals in learning to program? Are you just wanting to have some fun? Consider Game Maker (or RPG Maker)! It's really powerful and flexible, and you can get things running quickly. Jumping into programming for the first time, you likely won't get things up and running quickly.


If you are actually wanting to become a programmer long-term, Lua or Python would definitely be a possible choice. You'll end up learning many languages if you program for a long time, but Python or Lua will still be useful even when you learn other languages. 

C++ is also a good choice (and the language I started with, and still use), but is also a bit of an uphill battle! Still, don't let that discourage - it is probably what you'll need to learn anyway, if you want to become a programmer as a career.


Whatever you choose, it's important to stick with it long-term. Programming isn't something learnt overnight, and even though you can master the basics in just a few years, you'll continue to learn more and more (or, at least I continue to, nine years later). So if this is something you're really wanting to learn, choose to be stubborn enough to stick with it through the boring parts. It's really fun and exciting, but also can be aggravatingly frustrating at times (rather frequently, actually dry.png). Programming is definitely worth learning though! I strongly recommend learning it! It's just not something that you can learn in a month.

So what are your actual goals? What are you wanting to get out of this project with your brother, and what are you wanting to get, long-term, out of learning computer programming? 


Sorry for being all, "life choices" and "career" and "goals and planning" when you're just wanting to make games and have fun. wacko.png But I can't give good advice without knowing what you actually want. smile.png