Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

122 Neutral

About certaintragedy

  • Rank
  1. Hi guys. I've been having some trouble with Eclipse CDT and referenced projects. I have one project that is a general code library. I have another project that's an application which needs to use that code library. The application's project references the library's project. I can compile everything alright, since the headers are in order, but when it comes to the linking stage it gives me undefined reference errors for all the functions in the library. I'd imagine this is an easy fix, but I'm relatively new to Eclipse and haven't been able to figure it out myself. To be clear, I'm not trying to build a DLL and link it or anything, I'm just trying to straight compile the library into the application (as though it were all part of the same project), but I'd like to keep them physically separated on disk. With Visual Studio, this was fine because I could just add the CPP files to any project I wanted and they would all refer back to the same single file on disk. So I'm just looking to be able to compile my code library into multiple different applications without creating a ton of copies of it on the hard drive. Thanks!
  2. certaintragedy

    So I'm sort of getting in a rut learning C++

    I started with C/C++ in seventh grade. I'm not of the school that says you should start with a "beginner" language first. Find some good books and really plug away at the reading and the examples. And code, code, code. If you see something in the book you don't understand, try to code it out yourself. Even if you don't know what you're writing and you're just straight copying it from the book, go ahead and do it and then play with what you've got until you understand how it works. If you find yourself falling behind then slow down and make sure you've got a handle on the basics before you move on. Put together little side projects that aren't in the book as you go to test your knowledge. I don't think there's anything inherently bad about starting with a language like C++, however there are some features of the language that I would be wary of tackling early on - namely templates. I'd stay away from templates as a beginner because you don't "need" them for any sort of fundamental task, and because the syntax and the related compiler errors can at times be a headache even for an experienced programmer. I say stick with it. Take things on step by step. Don't start working with classes and objects until you get a handle on how functions and arguments work in plain old vanilla C. Don't start trying to mess with pointers and polymorphism until you understand the OOP fundamentals. Try different books, code the examples, and come here when you have questions the book can't answer and you'll be on your way in no time. As a final note, I would start with a general beginning C++ book rather than a C++ game programming book (or better still, go through both at the same time). Learn to code then learn to code games.
  3. One thing to think about is that the clients only need to communicate with the server when their "state" changes. In your paddle moving example, let's say I press down the Left Arrow to move my paddle to the left. Rather than spamming the server with "Move Left" packets, one could be sent when I press the key and one when I release it, and the client and the other server could figure out everything in between.
  4. certaintragedy

    #Include Problem

    To extend a little on what Illco said: The compiler processes each CPP file individually. So, if you only have In DebugFile.cpp: #include "DebugFile.h" ... Then, when the compiler begins compiling DebugFile.cpp THE ONLY INCLUDES IT SEES are those expressly stated in DebugFile.h, regardless of whether Engine.h is included by some other CPP file. Remember, the compiler "starts fresh" in terms of includes for each CPP file in your project, so trace through your files from top to bottom and follow where the compiler goes as it hits each #include. Unless you've explicity stated either in the CPP file or in the files that it #includes that you want to #include some header, the compiler will not do it, and this appears to be the case with your example (although I'm only speculating without being able to see the DebugFile.cpp code).
  5. certaintragedy

    Totally Weird Error(C++)

    As was mentioned before, you #define basePlayer and then try to use the same name for your class. Basically what is happening is this (at least I'm fairly certain): 1.) You define an empty constant named basePlayer. #define instructs the compiler to replace any instance of the name you defined with the value you specify after it. In this case, you're instructing the preprocessor (runs before the compiler) to replace every instance of the name "basePlayer" with "" (nothing). 2.) You try to name a class basePlayer. The preprocessor sees this string and replaces it with any empty string. 3.) When you try to declare the constructor, the compiler actually sees this: public: (); and properly notifies you that this makes no sense. 4.) At the pointer declaration, the compiler sees this: * enemy; and properly notifies you that there is no "storage-class or type specifier" preceding the name enemy, which it requires. 5.) And finally, the real clue to your problem is the last error, where it's complaining about the unnamed class. Again, it's because you've instructed the preprocessor to treat that name as an empty string. Compiler error messages can often be very cryptic and misleading, but in this case it turns out they were pretty much straight to the point. As was also mentioned above, and as is advisable any time you're #defining things in the preprocessor, you should use names that won't appear elsewhere in your code. Often people use all capital letters for such things. The common standard for preventing multiple header inclusion is: #ifdef MYCLASSNAME_H #define MYCLASSNAME_H #endif
  6. certaintragedy

    The downfall of realistic AI

    Quote:Original post by headfonez say you have 500 npcs all on one screen doing just as people (socializing, completing a task, etc) It would either A, be extremly confusing/random looking as people sway to and fro or B, it would turn boring, much how life is already, knowing that certain people will do certain behaviors. For example, I can predict that Ill have either serious replies, sarcastic replies, or off topic replies to this thread. No matter the exact content, those three choices are predictable (and because of that, It looses its excitement/fun value) Realistic AI, if its very similar to life, would not be as much fun as something not based on reality I'll try to keep this reply light-hearted, direct, and pertinent! If you want to break down all the types of replies you get into three categories and only view them in terms of those attributes, then.... well.. yeah I guess it's not as exciting. I mean, you could break them down into one category: say... text-based. All your replies will be text-based, no surprises there, whoop-dee-doo, seen text before, will see it again. I'm mean, hell, at any given time all human beings are either participating in self-immolation or not participating in self-immolation. You would be in err to then use this fact to assert that there are only two possible states of human behavior, even though OF THOSE MYRIAD STATES we can break them down into these two categories. It sounds like what you're getting at is more of a design issue than an AI issue. Sure, highly predictable behavior can "boring," but a "realistic" AI is not necessarily highly predictable... I would find it very unrealistic if, when shot at, my enemies simply scatter about and run into stupidly walls. I would find it much more realisitic and ENJOYABLE if they seek cover and shoot back... even though this is probably the most utterly predictable thing they could possibly do. I'm not going to sit there thinking to myself "God, I'm so bored, when I get into this fire fight they're just going to hide behind the nearest obstacle, notify their friends for help and launch a coordinated counterattack, sooooo predictable." "God, when I give this input-output machine input, it's just going to give me output in return. How boring!" "This deterministic world is so boring. Everything's just cause and effect anyway." Ok, you were right, I am getting sarcastic :). But, I'm doing it to illustrate a point. I think you're confusing some things here. Whether or not a simulation is BORING is not a function simply of the AI that drives it... it's much more nuanced than that. Nowadays it's a matter of whether or not the AI and the environment produce a wide range of fun/interesting/challenging situations that in turn provide a variety of ways that the user can respond. You can't just say that realism is boring. It *can* be boring, sure, but before you can make that sort of assertion you need to look at a lot of other factors as well. Quote:Original post by headfonezI think that too realistic ai would be a disapointment. Alot like how life is. [emphasis added]. Somehow I'm thinking there might be other forces at play here rather than an opinion about AI :).
  7. certaintragedy

    c socket programming

    IIRC DGRAM sockets don't listen at all (as they are not connection oriented). You just recv() off of them.
  8. certaintragedy

    C++ Templated functions/class in another file

    // template_class.h template<typename T> class template_class { }; #include "template_class.cpp" //Contains class implementation
  9. How does one determine the type or processor that a program is executing on at runtime (under windows and/or linux)? Specifically I want to know whether or not I'm running on an AMD or Intel processor. Thanks
  10. certaintragedy

    Main Loop Issues

    In window.cpp, you're missing a 'break;' in your switch statement after the 'WM_KEYDOWN' case. The WM_CLOSE case follows, and as a result, pressing any key will immediately destroy your window.
  11. Well, if you were making a class that didn't use the run() function, then you wouldn't want your class to be derived from Window. This is one of the basic tenants of object oriented design. Perhaps your Main class should *contain* a Window object rather than descending from it. Read up on some basic OOP (object oriented programming) principles and then go back to the drawing board with your design. But, the overall answer to your question is that you shouldn't be deriving Main from Window at all. If it doesn't make sense for a run() method to be present, it should not be derived from a base class that has the run() method. This is the answer you should focus on. The direct answer to your question is that you cannot create an instance of an object (Main) that contains a pure virtual function (CWindow::run). There is no way around this restriction. You cannot create an object that has a totally non-existant function. In other words, because it does not define run(), Main is still abstract. This is not the answer you should focus on, but it's good to know nonetheless.
  12. certaintragedy

    language advice (no flamers please)

    Well, I'm not trying to be a smart-ass here, but I personally wouldn't expect too many kids to try and crack an educational game. I would imagine most of your potential clients would be schools anyway. And I don't really see how writing it in Java is "giving it away for free." I agree with previous posters: your best bet is probably just to finish it up in Java.
  13. certaintragedy

    what's up with cstdlib's rand() syntax?

    Yeah, the % operator is modulus. Should be in your compiler documentation.
  14. certaintragedy

    Peer based MMORPG Network Engine

    Either I fundamentally misunderstand what you're trying to do or I see some serious flaws. A limit of two to three clients per server is impractical in a variety of instances. Consider a major town center where upwards of 100 players can be in a geographically limited area at the same time. In this case, if each server is only supposed to serve two to three clients, you'd need to have 30-50 servers handling that small area. The problem is, each of the 100 players needs to know the positional information of up to 99 other players. In this case, you'd need to have the servers intercommunicate with each other which is problematic by my understanding: most importantly, this radically increases the amount of bandwidth and latency used to propagate player positions - instead of PlayerA->CentralServer->PlayerB + PlayerC + PlayerD... it's PlayerA->SomeServer->OtherServer->PlayerB, PlayerA->SomeServer->AnotherServer->PlayerC, PlayerA->SomeServer->YetAnotherServer->PlayerD. In an abstract sense what you're proposing is akin to a very complex equation that simplifies down to a known, simple equation. The p2p method you suggest is a complex way of handling the problem that should "simplify" down to produce the same results as the client-server model. The difference is in the inputs (bandwidth, latency, monthly fee, development time, etc.). In this case it would appear that you're proposing a solution that greatly increases the bandwidth, latency, and development time necessary to solve the problem and leaves the monthly fee at about the same level. The point is, the model that's being used presently is about as good as anyone has come up with thus far. Certainly, pursue your goal, but not to the extent that some sound skepticism doesn't give you pause.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!