• Create Account

Banner advertising on our site currently available from just \$5!

JTippetts

Member Since 04 Jul 2003
Offline Last Active Yesterday, 11:02 PM

#5175705Looking for C++ engine for 2D isometric game

Posted by on 23 August 2014 - 05:41 PM

You might give Urho3D a try. Grab the latest commits from the repo, rather than a release build, as there has been a lot of activity on the 2D side of things, including a tilemap structure with isometric capabilities. The chief drawback might be the documentation on the tilemap lacking a bit due to its newness, plus possible bugs.

#5172062Trying to figure out the Accidental Noise Library

Posted by on 07 August 2014 - 10:21 AM

I understand that it's a pretty complex process. I did download your newer source from google code and compiled it. I haven't played around with it yet. I am starting to finally shape terrain with a full length ground level with hills and mountains after playing with a few numbers, but still having problems with the cave systems, which render as a huge open area with a bunch of floating islands.

The Ridged Multifractal module is a hairy beast. There really isn't much in the way of internal 'taming' of it going on in the code, so the default output range can be weird. A quick analysis of an 8-octave Ridged using a Gradient noise basis and quintic interpolation shows that the values of the fractal are distributed like so:

The maximum value output by the fractal is 1.968995 in the test (corresponding to the right hand side of the image), and the minimum value output is 1.15179 (corresponding to the left hand side). The 'peak' in the diagram falls at approximately 1.70723, and roughly corresponds to the value that is most commonly output from the fractal. So if you use a ridged multifractal as a selection mask, as when doing caves, you need to ensure that your selection threshold lies at an appropriate location within that curve. Given that the distribution of that curve is so odd, you might need to experiment to find the sweet spot; and given that the curve can vary so rapidly especially on the higher end of the spectrum, small changes in the threshold value can result in large changes in the output mask.

#5171953Trying to figure out the Accidental Noise Library

Posted by on 06 August 2014 - 04:08 PM

I recommend that you start with the most basic functions (the gradient function forming the ground plane) and add complexity as you go. There are any number of ways such a complex tree can go wrong with but a single parameter change or error (and it can be quite difficult for someone, even myself, to browse through someone's function specification looking for such tiny errors),  so it would probably be best to work with simpler stuff until you have a good grasp on what's going on and build from there.

Additionally, I have not updated the Sourceforge repo of ANL in a long time. I changed to Google Code at one point, so the version [url=https://code.google.com/p/accidental-noise-library/]over there[url] is a LOT more recent. Specifically, the Builder code tree allows for far more concise function specifications in C++ than the repetitious pattern of (Create module) (Set parameters) (Set sources). There have also been a few bug fixes that made it into the Google Code library since I switched (although some other bugs yet remain that I haven't uploaded fixes for; I'm not much of a FOSS project maintainer, sadly).

#5152787opengl question

Posted by on 10 May 2014 - 07:57 PM

People have been very patient with you, phil. For a very long time. But you need to understand that you have to change your approach to all of this. It is just not acceptable for you to continue wasting the time of others. Before you come back to this thread, or any other new thread, I want you to re-read the advice given to you in past threads. I want you to really study it, because I promise you there are answers to your problems there. When you do come back, you really need to ask an actual question, and it better not be something vague like "how do I shoot bullets?"

I have been reluctant to employ actual moderation against you, but understand that my own patience (as well as the patience of others) is growing thin.

#5152773opengl question

Posted by on 10 May 2014 - 06:39 PM

Is it one you've already asked before? If so, the response is likely to be predictable. Are you prepared to take the advice of the responders, and make an honest effort to understand it and use it to solve your problem? If not, then again the response is likely to be unpleasant.

Unfortunately, you have made a name for yourself among many of the members of this community, and I believe it is going to take extraordinary effort on your part to overcome that. You are free to post, as none of your posts technically violate any hard rules, but just understand that if you expect anything good to come of it, you are going to have to work very hard.

#5152039The acceptance of gold loot in RPGs

Posted by on 07 May 2014 - 08:24 AM

I prefer gold drops. Hell, I even prefer that snake to have the chance at dropping a full set of platemail, 35 different potions and a massive claymore of impossible strength.

#5150942UV Unwrapping: Ugh!

Posted by on 02 May 2014 - 10:17 AM

UV unwrapping is, indeed, a tedious task. I don't really have anything to add to the discussion to make it easier, since I struggle with it myself even after all these years.

However, I would like to just throw a suggestion out there. How about eliminating UV unwrapping entirely? Depending on the style you are shooting for, it is entirely possible that you can make do with entirely procedural coloration/texturing, rather than texture mapping. Look at games like Cube World, which has minimal (if any) texturing, and relies almost entirely on coloration and AO to provide the rich visual appearance. On the other end of things, if you want more visual detail than simple vertex coloration, you can use techniques such as tri-planar texturing for terrain and landscape objects, and with some creativity, it can be used for all sorts of things.

Granted, doing procedural coloration and texturing moves work required from UV unwrapping over to additional shader creation, but for a programmer it can be a worthy trade.

#5144877I have some new habits.

Posted by on 06 April 2014 - 08:43 PM

Good point JTippetts. My goal is that an object can be varying degrees of happy and sad, as in happy, happier, very happy. The setup doesn't yet reflect the range of emotions I want to create.

The mood effects the state of the object.

So, the mood ranges from 0 to 10.

If the mood is between certain lower values, the state of the object is more sad. I just wanted to use words to convey the mood rather than numbers.

Sounds like you're struggling toward a form of fuzzy logic. I'd stick with the numbers and leave the words for presentation to the user. It is useful for the script to know that an object sits on the sad/happy index at 0.56, whereas it is far less useful for the script to know that the object is 'somewhat happier than normal'. 0.56 it can calculate with; the other is just meaningless.

Eventually I want a full Emotion class as well as a Senses class. And I want all of my syntax to flow like an English sentence. So I will be making it object oriented also.

I highly recommend against trying to combine natural language processing with fuzzy logic. Each can be complex; together it could be far more of a project than you really need to implement a simple Sims-like AI. Just stick with the fuzzy numbers on the back end and save the English for the player.

#5144870I have some new habits.

Posted by on 06 April 2014 - 07:59 PM

```--Emotional States
mood = 5 --initial mood (normal)
happy = false
normal = true
```
Is it really your intention that an object can be happy, sad and normal all at the same time? Because if that is not your intention, then there is really no need for these sad, happy and normal booleans. Especially since their state is set depending on mood, so you apparently already have all the information you need about their mood without the booleans. Doing it this way is just asking for trouble.

Posted by on 05 April 2014 - 02:36 PM

A first place to look if you're interested in learning how to make those types of textures would be the Polycount Wiki Environment Page. This tutorial (linked from the wiki foliage page) in particular can be adapted to tree and leaf foliage as well as grass as shown.

#5143618Component-Entity game design issue

Posted by on 31 March 2014 - 11:18 PM

Now you are getting into the next tricky part of these types of systems: communicating with objects and making them do their "thing".

In the Object-As-ID system, this is performed by iterating through all the sub-systems (graphics, physics, etc...) and calling some sort of Update() method on the sub-system which will, in turn, update all the various components. This type of system gets tricky in that sub-systems can often be very inter-dependent, and the order of updating can often be very rigid. For example, you might want to update Physics before you update Graphics (since the physics step will update the object's transformation, and Graphics will require up-to-date transformation to draw at the proper transform). As more sub-systems are added, this staging of updates can get complex and even brittle unless handled very carefully. However, we've kind of moved on from that type of entity system anyway, so...

How exactly do you communicate with an object that is composed of parts? Especially if you are not supposed to really know or care exactly what parts it comprises? Object lifetime and management systems typically shouldn't know or care how an object is structured, since that gets right back to the dependency problems introduced by static, hard-coded classes. So when you see lines such as:

```playerPhysics* pp1 = (playerPhysics*)player->component.at(1);
```
in your object handling code or main game loop like this, then you should have some alarm bells going off in your head since that part of your game really shouldn't know or care what components any given object contains, nor should it know exactly where to locate a given component like that. The game loop is responsible for handing off high level instructions to all objects, and the components themselves should handle the particulars.

So how can it be done? One commonly used technique is to implement event passing. (This is the technique Urho3D uses.) Somewhere in your system code is a structure or backbone that allows you to construct an event or message and hand it off, either to a specific object or to all objects in general, as required. Any object or component can be a message receiver as their needs require. In Urho3D, objects must specifically register for certain events, optionally originating from a specified object. (Defaulting to listening to the specified event originating from ANY object, if none specified.)

An event is usually configured as an event Type and some packet of arbitrary data that might be required by objects processing the event. (This is another tricky area, this specifying of arbitrary data packets, especially in statically-typed languages such as C++.) The high level game loop is going to launch off a sequence of high-level events which other objects will listen for and act upon. These high level events are staged in the proper order so that things occur as is best for the systems.

To cite an example, again from Urho3D, the main loop will trigger, in sequence, these events:

BeginFrame
Update
PostUpdate
RenderUpdate
PostRenderUpdate
EndFrame

Some of these events (such as BeginFrame/EndFrame and the post-update ones) do not necessarily convey any data. Others, such as Update, convey a packet of data which can be accessed by any objects receiving the event: namely, a floating-point precision value, TimeStep, indicating how much time to advance the simulation and animation. Any object or any component of an object can listen for Update to do its thing.

Additionally, sub-systems (such as the PhysicsWorld component of the scene manager, if present) might listen for specific events from the main loop and fire off additional events in response. For example, the PhysicsWorld will listen for Update and fire off, in response, the events PhysicsPreStep (right before the physics simulation is advanced) and PhysicsPostStep (right after the simulation is advanced), allowing other objects to listen for these events and act accordingly.

Events are hooked using a subscription model. For example, a component can subscribe to the Update event, providing a callback that is called whenever the Update event is broadcast. It can use this callback to implement things such as movement, advancing animations, etc... A component on a physics-enabled object could listen for PhysicsPreStep event, for example, and use that event to cause a force to be applied to the object that is equal to 2x the negative of the gravity force vector; the result of this force application would counter-act the force of gravity, then cause an additional impulse equal to the force of gravity but in the opposite direction.

By using an event system like this, it is not necessary that the top-level game loop have access to individual objects' component lists in order to apply updates. It just sends a generic update event, and the components handle themselves accordingly in response to the Update event and any other events that are subsequently generated.

Now, it is possible (and probably preferable) to still provide some sort of GetComponent() method to objects. Urho3D does. If you are confident that a given object contains a component of a given type, then it can be faster and much less messy to access that component directly rather than trying to go through the event system. For an example, in Urho3D you can add an AnimatedModel component to an object to implement an animated character. Controlling the animation, however, is done through an AnimationController component, which is used to play animations such as Walk, Run, etc... This controller component will call GetComponent("AnimatedModel") and obtain a direct reference to the animated model component in order to play the animation. Of course, such systems should always fail gracefully; if there is no AnimatedModel present in an object, AnimationController should not crash or segfault when looking for one. And typically, you would only use this direct access internally on a given object, since external objects usually shouldn't know the exact composition of a foreign object. How you handle these dependencies, though, is very much up to your particular game structure.

Events can be used to communicate between game objects (Player object might send a ApplyDamage event to a target combatant object, for example) or to allow a game object to communicate with all the parts of its self. (For example, in Urho3D animations can specify events to fire off at specific times during an animation played by AnimationController; other components owned by the object, such as a user-defined Footsteps component, could listen for a specific event generated by the walk cycle animation to know when to play a footstep sound.) Logging sub-systems can be set up to listen for all events of a given type, regardless of origin, in order to facilitate the tracking of event flow for debugging situations. While the coding for these kinds of event systems gets a tad tricky, the solution itself is fairly elegant once implemented.

#5143525Component-Entity game design issue

Posted by on 31 March 2014 - 11:59 AM

If you refer to the very top of the source code: I was in the process of modifying what I had laid out. I was attempting to use an ID-tag system (ergo: "isEntity" struct), but ran into a problem. I had an idea that seemed near impossible (templates with map containers, based on virtual functions from inheritance). After searching around Google, I stumbled upon that person's solution (which is exactly what I wanted to do, but was unable to express in C++).

The entity-as-ID flavor can be a little bit tricky. It's commonly used because it allows you to lay out your component lists in a cache friendly way, but the trickiness comes in dereferencing the ID to get the component. If you use a map keyed on the ID, then you lose the cache coherence, since the component can be sitting just about anywhere in memory, rather than in a sequential (flat) array. Some custom allocator trickery is often used to ensure that components sit in flat arrays but can still be accessed by dereferencing a map.

I understand what you're saying regarding "all objects (entities) are objects (entities)." What you're implying is that everything is dynamically created.
I've read so many differing arguments on the subject (posts dating from 2005 to 2014), this is what I've concluded: There is no universal concept of it yet.
Every person uses a different metaphor with their own conceptual idea of the design to solve their particular problem. The only commonalities between all is the "buzz words."

It's true that there is no universal definition. The commonality among systems, though, can be found in the maxim "prefer composition to inheritance". Entity/component systems attempt to follow this guideline by allowing the user to aggregate their objects from disconnected components. Unfortunately, while inheritance is well-supported in most object-oriented languages, composition is less so, resulting in the creation of many different systems. However, the end goal is usually the same.

And yes, dynamic creation of the objects is the key. The idea is that the "management" layers (that manage object lifetimes, etc...) work only with Objects, and don't care what the objects themselves "are". In order to make this work in a statically typed language such as C++, this root level object is usually implemented as a generic container of sorts, whose aggregate components are managed in a list or bucket of some type, rather than by hard-coding a separate structure type for each object as you are doing above. That way, you can just pass references to objects around, without worrying about type.

I will happily modify it to use strictly dynamically created entities ("objects" as you said) here shortly, and see what comes to mind afterwards.
I still cannot foresee how you would create an entity that reacts to gravity in an opposite manner than another object would (dynamic or statically created).

I would design the physics system such that the gravity force is applied through a "hook". (Some systems refer to such a device as an event.) When the event ApplyGravity is fired, one component can apply the force as is, another component could multiply it by -1 before applying it. Whichever of these two components you add to an object determines which of the two behaviors it uses. Note that doing it in this manner might require either significant modification of whatever third-party physics library you use, or creation of your own custom physics sub-system, since such simulation libraries are typically written from a simulation point of view, rather than from the event-driven point of view of a component-based system. This kind of "glue" code is usually the trickiest part of writing a component system.

Unless you're implying to create multiple sets of "physics components" and apply (staple together) it the respective entity?
Which, if that is the case, would mean exactly what I am saying: Everything is going to be hard-coded (to a "component").

That is what I am implying, yes, but I don't see where you get the idea it has to be hard-coded. You can provide your object description as data, and use an object factory of some sort to build it from the data description. If you are constructing a hard-coded structure, you're Doing it Wrong™. Yes, technically, this is object composition, but it's inflexible in the context of a game, which can possibly have many thousands of different object types.

```struct Player
{
PhysicsObject *body_;
GraphicsObject *animation_;
PlayerControllerObject *controller_;
};
```
This "works" but, as I said, it's inflexible. Changing the implementation or structure of the object can force recompilation, adding new objects can force recompilation, etc...

```struct Object
{
std::vector<Component *> components_;
};

player=new Object;

```
This method treats all objects the same: they are just objects of type Object. The systems that handle them don't have to be concerned with handling a thousand different concrete object types. Just one type: Object. The bits and pieces that differentiate a Player object from a Treasure Chest live solely in the components that are added via addComponent().

Doing it this way, you can implement a factory method that takes a chunk of data (XML, YAML, Google Protocol Buffer, Lua table, whatever you prefer) and instantiates an Object, then instantiates the components described by the data and adds them to the object. Changing the structure of an object, then, does not force a recompile: you simply change the data and feed it to the factory to instantiate a new object, deleting the old one. Objects are described 100% in data this way, making the inevitable tweaking of late-game polish much simpler.

Which brings me to another major question (assuming all above is true): How would you implement the system(s)?
A "world" system to represent in-game play (for a player), a "demoWorld" system to represent demo-play (by an AI-controlled player), and for networking, another system all together?

Thank you, and thank you for the reply. I will start modifying the source code from start to end now to follow what I understand.

The system I am accustomed to is that implemented by the Urho3D library, which is very similar to my roll-your-own systems of the past (hence my preference for Urho3D). An Object (in Urho3D, called a Node) comprises a set of 3D transformations and a bucket of components. By adding components to the bucket you add behaviors and characteristics to the object. One component might be a StaticModel, to implement a bit of world geometry. For a character, I'd add an AnimatedModel instead. For physics, you add a PhysicsWorld component to the base scene graph (which is, itself, an object defined by its components) and a RigidBody component to the object itself to implement the physics body. Various controllers can be implemented (ie, as Lua or AngelScript script components, or as custom C++ classes derived from Component) and added in. Since Urho3D supports Lua, I am in the habit of providing object descriptions as Lua tables, in data, that can be modified without forcing a recompile of the actual application. A factory method constructs an object from the Lua description. Urho3D itself implements XML factories natively as the standard means for instantiating objects, which can be used regardless of whether you are using straight C++, AngelScript, or Lua.

I recommend you take a look at how other people implement their frameworks. Component systems can get tricky; the idea of them is simple, but the devil really is in the details.

#5143368Component-Entity game design issue

Posted by on 30 March 2014 - 10:01 PM

You cannot acquire an entities input (player, NPC, etc) without hard-coding everything that should apply to that particular entity.
You cannot create a universal form of physics (to a degree), without hard-coding everything that should apply to a particular entity.

These two statements are not true.

What you are building up there isn't really what is classically called an entity or component system. A first indicator of that fact is that you have a vector of BALL and a vector of PLATFORM. In a component system, you would only have a vector of OBJECT. (Or possibly OBJECTID, depending on the structure you use.)

Any time you have hard-coded structures named BALL or PLATFORM you are most likely building something other than an entity system. There are a couple of different ways you can build an entity system, but all of them hinge around the idea that objects are composed of parts in aggregate.

One form uses an integral ID to tie the parts together, holding the actual objects representing the parts in numerous arrays scattered throughout the subsystems. Another form uses an OBJECT structure as a bucket, or container, of components, using the structure itself to tie the parts together. All objects are just objects; what make them act as balls or platforms are the components they contain or encompass.

#5141233Blender for making Games?

Posted by on 22 March 2014 - 10:04 AM

Seems like we might need a 3D Modeler War tag in addition to our Language War tag.

#5140451What is the best 3D game to make first?

Posted by on 19 March 2014 - 04:16 PM

JTippetts has a compelling argument for picking something you like, but sadly many beginners don't start small.

I note that JTippetts' goblin project looks like it is now in year 11. That many years, even at a hobby level, disqualifies it from being a beginner project. Over the course of a decade you can move from beginner to veteran.

Heh, true, in a way. The goblin project is only a couple years along, but before that were several isometric experiments and projects that led to it. I did do a lot of 2D stuff before I ever switched to 3D, so the 3D switch was cosmetic only. Still, though, I have always worked on RPGs. It's why I got into game development, so all these silly progressions and learning paths that people try to pawn off just seem, to me, to be specifically engineered to drive a certain type of person away.

Most beginners aren't looking for a decade-long project.

Not necessarily true, and kind of beside the point. Beginner isn't an all-encompassing designation of common characteristics. And making RPGs doesn't have to be a decade-long affair; you can just as easily make smaller ones. Many of the original RPGs I grew up playing were hardly complex.

"I want to make an MMORPG" is the common refrain in the For Beginners forum.  After a brief explanation about what "MMO" means, the next week it becomes "I want to make an Online RPG", then after they post a few times in the online forum and discover it requires work, a few weeks later it becomes  "I want to make an offline RPG", then if they bother to follow up, becomes "game programming is stupid. What are good free game makers?" And then a few months after they appeared on the board, they vanish after learning that while playing games is fun and entertaining and a diversion, it is different than making games which requires thought and effort.

On the other hand, this is an excellent filter for those folks who might just be wasting their time chasing something they don't really want to do. Being a game developer isn't a "right" that everyone possesses. The possibility of it is, sure, but if someone can't stick it out, then they can't stick it out and it's best to find that out as soon as possible. I understand the idea of all these step-by-step progressions that everyone makes. You know, "first make Pong, then make Breakout, then make Tetris, yada, yada, yada." I get it, someone's learned a few things and they want to give a hand up to others. But the good ones, the ones who are really going to make it... well, I doubt they usually do so by sticking to any progression laid out by someone else. Instead, they'll make it by chasing their own dreams and desires with discipline and focus. If they require a roadmap laid out by someone else, then I highly doubt they have the creativity and initiative to really make it happen. You can learn the things you need to learn without ever touching a Pong or Breakout clone, if such games are not your inclination. Following someone else's curriculum just seems counterproductive to me.

My recommendation for beginners is the same as my recommendation for everything:  Build the simplest thing that will possibly work.  The philosophy has worked well for me for two decades.

+1 This is an excellent philosophy to have.

PARTNERS