Jump to content
  • Advertisement

Puck

Member
  • Content count

    78
  • Joined

  • Last visited

Community Reputation

374 Neutral

1 Follower

About Puck

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. *confusion* Boy do I ever feel dumb. That was the first thing I tried, but the compiler kept pointing to the method declaration and saying "invalid use of an incomplete type!" I must have been doing something else wrong though. Thanks for your quick reply, I appreciate it!
  2. Hello all, I have a bit of dilemma in a little C++ project I'm working on. The code is a bit lengthy, so I'll try to simplify it. I have two classes -- let's call them "A" and "B" -- which I want to allow conversions between that don't require an intermediate variable, say: somefunc(A.toB()); As opposed to: B tmp; AtoB(AInstance, tmp); somefunc(tmp); The obvious solution is to simply return an instance of the class I want to convert to, but because the conversion goes both ways, I have to return a reference since one of the classes has an incomplete type at the time of the method's declaration: class B; class A { /*ctor, dtor, etc.*/ B& toB(); } class B { /*ctor, dtor, etc.*/ A& toA(); } B& A::toB() { return B(*this); /*Overloaded constructor does the conversion*/ } A& B::toA() { return A(*this); } But I keep getting told that it's an "invalid initialization of non-const reference." I've googled the error and found that it's apparently because that statement returns a temporary. The problem is that none of the articles or postings I found offered a solution that would work in my case. Oddly enough, the compiler doesn't complain about the following code I found on a site about operator overloading: A& operator+=(const A& rhs) { /*add*/ return *this; } A& operator+(const A& rhs) { return A(*this) += rhs; } I don't quite understand the difference there, aside from the const-ness of the argument. Maybe someone can enlighten me on the subject. I could possibly return a pointer instead, but I can't rely on "somefunc" to free the pointer, so I would have to use a smart pointer or some similar mechanism, which seems excessive and confusing for such a seemingly simple task. So, with all that said here's my main question: What's the best way to return a reference to a new object in C++? Should I just resign myself to using a smart pointer instead, or is there a clever trick I'm unaware of? (As a side note, I see the forum engine still doesn't like plus signs [wink]) [Edited by - Puck on April 17, 2009 7:54:14 PM]
  3. The problem with your idea is that you create an entirely new problem: With players creating all these offspring characters that are each progressively more powerful, at some point they're going to become so powerful that none of your content is challenging any more. You could solve the problem in the same way -- with much less work involved -- by simply removing "caps" on levels, skills and statistics. Of course the obvious solution is to put a limit on how powerful characters can get, in which case you aren't solving the problem but rather delaying the inevitable. That's not to say the idea is completely without merit though.You're on the right track in giving players more incentive to create new characters and thus recycle content. The primary purpose of MMO design is to keep players p[l]aying for as long as possible after all. On the other hand, as much as you want them to players don't really want to replay the same content. "Been there, done that" they say. Traditionally the approach to this problem has been to provide multiple paths the player can take to get to the higher levels. "Well, I have a maximum level elf, but I've never played a dwarf before." The problem with this approach is that as the player progresses more of the world opens up to them, and the number of viable advancement locations -- dungeons of the correct level to put it another way -- he or she hasn't already visited tends to rapidly decrease. Near the maximum level the player tends to find that they've already seen everything and you risk losing their interest. The solution up until now has been to add new content in these level ranges to keep things interesting, but doing so also removes the original incentive to start over, and the low level areas get forgotten. With your idea you'll end up in much the same situation, where you have to add high level content to keep the progressively more powerful characters content, while the original low level starting areas get forgotten about as their offspring start becoming too powerful for them right at the start. At least, that's how I see it. You're thinking in the right direction, but when it comes to MMO design the simplest things have to be considered very carefully because not only will players try to defeat the system, but the system can even defeat itself if not designed correctly.
  4. Puck

    random crashing

    It's impossible for us to tell what might be wrong with your code without a little more information. If you've isolated the problem, then please post the context wrapped in [source] tags. By the context I mean the relevant block(s) of code, for example there "debug" is defined, where its type is defined if applicable, etc.
  5. Puck

    How Do I Make Games With Code::Blocks

    It's not quite so simple, unfortunately. Code::Blocks is only an IDE, you can't "make games" with it per se, you can only use it to write and compile code. If you want to make games, you'll need a little more than just a copy of Code::Blocks. First you'll need to learn a programming language. I'm guessing you've never programmed before, so I would suggest something more along the lines of Python, Java or even Game Maker. If you're absolutely intent on using Code::Blocks then you'll need to learn C or C++. There are a multitude of resources on all of these, so you shouldn't have any problems in that regard. Next you'll need the appropriate library for making games. pygame for example is a good choice in python, and there are a wide variety of multimedia libraries for C/C++. Game Maker has all of this functionality built in. Once you know a programming language and have some libraries to help you out, then IDEs like Code::Blocks can make your life a little easier by helping you manage the large amounts of code required to make a game. (As a side note, the forums mangled my original "C++" link. Apparently the forum software doesn't like it when you write C++ as a link. Someone might want to look into that.)
  6. Puck

    [SDL] Flushing Queue

    I don't know how your code is organized, but I would personally check the event queue within the fade in loop and discard input events you don't care about then and there while responding to events that should logically interrupt the process -- like the SDL_QUIT event that rip-off mentioned.
  7. Puck

    library headers directory structure

    That's because both "Include\" and "Include\al\" are in the list. If you include "al/alut.h" it won't be able to find "Include\al\al/alut.h" but it can find "Include\al/alut.h", so it uses that. Conversely if you omit the directory, it can't find "Include\alut.h" but it can find "Include\al\alut.h".
  8. Puck

    Another MUD question?

    Quote:Original post by Vallar However what is hindering me really is the lack of documents that would teach you the technical things about making MUDs in Python. Honestly you're probably not going to find a lot of documentation on creating a MUD server in any language because, quite frankly, there isn't much to document. A MUD server is just something that accepts connections and sends and receives text; the vast majority of your code will deal directly with your game mechanics. If I had to guess I would say that a lot of the appeal of MUDs from a programmer's perspective comes from this fact, and in turn they appeal to users because the programmers can focus purely on their game mechanics and usually offer innovative gameplay experiences that more complicated games simply cannot afford to. For example, here's a bare minimum "mud server" in Ruby: (Disclaimer: This isn't production quality code by any stretch of the imagination, it's only an example.) require 'socket' port = (ARGV[0] || 25).to_i server = TCPServer.new(port) breakhandler = proc { print "Shutting down\n"; server.close} trap("INT", breakhandler) trap("TERM", breakhandler) print "Server started.\n" begin while (session = server.accept_nonblock) Thread.new(session) { |arg| Thread.current[:client] = arg Thread.current[:client].print "Welcome to MyMUD!\r\n" Thread.current[:client].print "Enter your username: " Thread.current[:name] = Thread.current[:client].gets.chop Thread.current[:client].print "Welcome back #{Thread.current[:name]}!\r\n" names = Array.new() Thread.list.each { |thr| if (thr != Thread.main and thr != Thread.current) names.push(thr[:name]) end } Thread.current[:client].print "The void\r\nYou are standing in a void, there are no exits.\r\nYou see here: #{(names.empty? ? "Nothing" : names.join(", "))}\r\n" while (message = Thread.current[:client].gets) case (message) when /\/quit/i Thread.current[:client].close when /\/name (.*)/i Thread.current[:name] = $1 when /'(.*)/ print "#{Thread.current[:name]} says, \"#{$1.chop}\"\n" Thread.list.each { |thr| if (thr != Thread.main and thr != Thread.current) thr[:client].print "#{Thread.current[:name]} says, \"#{$1.chop}\"\r\n" end } else Thread.current[:client].print "Huh?\r\n" end end } end rescue Errno::EAGAIN, Errno::EWOULDBLOCK retry rescue IOError end As you can see, it's little more than a chat server with a bit of flavor. Anything beyond this is really getting into the mechanics of your specific MUD. Try looking up chat server examples, sockets in general, and general game design and you'll likely find a wealth of information you can use in the process of writing a MUD server. [Edited by - Puck on January 20, 2009 1:23:02 PM]
  9. Puck

    library headers directory structure

    the way to solve your problem without altering any files is to include "C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\al\" in your include search directories list. I'm not familiar with Visual Studio, so you'll have to consult the documentation or someone else for the exact process, but that should point you in the right direction. Essentially the idea is that when you include a file, the compiler takes a list of directories and searches for the path you specified in each until it finds the file, and spits out an error if it exhausts the list without finding the file, which is what's happening here. The compiler sees your include of "al/alut.h" and goes through its list until it finds "C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\al/alut.h", then it processes that file and finds the include of "alc.h", whereupon the compiler starts over at the beginning of its list, but it can't find "C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\alc.h" so it spits out an error. If you add "C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\al\" to the directory list, the compiler will, in perusing its list, check for "C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\al\alc.h" where the file actually exists.
  10. Quote:Original post by sofakng Why does it matter how the objects move? Perhaps you're making a platform game and your sprites never rotate, do you still send rotational information? What if most of your objects behave normally, but one certain type of object only needs its initial state and a deterministic simulation handles the rest? If it's a two player competitive network game and the data doesn't match up, who has authority? Would that solution be fair or practical in a different type of game? As I said before, such a solution would be inefficient in terms of bandwidth as best, and have gameplay side effects at worst. Networking really has to be tailored to each individual game to get good results, there just isn't any way -- at least that we know of -- to create a solution that just works for many different types of games.
  11. Game Maker does something similar to you're talking about, but in general that kind of thing is nearly impossible to implement well. Every game utilizes the network conenction in a completely different way, so creating a general purpose solution is at best highly inefficient in terms of network traffic and at worst affects gameplay or visual appeal -- extrapolates when it shouldn't, doesn't when it should, etc. 2d sprites may only have a position rotation and velocity, but that move in a wide variety of ways, sometimes even within the same game. It's impossible to account for all the methods of locomotion and various contingencies in a sensible manner. Not only that, but it's often more efficient to synchronize based on input rather than variables like position and rotation, especially in anything more action oriented than an RPG. Honestly if you look there are probably libraries out there that attempt the kind of thing you're asking for, but they're unlikely to be practical in most applications.
  12. Puck

    flash 8 actionscript help

    Assuming I understand you correctly and everything you say is true, I believe what you want is this: if (_root.answer == _root.correct){ result.text = "Good job!"; } else { result.text = "Wrong!"; } In actionscript it's possible to set an instance to an arbitrary value -- in this case a string -- but it's probably not what you want. Rather you appear to want to set the text property of a dynamic text area. That's just a guess though. If that doesn't solve your problem you might try asking on a dedicated flash forum, there are plenty out there.
  13. Puck

    LAZY MAN WITH AN IDEA

    Quite frankly, I doubt there has ever been a case of a game development company adopting an idea from outside. Most game development companies are started for the purpose of developing a specific title, and then move on to sequels or titles with similar themes. The chances of getting your idea developed by a company with the resources to license rights to develop for something like the Wii -- especially without experience -- are zero, or close enough to call it that. I'm going to be brutally honest: You're looking at nearly insurmountable odds. The chances of you ever playing your game as things stand now are very slim. With that said however, if you're really intent on seeing your idea become a reality -- and I do mean really intent -- and are willing to invest most of your free time in it there are ways. I suggest you read, read and read some more. Learn everything you can about game design, and game development as well. See if your idea stands up to a rigorous examination based on the principals of game design, and if you're still sure that it's a genuinely good idea then you just might be on to something. Next write down every thought you have related to your game idea, organize them all, and write a design document. Modify your idea into a PC game, keeping in mind that the Wiimote has been adapted for use with the PC. Read the design documents to yourself a few times and make adjustments as necessary, then find someone to review it; Right here at GDNet wouldn't be a bad place to look. Once your idea is documented and proven viable in the eyes of others, then you can start assembling a team with the skills that you don't have. Conveniently GDNet also offers a service specifically for that purpose. This step will be your trial by fire, but if you can get enough people genuinely interested in your idea, then you've got a pretty decent chance of success. But don't think your work is done yet. Once you have a team it's be your responsibility to ensure that everything runs smoothly, which may be trying at times. If someone quits for any reason, for example, it's up to you to fill the void in whatever way you can. You'll have a lot on your shoulders, but if you stick with it you'll be well on your way to a finished product. If all that sounds like too much, then I'm sorry to say it but you're probably better off to accept that you're just another average Joe with an idea, and forget about the whole thing. It's unfortunate that so many great ideas get passed by, but the simple fact of the matter is that there aren't enough man hours to develop every game idea out there. In the end it's only the ideas by the people with enough money or motivation to see them through that get made, so you need to either be one of those people or give it up. [Edited by - Puck on January 15, 2009 5:51:01 PM]
  14. Among the choices presented -- C++, C# and Ruby -- I would suggest C#. It's easier than C++ to pick up, yet relatively similar syntactically, which would make switching to C++ later easier if it becomes necessary for performance or portability reasons. Ruby is a real dream to work with, but with the current set of libraries I wouldn't recommend trying to write any sort of graphical game in it; it'll likely end in disaster.
  15. Puck

    Java or C++ (games)

    Your unbiased answer is: neither. Your question is far too general to answer with anything other. C++ and Java are both viable languages for writing games, along with many other languages -- even the dreaded P word, as much as I hate to admit it. [wink] The real question is what you have and what you're looking to achieve: what language features are important to you and your project? C++ offers speed and flexibility at the cost of simplicity and safety. If you want to play around with writing pong or breakout then C++ is a fine choice when paired with something like Allegro, SFML or SDL as it will give you experience in a widely used language that could benefit you in other ways. Conversely if you're the one man army type and want to make your big MMO idea a reality, then Java is probably a better choice, since it'll give more and ask less on a one man team. In summary, neither language is inherently better than the other, thus the endless debates. Just remember to pick the right tool for the job. [Edited by - Puck on January 14, 2009 7:16:36 PM]
  • 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!