Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 13 Dec 2012
Offline Last Active Feb 06 2016 11:36 PM

Posts I've Made

In Topic: Dialog and Event trees

04 February 2016 - 12:07 PM

if the engine you're using is limited to one behavior script per object type, you'll need a script and object type for each desired behavior. if you want 100 different npcs, you'll need 100 different scripts and 100 different types.


if the scripting language has the power to query an instance of a type for instance specific data such as an ID #, and can do branching logic on that value, you can use a single branching script for all instances of a type. the script would use the instance ID to figure out which NPC its was controlling. from there, hopefully the scripting langue is powerful enough for you to figure out where that npc is, whats going on, and thus what they should say.  this would basically fold your 100 scripts into one big branching monster script, but it would eliminate redundant lines of script code, IE having the same lines of code in 100 scripts. so it would be somewhat easier to maintain.


if you can't do a branching script, there's still the possibility of making a script generator. you would give it a list of high level behaviors, and it would generate the script code for them. a slightly faster way to generate and maintain 100 scripts.


a variation on that would be to have script code snippets for each behavior, and use batch files with the the copy+ command to concatenate them into whatever kinds of scripts you need. 


obviously, any script will somehow need to know which NPC its controlling, via some ID info its passed or looks up, or by the object type (for one type = one script).

This reply was very constructive. This scripting language is more than powerful enough to test for an ID (or any variable) of a an NPC and can have virtually limitless scripts to reference from, or call functions from. Are you saying that I should create a separate script (such as a singleton) that will always be running, or listening, and for the NPC script to pass its parameters to a function on the external script signaling it the details it needs to make things happen?

I guess my question is, how could I use that external script to manage 100 different behaviours for 100 different NPC's when they all have very different conditions? Or am I missing the point?

In Topic: Where are the .a files in SFML 2.0?

28 June 2013 - 05:20 PM

Thanks for all the input and contribution to my problem guys!
The problem ended up being that none of the builds were compatible with my compiler. I needed to download a Nightly Build. I simply replaced the contents of the Nightly SFML with the ones in the current directory, rebuilt my C++ file and everything is working now.

My circle is on screen and I'm ready to sell it to Microsoft for a mere $120,000,000 and the rights to Halo.

In Topic: Where are the .a files in SFML 2.0?

28 June 2013 - 06:36 AM

Alright, thanks BitMaster. I get where I was going wrong now, I didn't understand that those errors were telling me I was using a version of SFML for my wrong compiler.
After downloading the MinGW version I am faced with a new dilemma. I've linked them all correctly, however:



I don't even know.
Honestly I should be able to understand this but, c'mon, I just want to display a blue circle.
My computer hates me.


I'm sure that I've put everything in its right space though.


EDIT: Okay, I rebuilt it and now I'm not getting the error above anymore. But now I'm getting the errors seen in the original post again! Except this time I've linked up the .a files and everything seems to be set using the MinGW version.


EDIT 2: Here's everything as it should be, and you can see the errors down below.


In Topic: Where are the .a files in SFML 2.0?

28 June 2013 - 04:42 AM


It's relatively the same error each time:
'undefined reference to `_imp___ZN2kfjalCOLORskfjaCOMMUNISTSsfllRENDERTARGETasfkPOLLjsfhjdCHILDSUPPORTsRNS_fkhsfaBLUEkljghf'

I assume you found it 'funny' to modify this error. Because if not, whatever is missing has nothing to do with SFML.

Never modify error messages. Always post them verbatim.

For the actual problem, either download the correct distribution of SFML for your compiler or build it yourself.

As a side node, this problem has nothing to do with graphics programming. It's purely a basic library issue.


I think that for anyone after spending days upon days sitting in front of a screen trying to understand the headache of C++ and OpenGL you will do absolutely anything to try and lighten the load. However in case I needed to reiterate, I got about 50 error messages upon trying to compile them, all starting with `_imp___ and then followed by lots of gibberish with random words inserted into them. If you'd like to see them all in their non-hilarious format, that's super. Here they are.




Personally I prefer the communist child support alterations.

Anyway, I had no idea this was not related to Graphics Programming. I have not had this issue at all until I tried to use Code::Blocks with SFML.
I just want to know where the .a files are, then I'll leave you alone and go buy some kittens. (SFML 2.0 is perfectly compatible with Code::Blocks and the GNU GCC Compiler)

In Topic: Basic Concepts of Programming

27 June 2013 - 11:56 AM


As a dissenting view, I'd just like to say that how computer architecture works, or what high level languages compile down to is largely orthogonal to being able to use them effectively.


Knowing all of that stuff won't help the OP understand bad tutorials better, it just provides more terms they don't understand and relationships that aren't clear.


Yeah, totally agree. I think the OP has two main problems right now:


1. The OP may be focusing on C++.

2. The OP may have tutorial-itis.


On 1., don't start with C++. Try C#, Java, or Python or just about anything else besides Perl or C or C++.

On 2., don't read tutorials. There are some good ones but most of them suck and at this point you won't be able to tell the difference.


Damnit, I just spent 3 days watching a 72-video series on C++. I feel like I have a handle on it but I'm not sure where to go next. I was recommended to use SFML to start making some really basic games but I'm already lost. It's like I learned the C++ syntax and now I'm in an entirely different world.


I read everyone's posts and I can't reply to them all, but I think I get the whole concept of stacks and binary a lot better now such that each variable takes up a certain amount of space and is allocated a memory address (hence why you can use pointers to cout << the address directly and see them) and it's helped a lot.

I guess my real problem now is picking either SFML or OpenGL and running with it whilst reading C++ books on the side.
I don't really want to learn about graphics though, I want to learn how to manipulate graphics but with the least amount of "learning to make Disney movies" side of it as possible. I am almost exclusively learning C++ for games.

I've tried C# and Java but I find them much harder and less enjoyable than C++. I know that everyone wants to become teh n3xt besterest AAA c++ pr0gramma in teh w0rld!11! and usually give up after a week but I'm generally interested in sticking with C++ and maybe using Lua to handle some of the load. Permanently. I've been coping so far, it's just come to a bit of a point where I'm unable to figure out what to do next.
I've learnt the syntax, I can do basic code and understand it relatively easy, and the rules are etched into my head. I just need the next step to making my really terrible 2D rip off of Pong in terms of manipulating screen graphics with an API through C++.