• Content count

  • Joined

  • Last visited

  • Days Won


Alberth last won the day on September 11

Alberth had the most liked content!

Community Reputation

9534 Excellent

1 Follower

About Alberth

  • Rank

Personal Information

  • Interests
  1. Ok. I don't write games in Java, but I know of two Java libraries that are listed in this forum quite often. One is LWJGL which you already mentioned. The other one is LibGDX The simplest way to get started is to do the tutorials of these libraries so you can get an idea of how they work. If you don't insist on using Java, then C# with Unity might be interesting too. C# isn't that far from Java, and Unity is a much larger framework, which means you have to write less code for doing the basic things. (However, also with C# and Unity I have no experience.)
  2. Become filthy rich, and hire a thousand developers for a few years would do the trick. If it's just you and you have no money, and no knowledge of all the things you want to use, it's about a decade of work to get this at professional level, which gets you in the position that you understand how to build such a thing. By then however, you fully realize I wasn't joking about becoming filthy rich and hiring a thousand developers for a few years. The MMOs of the world really have budgets of millions of dollars and years of work by a zillion persons. You'll never get there on your own. If you, despite this setback, are still interested in learning to program, I'd recommend to learn the entire Java language, and make many small games, starting with something simple like Pong. Then move on to more complicated stuff like Tetris or Space Invaders. From there you can do Pac man or a platform game. After that, you more or less understand how Java works in basic games, and can move on to other stuff (though other 'stuff' than what you intended in your question, I think).
  3. I think your basic premise of Sword and Rifle belonging in the same class hierarchy is wrong, or your Sword definition is wrong, or your Weapon definition is wrong. The simple solution is to unify how a sword and a rifle work, by adding a Reload method to the Sword. It's a silly thing in terms of reality, but we're not interested in reality modeling, we're writing a game. This unifies both weapons, and your entire problem disappears like snow in the sun. The second option is to acknowledge they're different weapons. The game character does something different with a Rifle. The simple solution is then to make them truly different things, each in their own hierarchy. This is not different from not having Money in the same class hierarchy, even though it could be used as a weapon (bar of gold dropped from a 10 story building can severely damage you!). Your Strategy acknowledges the weapons are different, and then you add another layer of software that hides the difference. You make new instances of the strategy class that basically encodes how to handle each type of weapon, inside the weapon itself. In other words, your current notion of Weapon is flawed, and to correct it, you add a wrapper layer around it to unify the interface? Is that not equivalent to unifying to a new weapon class that just has a "useIt" method and nothing else? The Reload becomes a hidden implementation detail. Wouldn't it be simpler to just ditch the Strategy, and make a simpler Weapon definition where you directly encode the weapon behavior, where Reload could be a private sub-function of Rifle.
  4. Python code review for Snake

    Copied the files, and added comment, start with the input manager, as I refer back to that from the game comments. (see bottom of the post for the files). I agree, dicts look like cheap classes, but accessing fields looks messy. Also, there is no useful place to document what variables exist, and what they do. Ah, ok. I agree that recursion is only useful if you have recursive data structures, so running into it is indeed dependent on the kind of problems that you usually solve. In this case, it's mostly just obfuscating intention, so better remove it. Function names are pretty good, just a bit long-ish. Documenting data and data flow is at least as important. Allowed values of all variables, and their meaning, and input/output relations of functions is crucial in avoiding problems. As you seem to favor heavily fragmented function (a zillion functions of a few lines), some way to document the global picture would be useful too, as there is no single one page function that shows that. I think it would be useful to try having less functions. You're almost using a function as a one line comment description above a block of lines now. No idea, it does give you that authentic feeling doesn't it? Some stuff to ponder is the problem of deciding which key the user pressed last. Right now the result depends on your order of processing, rather than me pressing keys in some order, I think (but didn't quite check). You can of course also consider faster updating of the game screen, which makes things move more smooth. Maybe something for a next game? I am a non-believer in unit test code for anything you can easily find out in the first use, so I'll pass on this one.
  5. Learning Making my First game

    An article that is often helpful to get some initial answers below. I agree with yyam, start small, probably smaller than you're thinking now. Programming expands very quickly to the point of overwhelming, so better err on the too-small side
  6. Advice Youtube tutorials/Online courses

    You typically learn most by trying stuff yourself. Videos tend to look simple and logical, since they skip or avoid all the traps you can fall in. Be sure to practice a lot!
  7. I don't understand the difficulty that you have, aren't you just over-thinking stuff? I mean class Writer { ... void WriteInt(int n) { Store((const char *)&n, sizeof(n)); } void WriteFloat(float n) { Store((const char *)&n, sizeof(n)); } // etc void Store(const char *base, size_t sz) { for (int i = 0; i < sz; i++) // store or write base[i] } } struct SomeStuff { int a; float b; void Write(Writer &w) { w.WriteInt(a); w.WriteFloat(b); } } Make a Writer class that has a function for each type of data, for each structure you have add a "Write" method that writes self to the Writer. Reading is just the other way around, you have a Reader class with functions that produce various elementary values, and each struct has a Read method that assigns fields in the same order as the Write method.
  8. Again Inclusion question

    Simplest form is to create them inside main(), and pass them around as needed. You could make a class for them, so related variables are close together. It's not a real global, but you have much more control over them, and you have to make explicit that some code relies on them, which will one day help in refactoring code (ie avoid the case that you got all parameters, and then find out code also has a huge number of dependencies on globals you completely forgot about.)
  9. Meaning of data in a file is known under the name "file format", or "file specification". In your case that ended (for me) at wikipedia which lists two URLs describing the format unofficially, which is likely the best you can get given the closed format. I ihaven't read those URLs, but if it is known, it's likely there. If that description does not describe your 1 and 2s, the only useful remaining source is the owner of the file format, ie AutoDesk which is probably useless to even try. As a possible alternative, maybe you can export to an open standard file format instead? That solves your problem instantly, as such formats are publically available.
  10. Wierd bug

    Code you posted seems fine at first sight, 842150923 is 0x3232340b in hex, which is not near any limit. Since it's not happening at first, I am going with accessing non-existing data (eg accessing a piece after it got deleted). For example, in your m_pieces vector, do you remove anything from it? If you do, do you delete the data (not related to this bug, but important to do right)? Do you ensure you cannot access that old data any more? As a test, you could fill all values of a piece with a known and unused value just before you remove it, and then remove the piece (eg in a destructor). Since those values are in removed data, you should never find them in your live data. If you find those values in your live data, you know what the problem is. Sadly, if you don't find those values, it does not mean you don't have this problem. Code-wise, how you remove and add a piece to m_pieces could be interesting, along with how you decide which elements contain live data, although your PlayState::update suggests everything in the vector is live data. You could consider posting the code eg at github or some other site, which works better for larger code bases. Edit: 842150691 is 0x32323323, which also has lots of 2 and 3s. Maybe it's text? thus 0x32323323 -> 32 32 33 23 -> "223#" 0x3232340b -> 32 32 34 0b -> "224." (0b is not a printable character) So yeah, garbage data you're reading, likely from a previous program that used that memory
  11. Don't you give an answer yourself here? Being non-standard means "not for standard built-in types" doesn't apply. As for performance stuff, no clue, I typically don't go that close to the edge where such details matter. It takes too much time for too little benefit.
  12. Why would it be weird, you add one interpretation of binary + to the available set of options. You can define overloading on any operator with any known type (in any combination). The main reason why this doesn't happen, is because overloading an operator is surprisingly ambigious, in the sense that users (ie us), have a surprisingly difficult time in correctly understanding the meaning of +, in particular if you didn't program the overloaded operators yourself. There are often several "+" interpretations which are all equally valid to chose from. For this reason, it is often better to use a name rather than a symbol for describing the operation. Other languages have gone as far as not allowing operator overloading at all, which makes sense too, given the few useful opportunities that are valid cases.
  13. C++ Text Adventure Design

    Instead of hard-coding an action, make it an object (this fits in data-driven thinking). Each room has a list of actions that you can do. You'll have several such lists, depending on what's around. The room itself can have one, each object in the room can have one, your inventory items can have one, a NPC can have one, etc.
  14. It can't paste correctly in all cases. TAB length isn't copied with the text, so either it guestimates, or it just happens to use the same length as you have. In both cases, you can break the formatting with a clever enough example. I don't fully understand this, I basically just needed to pass around width and height so that I can spawn my Entities like so(code below: This means that if two numbers have a width and height relation, you can discuss other properties, eg "area". You can multiply 2 unrelated numbers, with each other, but without a width/height relation between them it has no useful meaning.
  15. It is, a TAB character is defined to aligned at multiples of 8 characters, in ASCII. Most editors ignore this definition, and allow you to change it, giving the illusion that a TAB is whatever you configured. That of course fails as soon as your file leaves your editor, since other programs or other people use different TAB settings, or use the official size.