Jump to content
  • Advertisement

frob

Moderator
  • Content Count

    11462
  • Joined

  • Last visited

  • Days Won

    15

frob last won the day on November 1

frob had the most liked content!

Community Reputation

45572 Excellent

About frob

  • Rank
    Moderator - Mobile & Console Development

Personal Information

Recent Profile Visitors

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

  1. Not all collections can be modified, and only some iterators are suitable for insertion. The standard library provides iterator types like insert_iterator and output iterators, which are being revised somewhat in C++20. There is also an inserter template you can use, with common adapters like front_inserter and back_inserter. With your container objects a and b, you could use std::copy( b.begin(), b.end(), std::back_inserter(a)); That will copy all the items in b onto the back of a. To test that out: { std::vector<int> a = { 1, 2, 3 }; std::vector<int> b = { 4, 5, 6 }; // Copy all the items in b onto the back of a std::copy( b.begin(), b.end(), std::back_inserter(a)); for(int x : a) { std::cout << x << std::endl; } } Output is all six values.
  2. frob

    License for a Game Engine?

    I get that impression based on the problems he had with each of the licenses and the questions he had: Combined, those statements lead me to believe his big fear is that someone will take his published work, improve on it, and leave him in the dust. With open source software, all the licenses not only permit that type of thing, but for some it is explicitly an incentive to continue producing the best possible code. The Free Software Foundation has four "freedom" goals with the GPL and other licenses, and this ability comes with the fourth Freedom. That is, anybody anywhere can can create a derived product, including marketing that product and charging a distribution fee for that product. They can do it without notifying you of their changes, nor incorporating their changes back into yours. The fourth freedom means somebody else can start with the same product, add features and modify features, and supplant the original creator as the leader for the product.
  3. Those FAILED and null tests are normal and commonplace. Good code is very defensive and checks for errors constantly. Unit tests ensure permanence, not correctness. Unit tests fail when the behavior changes. Hopefully tests are written in a way that verifies results were correct, but through history many unit tests were written that ensure buggy behavior remains constant. Exceptions are a fancy way to provide an alternative return path. They have their uses and some languages rely on them heavily. Since you're talking about C++ code, exceptions generally should only be used in truly exceptional conditions. Games written in C++ should assume that failure is always an option. Reads and writes can always fail, acquiring resources and always fail, anything touching external systems can fail. If you write code as though every function can (and will) potentially fail, your code will be more robust because of it. Exactly how you handle each error is up to the program's design. If you are creating a system, make sure your interfaces are designed that failure is always an option, so failures can be signaled properly upstream. If you decide that exceptions are the best way to signal those conditions, and you're comfortable paying the runtime cost of exceptions, they can be a viable solution. The most common pattern over the decades is a return value indicating success or failure through an error code. The C++ language is adapting more to push better developer behavior in validating success and failure with attributes like [[nodiscard]] in C++17, but even so, correctness and robustness are up to the individual programmers.
  4. frob

    License for a Game Engine?

    Then you're not ready to release it the way you're describing. One of the major purposes of those open source licenses is that anybody can take it, make it better, and release it as their own. Anybody can "fork" a project to create their own based on yours, adopting your work and building a new product from it. This seems to be the opposite of what you are describing as your goal. IP laws are much like a genie in a bottle. If you accidentally release it, it is impossible to recapture. This kind of thing needs a chat with actual lawyers who understand the licenses and can take the time to understand your exact needs. Most likely they will draft a license that exactly matches your requirements. If you want to forbid other people from taking your product and re-launching it, none of the major Open Source licenses will work for you.
  5. ^^^ This one. For the way you are describing, no, it requires permission.
  6. Yes, there is such a thing. Lots of artists make lots of generic cars. This is the part with the problem: A car that looks like a box on wheels is fine. You can make up your own designs from 1960's style to futuristic models. Do that all you want. Artists do that all the time, designing vehicles that looks like it belongs in the 1920s or 1960s or present day cars or future era flying cars. They can use reference photos to make them look like car of the era in general terms, made boxy or curvy or bubbly, made with tail fins or spoilers or other features of specific eras. But when the designs begin to resemble actual cars the people who own the rights to that design can have a problem. A car that brings to mind a Bently Flying Spur, or a Ferrari GTO, or a Toyota Corolla, even if it isn't an exact match, can be enough that those who own the design think there is a chance for confusion. The more similar they appear, the higher the risk of a lawsuit. If a game has one car that happens to look vaguely like a 1950's Buick that is a relatively small risk. If a game has 15 cars that look like the entire set of cars from 1957 from all the manufacturers, that is a far more substantial risk. Chances are good you cannot afford a lawsuit, even if a judge would ultimately decide they are dissimilar enough to not cause confusion or to violate any other IP law. There is ENORMOUS gray area. Much of trademark law is based on the likelihood of confusion. Lawyers can argue back and forth about if a mark is likely to be confusing or not, but ultimately it is up to a judge. There are subjective questions about how distinctive a thing is, how closely related a thing is, how similar the things are. There are some factors that are easier to measure like evidence of actual confusion by people. And there are some that are mostly up to the skill of the lawyer, like intent of using the thing. Trademark decisions are overturned and vacated relatively frequently, sometimes opening things up, sometimes shutting them down. Except they probably aren't the right thing, especially if the person who owns the IP decides to sue. There are many different IP laws that can be used, not just the big three of Trademark, Copyright, and Patent. By including a disclaimer, something like "This car that may look similar to a Ferrari really isn't a Ferrari", if Ferrari actually cares and brings it to a judge that can be used as evidence of intent and liklihood of confusion. That is, you clearly knew in advance and otherwise intended to make the thing look like Ferrari's car because you pointed out the similarities yourself when you launched the product. When you see people put disclaimers like that, very often it is when product names are used for comparison after nominative use. This is done AFTER talking with lawyers. Nominative use is generally permitted when kept within certain bounds, although even that is generally discouraged both for legal reasons and for PR reasons. But here's the thing: It is irresponsible to recommend anything other than "stay away from stuff you don't own and don't have permission to use." There is no good way to recommend "copy another person's IP but change enough to make it look like you made up your own" that can be a good recommendation. Either make something entirely new and distinctive (this is a creative industry, after all) or properly license the thing you intend to use. Yes, some people do it and get away with it. Others get shut down hard, including to the point of bankruptcy. It is minefield that should be avoided. If someone really wants to navigate the minefield a good lawyer can help them find good paths, but even that is fraught with peril.
  7. The concept of a state machine does not need to be nearly that complex. You can implement a state machine with large objects and virtual functions like that, but it is big enough to be a bad fit in the general case. You can implement a state machine with a switch statement, each state is a different case label. You can implement a state machine with an if/else tree. Even a bool value is enough to be a state machine, albeit with a single binary state. State machines are EVERYWHERE in code, and they take many different forms.
  8. If you're struggling with the numbers and the math of the system, get some good paper-and-pencil RPG games and play some of them. It may take some effort if you aren't currently skilled with the math, but usually it is simplified enough in the rule books that you can work out how they all interrelate.
  9. I've seen them done well on several projects, and I've come to believe there is no "right". As I mentioned above, the first relationship of People over Processes means that if the people are happy with what is going on, that's good. For the common practices, the biggest difference I've seen is the difference between the chickens and the pigs. The daily standups are for pigs, not chickens. The backlog is for anybody to fight over, but the active sprint board is for pigs only, and each pig can only post or move their own bacon. The biggest failure I've repeatedly seen is violation of the Sprint commitment. This is doubly-true when people other than the 100%-committed developers add anything to the sprint. It doesn't matter how important that bug or new feature is, that was not part of the sprint commitment. If something absolutely must be added, they give it to the Pigs (the developers) with a stated priority. The developers then re-evaluate the commitment, and the developer who accepts the task must remove an item of similar size in order to accept the one coming in. Far too often when it goes bad, it is because every bug and design request gets added to the running sprint, violating the nature of the commitment. If the specific developer did not commit to doing it up front, or did not account for the time in their plans for the cycle, then it doesn't belong on the board.
  10. frob

    Leaderboards optimization

    What you described isn't that big of a database hit. Even if you have 100,000 people per day, they should not be constantly probing the entire high score list. These requests are both simple and easily cached. If they're cached they have no real work, just the network requirements of sending data each way. If they require a lookup, there is no join or anything, just a single key lookup on a single table. Modern database servers can handle several thousand concurrent requests like that every second on a single machine. You're more likely to hit networking bottlenecks before database limits with those queries.
  11. Those are all this you *can* use, not things you *must* use. A static IP address is nice, but isn't necessary with dynamic DNS services. Virtual machines and virtual networks are convenient for configurations that you want to start up, shut down, move around, and isolate from the real machine, but in no way required. All you need is the ability of a remote machine to connect to the machine that is serving. It is extremely convenient for a DNS entry that points to mygame.com, but even that isn't a requirement. Hobby games can work just fine with manually entering an IP address that changes whenever you connect to the Internet. If/when it becomes worth the small cost to do more, you can do it at that time.
  12. Parallel: I'm only going 5 over the posted speed limit, is that safe enough? The only right answer is to tell you to not do it all. Don't do anything that is in the gray area. If it is someone else's idea, product, design, image, name, story, or anything else, then it is theirs and not yours. If you still want to do it, talk to a lawyer to understand the actual risks and the actual costs. Something may have a low chance of causing trouble, but if it happens you will be in the poorhouse, or the business will become bankrupt. Other things may have a worst case of costing a few hundred dollars if it is a problem. Usually the best option is to get permission so you eliminate that risk. If you don't get permission, don't use it.
  13. Don't try to mark discussions as "solved". This is a discussion board, not a Q&A board. We remove those markers when people add them because it halts discussion, and other people may have more to contribute.
  14. frob

    Traveling Santa Problem

    TSP is well researched. What you described with simplifying the mesh into small groups and solving those seems similar to the V-opt variations, where you solve the sub-problem of a cluster and then link the clusters. Not necessarily optimal, but often good enough and much faster than an NP-Complete brute force. The few times I've needed to write solutions I went with greedy algorithms. They path is not ideal, but substantially easier to compute and generally good enough in the context of games.
  15. frob

    How to get out of the mass? HELP ME !

    Many beginners and startups miss the details about marketing. Usually the development budget and the marketing budget are roughly equal. That is, if a game spends 500,000 on making the game, they will often spend 500,000 on marketing the game. If they spend 50,000,000 developing it, they will spend 50,000,000 marketing it. if you spent three years developing your project alone, working nights and weekends, expect to spend three years marketing your project working nights and weekends for a similar investment. Or pay money for a similar rate.
  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!