• Content count

  • Joined

  • Last visited

Community Reputation

10976 Excellent

About rip-off

  • Rank

Personal Information

  • Interests
  1. Nobody Wants A Cybergod?

    The description about missiles, being the most concrete description given so far, is interesting. While I've not played the game, so I can only speculate, it sounds like such an approach has the potential to add additional mechanical depth to such a game. Now, to play devils advocate against such an approach. from your description it sounds like it takes power away from the player and gives it to the ship "captain", which may not be ideal. For example, imagine the ship in question is likely to be destroyed shortly - perhaps the player would rather the missiles be fired now while the ship is definitely alive rather than gamble on whether it gets to the "perfect" attack position. Or perhaps the player has a different goal in mind, maybe they want to feint an attack for some reason, hoping to distract or panic the opponent (assuming multiplayer). Off the top of my head, and bearing in mind I've not played the game in question, another approach might be to make it easier for the player to co-ordinate attacks between multiple ships, rather than to try automate this for them. This might feel more subjectively fun approach, the player feels like they've executed the tactics rather than issuing an order and watching the game "play itself". In any case, it is very important to realise that the lack of intricate details is not a flaw in a game. The fact that the game chooses a simplistic modelling of missiles is likely an intentional choice. The designer may be trading off such depth for other goals like shorter play sessions or reducing the complexity to achieve a broader appeal. That is not to mention the production difficulties like trying to integrate many competing features in a balanced and accessible fashion, or simply the commercial necessities of completing the game in a given timeframe. Incredibly detailed simulations exist (e.g. Dwarf Fortress), but they are a niche. In contrast, if you look at ancient games with relatively simple and abstract rules. like chess or go. They're deep game in a different way, ones you can play for a lifetime. Their lack of detail is not a limitation, their enduring popularity attests to this. Maybe you've got a decent idea, but that shouldn't take away from the many developers designing different games and being successful with it.
  2. Nobody Wants A Cybergod?

    It is easy to write a design document, even one that is not possible to implement, at all or with acceptable fidelity / performance. From what you say, I think it may be the case that you are unaware of the infeasibility of your ideas. For example, simulating reality at the sub-atomic particle level is not a new idea, the reason nobody is making games like this is that computers are not powerful enough to simulate a non trivial number of particles. Consider that the most powerful supercomputers are needed to approximate weather forecasts, and they don't try to model at the level of particle interactions. Then consider how imperfect the results of these predictions are. You're talking about people with obscene amounts of resources, have you really solved problems that they haven't? I may be wrong, because you haven't described your idea in sufficient detail, but I infer that your idea is basically some kind of game / physics engine. I think you believe the ability to predict where the game objects will be in the future is somehow new, which it is not, and will that it would improve game A.I. to make use of this. A.I. can already try to predict the future, if the designers so choose. Any limitations you feel in computer opponent intelligence is likely due to the difficulty in actually making use of the resulting data, it is not due to a deficit of imagination on behalf of the designers to try this. For example, a key difficulty is predicting how the human player will react as events unfold. It would be one of the biggest breakthroughs (technologically and philosophically) in history if you or anyone could solve this. The goal of games is to be fun. Perfect A.I. is not fun - how much fun would it be to play chess against a computer that can beat any grand master? See "playing to lose", an excellent video explaining some of the decisions behind the Civilisation computer opponents. Sure, there are players who crave an ultra realistic game with incredibly difficult A.I. - but it is a niche, it is not the "Holy Grail" you claim. In summary, ideas are easy, execution is the hard part. If your experience hasn't taught you this... p.s. "Rube" seems like a terrible name for any project, much less one as revolutionary as the one you claim.
  3. I've hidden some more unhelpful replies. To Asokanta, this is not a real time chat. Please have patience and wait for a reply. Also understand that we're not here to write your code for you, but to help you learn how to write your own code. To others, please bear in mind that Asokanta is relatively new to this and what might seem like a straightforward suggestion could be confusing or not very obvious. All future replies should be respectful and on topic. Failure to follow these instructions will result in moderation action being taken.
  4. In your updated code, you have not declared a global variable "Z2". It is not clear to me whether you really want to introduce a new global variable, or whether you want to update one of your existing variables from the configuration settings. In general, setting a global variable is done like so: #include <iostream> int global = 13; void changeValue() { global = 42; std::cout << "Changed value: " << global << std::endl; } int main() { std::cout << "Starting value: " << global << std::endl; changeValue(); std::cout << "Updated value: " << global << std::endl; } If you want to declare a new variable, then you need to add it to those globals like you have done for the others. The other thing to be careful of is to not declare a local variable with the same name: #include <iostream> int confusing = 13; void changeValue() { int confusing = 42; std::cout << "Changed value: " << confusing << std::endl; } int main() { std::cout << "Starting value: " << confusing << std::endl; changeValue(); std::cout << "Updated value: " << confusing << std::endl; } If you run this, you'll notice that the global has not been updated. This is because a new variable with the same name was introduced in "changeValue".
  5. I've hidden some negative comments that weren't helping. Please, be respectful and understanding of one another.
  6. Can you show us your current code, after you tried making the variable global?
  7. Try Catch Statement Question [2]

    You are partially correct, many exceptions can be avoided by placing explicit checks instead. In the example you quoted, catching a FileNotFoundException could be considered poor style (abusing exceptions as flow control), an alternative approach would be to check if the file exists explicitly before opening it. However, as Kylotan mentioned, exceptions can still happen - in your example, even if you manually check whether the file exists, there is a "race condition" between the two steps - maybe the file is on a network share and the Wi-Fi suddenly drops! Another source of exceptions can be misunderstanding the code. When the codebase becomes large, and the team working on it grows, it can happen that two pieces of code with differing expectations can interact. For example, maybe one module was written with a strict policy of no "null" references being passed or returned, but another module allows null. If someone who doesn't remember this fact is writing code on the boundary of the two modules, they could pass "null" references into code that isn't prepared to handle it. This can happen even as a solo developer, with enough time passing the code you wrote a year or more ago will feel like it was written by someone else! Given that exceptions can occur despite your best intentions, it is very common in Java programs to have a high level try ... catch statement to handle all unexpected exceptions that were thrown, and try to show some kind of error report to the user. Even if you're quite thorough in trying to avoid exceptions, once you release software into the wild world someone will eventually break your program, so having a way to capture the error so that the user can submit a useful bug report to you can be quite useful. A related issue is throwing your own exceptions. Obviously, you have limited choice when it comes to exceptions that the language, standard library or crucial third party libraries might throw at you. It can be a quick way to "bail out" of an operation, but overuse of exceptions can make the program difficult to reason about and can contribute to requiring catch blocks to handle them. Whether to use exceptions over return values is somewhat of a philosophical question. I would say that try ... catch is a useful construct, but one that you should try to use sparingly. If you find yourself using it often, consider whether there is some other way to avoid the error in the first place. Note that try ... finally is a different construct, you should not worry about using that where necessary. My advice would be to avoid throwing exceptions, but don't be afraid to do so when the alternative would be worse. They are particularly suitable for handling programmer error, where something is wrong with the internals of the program, for example a critical array is empty but it should never be. An example of this kind of usage is the "assert" keyword, which can result in an AssertionError being thrown. Trying to handle all unexpected situations with return codes can lead to lots of complexity, because "unexpected" errors can happen in lots of places and you would need to propagate this error to every caller.
  8. Again, watching a video is a different experience from actually playing the game, but looks like a big improvement to me - well done! Just the movement alone looks way better, it gives the entire thing a different feel I think. Is the game playing a bit more like what you were looking for now? A potentially simple thing to look into is toning down or changing the particle effect when somebody is hit - it looks a bit like an explosion at the moment. I'm not an animator, but the sword attack animations look like they could use some attention. That said, I would also say that the player's kick attack looks more dangerous - where it looked a bit too weak before. Have you playtested the game with anyone? Would it be hard to package up a demo? Soliciting feedback about videos, while better than nothing, will tend to result in a focus overly on the visual impact and will not give you as much insight into the interactions. As an example, imagine if people could have given feedback on Tetris during development. The game is aesthetically simple and arguably even boring to watch, but actually playing it is a different experience altogether! But the feedback Alexey Pajitnov might have gotten would not have been about gameplay (e.g. the ability to commit a shapes position and drop it immediately), but rather would naturally be on the more superficial elements. Finally, remember we lack a lot of context about the game. I don't know if this is the only mode, or if there might be others. I don't know what kind of enemies you're thinking of having, nor what kind of levels and level elements. Will there be multiplayer? I don't even know whether it is a purely action game, or if there might be other aspects (e.g. stealth mechanics). Fleshing out your vision might help us understand what you're aiming for and whether that is coming through to us.
  9. You can change the feel of of a game without altering the fundamental mechanics by polishing how the game responds to your actions. I found this video very good: As for your game, hard to say without playing it or seeing more. The player in question isn't doing very well, which makes the game look less fun than it might actually be, if they were slicing up opponents without taking a hit I'd say the opposite...
  10. Search module for string?

    Can you explain what you're trying to achieve? Is this something that you might be able to pre-process during a build, or is it something you want to be able to dynamically detect at runtime?
  11. C++ / OpenGL Particle Generator help

    Excellent observation, that is indeed the sequence of IDs that you might expect, that you see a deviation is significant. 3452816845 is an interesting number, not by itself but rather because many of your variables seem to have this value. Googling it gives me, which reveals that the value has a special meaning: (I knew about this already, but this shows how you might investigate yourself).   So what is happening? This example program might illustrate: #include <iostream> #include <vector>   struct Foo {     Foo() {     std::cout << "Constructor for " << this << std::endl;   }     ~Foo() {     std::cout << "Destructor for " << this << std::endl;   }     Foo(const Foo &other) {     std::cout << "Copying " << &other << " into " << this << std::endl;   }     Foo &operator=(const Foo &other) {     std::cout << "Assigning " << &other << " to " << this << std::endl;     return *this;   }   };   int main() {   std::vector<Foo> v;   std::cout << "Before insertion" << std::endl;   v.push_back(Foo());   std::cout << "End of main" << std::endl; } If you run this, you'll see something like: Note that a Foo object was created, copied and destroyed during the "push_back". This is the lifecycle of the temporary Foo() instance. The copy lives on in the vector, and is destroyed after the last line of main(). It looks like your Particle class is more complex than it seems at first, it has complex inner types. The question is really whether these complex inner types can be copied and / or assigned. Remember the [url=""]rule of three[/url], which is that any class that has a destructor should probably have a copy constructor and assignment operator (leaving aside move for the moment), or be "non-copyable", which can be done (in modern C++) by deleting the problematic functions (to prevent them being automatically generated), or simulated in older C++ by declaring the functions private and leaving them unimplemented. Generally you do not want to implement copying semantics for external resources, such as textures that reside on the graphics card. Not only is it tricky, but also it is likely to have performance issues. You don't generally want to have lots of distinct copies of the same texture on the GPU, that is just wasting memory and wasting time switching between textures. I'd recommend changing your Texture, Vbo and Ebo classes to be non-copyable. Once you do this, code that attempts to insert Particles into the container should stop compiling. I was never much of a graphics programmer, and it has been a long while since I've dabbled, but my guess would be to think about managing the textures and related objects at a higher level than the particles, for example the emitter could manage these resources. Particles should be as lightweight as possible, managing GPU resources is the opposite of this.
  12. C++ / OpenGL Particle Generator help

    Indeed, most programmers would write "i < N" for loops that should run N times, rather than i <= N - 1. It would be a good idea to do this consistently from now on, to prevent such bugs. Now, it sounds like you've discovered something very interesting from a debugging perspective, which is you have two versions of the program, one of which behaves as expected and another which does not. As Lactose says, you can start running the two versions and comparing the various variables involved. Keep the number of particles small and it might be easier to debug.
  13. C++ / OpenGL Particle Generator help

    Progress, excellent! So, take another look at the code: void Emitter::Draw(Shader &shader) {     for (int i = 0; i < particles.size() - 1; i++)     {         particles[i].Draw(shader);     } }   void Emitter::Update(GLfloat dt) {     for (int i = 0; i <= particles.size() - 1; i++)     {         particles[i].Update(dt);     } }   void Emitter::SetParticlesAttributes() {     for (int i = 0; i <= particles.size() - 1; i++)     {         particles[i].setLife(10.0f); //(((rand() % 10) + 1) * 15);         particles[i].setVelocity(glm::vec3(0.0f, 2.0f, 0.0f)); //(((rand() % 10) + 1) * 2));     } }   Can you spot any reason why Draw might not draw the last element? In particular, can you see any differences between the Draw() function and the others?
  14. C++ / OpenGL Particle Generator help

    So that is a good start! There is more narrowing down to do. Here are some examples: * Have you tried an emitter with just one particle? * Have you tried two particles without the emitter? * Have you tried making the particles stationary?
  15. C++ / OpenGL Particle Generator help

    Tell us what you have tried. I see you have a few other similar topics, the pattern is that you get blocked and post your full program here, looking for someone else to spot the problem. This approach is inefficient. You need to wait for someone to spot your error, which is a waste of your time. Also you have different people reading large amounts of code every time, as you cannot narrow down the source of the issue. A better approach would be to invest some time into learning how to debug these situations for yourself. For example, in a recent thread you were strongly advised to add more error checking code. Start there, before you do anything else. Part of this is learning to use your tools, such as a debugger. As a beginner, I remember finding the debugger rather intimidating so I learned to use "printf debugging", which is basically inserting print statements at different points to allow you to understand how your program is running and what values different variables might have at the time. While it is worth your time investing in a proper debugger, even using printf debugging you'll be able to find and fix many bugs. There are techniques to speed up debugging, for example disabling portions of your program so you can focus on a smaller part and checking that for correctness. For example, start by checking that a single static particle will draw as expected, before enabling multiple particles and movement.