Wuntvor

Members
  • Content count

    168
  • Joined

  • Last visited

Community Reputation

170 Neutral

About Wuntvor

  • Rank
    Member
  1. That's a pretty stupid requirement if you ask me, but if you absolutely have to do this, the easiest way would probably be to just put it into an array. Of course, whatever library you are using has to support loading wav files from memory. Then you'd just to something like this: const unsigned char music[] = { 0xFE, 0x12, ... } You'll definitely want a program that generates this for you (I'm sure you'll find something on the net). Hope this helps.
  2. C++ or C#?

    The one thing that C++ has going for "amateur" game developers would be the amount of existing libraries, in my opinion. This is actually much more important than speed, because the one thing I am concerned about the most when I'm working alone is to get things done. Sure, there are some game oriented libraries for C#, but their number isn't really high and a lot of them just aren't mature enough yet. So, basically, I end up implementing a lot of stuff myself in C# that I wouldn't in C++. On the other hand, implementing something really is a lot faster in C#, so it really depends on how you want to work. Do not give in to the lure of speed and being "closer" to the machine. It is (besides the libraries issue) the one thing that always draws me back to C++, but I've found that I am much more effective with C#, and that is more important than having a 10% more fps.
  3. C++ vs C#

    There are really a lot of factors involved. For example, writing it in C++ may actually turn out easier as there are a lot more libraries ready to be used, while in C# you'll still have to do a lot by yourself. Sure, this'll be easier than doing the same in C++, but it's still work and if you don't like to do basic things yourself, I'd actually prefer C++ for this reason. Other than that, I'd say C# will probably be better in the long run, as it is a lot less complicated and makes code a lot easier to maintain, in my opinion (as it's easier to write good C# code than good C++ code, in my opinion).
  4. Quote:Original post by Wuntvor So, in my opinion, it should really be something like Stack->Current->Update() or whatever instead of Stack->Update(), to reflect this. If you feel this is too cumbersome, I'd still derive it from GameState, as it is no more wrong than not deriving. But then, I am not that good at designing classes, so I might be completely wrong about this. :) Guess I'll quote myself here.. I just wrote a simple implementation of this, and it appears a lot cleaner to me than my previous implementations (when I did have Draw() and Update()-methods directly in my Stack). Also, the more I think about it, the more I think that having those inside the GameStack class is actually not logical at all. Why would a GameStack have input(), process() and output() methods? Do I want to output() the GameStack to the screen? No, what I actually do want to do is retrieve the current GameState and output() that to the screen. Sure, it may seem more convenient to write Stack->output(), but that should not guide us in making decisions like this, in my opinion. One more thing I have been thinking about: Are Init() and Exit() methods actually important? It doesn't really sound that useful to me. The GameState may care when it becomes active and when it stops being so, but why would it care about being inserted or removed into a GameStack? Actually, I'd argue that GameState shouldn't know at all about GameStacks but should rather be independent from it. If Init/Exit is included so that resources can be managed, I'd argue that these should be loaded at construction of the object (or in the Enter event) and freed at destruction (or in the Leave event). Otherwise, it may be initialized several times (if it is inserted again after having been popped) which isn't very intuitive at all. Okay, I'll stop ranting now!
  5. Obviously, in a perfect world, you'd simulate the whole match like FM 2006. However, this is really really out of league for a web game like yours, so you'll have to come up with something simpler. One problem with the "take the result and build the game scenes around it"-approach is that it becomes rather meaningless, at least as soon as the player realizes this. In the end, it'd still be down to a game of numbers, as all you could do with your decisions would be to optimize your number. It is hard to get around, but it has totally destroyed more than one manager game for me. What might be worth a try would be using text for description of the matches. You could have chances, and depending of the skill of the player with the ball and other players interacting with him, his skills would actually mean something. For example, say we had randomly decided that Player A who has the ball is tackled by player Y, then you could now compare the attributes of these players and determine the odds of each player winning and go from there. It might still become quite complex, depending on how much variation you want in the game, but I think it might be more interesting. I think there is actually a (german) web football manager which does it like this, but I can't remember the name right now. I think this is a pretty good compromise between the two, because it still offers the possibility of actually creating meaningful situations without having to simulate all of it. It is still pretty complicated, though, so depending on how complex you want the game to be, it might be too much.
  6. Nice, I have done something like this as well, so I thought I'd give some comments as well. As to Enable/Disable methods, I think they actually have a lot of uses. For example, you may not want to keep all resources around at all times, so you could free them up when you lose focus. Or you could use it to hook up to input events when gaining focus and disabling it again when losing focus (not necessary if using your input-mechanism, I know, but if using an event-based system it might be useful). Also, in my opinion, having GameStack derive from GameState might actually make sense if you see GameStack not simply as a container for GameStates but rather as representing the current GameState. Actually, it sounds as if the problem with both approaches is that the class is in the end doing two things at once: It holds GameStates and it represents the current GameState. So, in my opinion, it should really be something like Stack->Current->Update() or whatever instead of Stack->Update(), to reflect this. If you feel this is too cumbersome, I'd still derive it from GameState, as it is no more wrong than not deriving. But then, I am not that good at designing classes, so I might be completely wrong about this. :)
  7. Quote:Original post by RDragon1 On the other hand, the new C++/CLI stuff makes it easy to use .NET libraries in primarily native C++ applications. I, for instance, use some interop with .NET to use ADO.NET in my C++ application, as I was pretty dissatisfied with other database API's... It's pretty easy to interface between managed code and unmanaged code, so it shouldn't be too hard to get performance-critical modules written in whatever is best to write them in, and write the logic driving and such in a managed language, if you want. Personally, i'm much more productive in C++ than in any other language, and because of that I prefer it. C++/CLI only makes me more productive. Exactly.. I have just started a basic wrapper of ClanLib using managed C++, and it's really coming along nicely. Indeed, the only thing that has kept me from writing a game in C# has been the lack of good libraries, especially for 2D (from what I have seen, there is pretty much just SDL.NET, which is alright, but I'd rather have something based on 2D in 3D stuff).
  8. Advantages over Lua?

    I really like how easy it is to bind my code to AngelCode. There are excellent libraries for Lua, I have to admit that (for example luabind), but that's another layer in-between that can add complexity at times. A big plus compared to luabind for me is that the code is generally pretty understandable, which can't be said about all that template-magic in luabind (plus, compiling doesn't take hours for the same reason). If you already have a game running, I am not sure if it would be worth it to change that now, but otherwise I have found that AngelCode has been giving me a lot less problems, most of the time it just works.
  9. Quote:Original post by Anonymous Poster Quote:Original post by Anonymous Poster What about apt-get install nvidia-glx? Or: emerge -av ati-drivers ati-drivers-extra Telling people that installing software on linux is hard, is telling them you run a distro that is 5 years old. Yeah, until you realize that unfortunately you are running a kernel version for which ATI hasn't supplied new drivers yet, so either you'd have to apply some obscure patch or switch back to an older kernel. Happy times. :) I admit I was probably very unlucky to try and install it right at that time, and part of that is ATI's fault, too, but things like this have happened several times when I tried to install graphics drivers in linux. Really, I have tried to install several different distributions on my computer, and oftentimes I did end up with a lot of different problems. None of them could simply be solved by running some GUI program, if there was a solution available, most of the time it required editing some configuration files. Now, for me, that's okay, but if this had not been my computer but rather that of a family-member, I would have despaired trying to tell them what to do. On Windows, it's mostly just "Click on this, click on that, set that to this" etc., which is pretty easy to do. I mean, sure, if you get it up and running, Linux does work rather well and it has improved a lot over the years. It is at a point where I would actually consider installing it for someone else. However, I really can't think of many cases where it would be superior for desktop usage, except maybe the amount of applications that come with each distribution (but if Microsoft would be doing that, I am sure they'd be looking forward to a nice lawsuit). That, and Amorok, which I would really love to have on windows. :(
  10. 2D .NET Game library?

    Quote:Original post by Arydrall This raises an interesting question. I originally thought that the general slowness of PyGame was because of Python itself, not because of SDL. Soooooooo, which is it? Granted, this question is coming from a complete newbie, so I don't really know what the slowdown is. (besides, y'know, the virtual machine bit that Python implements) Thanks! :D Actually, it is both, as far as I know.. The problem is that rendering to the screen is pretty slow with SDL, at least a lot slower than using OpenGL for 2D stuff would be. It's not that bad, however, as long as you don't do anything too fancy (such as rotations or zooming or the like), it will probably be enough. Now, PyGames problem is this and additionally the slowness of Python, and combined it means you have to be very careful only to update those parts of the screen that need updating.
  11. Please help me I think I did this wrong

    The way you do it, it'd work too, but you should call it like this: Hp=HpUpgrade(Hp); This, or just make the function like Drew_Benton mentioned: void HpUpgrade(int& Hp) { Hp+=1; } Hope this helps. Edit: Seems I was a bit too slow :)
  12. Ever heard of Google? Really, maybe you should try a bit harder to solve problems by yourself, at least looking at your posting history it seems that way. BITMAP bm; GetObject (_hBitmap, sizeof (bm), & bm); width = bm.bmWidth; height = bm.bmHeight; This is what I found somewhere with google, I haven't tested it but it should be correct.
  13. Casual Games. Target Hardware, Best Lib?

    Well, if you want it to work on older computers, it'll probably hard to avoid something like SDL or DirectDraw or something l ike that. Performance would probably be quite okay with some precautions taken, but forget about things like alpha-blending. However, I'd still go for an OpenGL/D3D-based approach. On all somewhat modern systems you are going to get much better performance and a lot more features as well. Basic 2D stuff shouldn't tax the graphics card too much, and I doubt it'd be worth it to support systems that are too old to have some reasonable 3d acceleration. Basically, your game would both look and perform worse on a somewhat modern computer.
  14. std::map is driving me insane!

    Hm, I am not sure if you should be modifying the map at all while iterating through it.. I am actually surprised that it works if you exchange those lines (all I know is you can't modify a collection in C# while iterating through it, which is kind of the same thing). After all, if you erase the current item, what is the iterator pointing to? Personally, I'd just iterate through it, clear up the resources and then clear the map afterwards. EDIT: Yeah, CoffeeMug put it better than me. :)
  15. Got a game? Love to review it!

    You should really spellcheck your stuff a lot better... "whether" != "weather", "squeal" != "sequel" etc. etc... I have just taken a look at the Games section, so maybe it's better in other areas, but it just doesn't look very professional at all. I don't like the style of writing either, but maybe that's just my personal taste. Other than that, the site is pretty nice, though.