• Content count

  • Joined

  • Last visited

Community Reputation

44752 Excellent

About frob

  • Rank
    Moderator - Mobile & Console Development

Personal Information

  1. I'm not sure what you're asking, so I'll give a few variations in my answers. If you're looking to move the targeting point, many games use a reticle (a crosshair icon) to show the approximate point of impact. It can move and wander as the player travels the world. It can also scale large or small depending on the accuracy and type of weapon. Exactly where it points can be adjusted either by code or by animators, depending on your game. Some games will also add some random motion to it, both to help avoid aim-bots and to simulate that humans aren't generally accurate marksmen on the battlefield. As for where the raycast source happens, either from the center of the screen or the muzzle of the displayed model, in general that doesn't really matter. In most first person games you see other players as human-shaped avatars, but based on what you actually see in the game your head would be mid-torso and arms are rooted somewhere behind your back. So fire the bullet from whatever position relative to the character's root works best for the game. Also for first person games, usually the player does not see their actual in-game model that other players see. Their own character is invisible and only their arms and weapons are visible, if they're shown at all. Some games don't use a single raycast, but are processed over time as segments. Bullets in real life take time to travel, and in networked games that time means more opportunity to mask network latency. A quick six-frame animation buys 90 milliseconds. A traveling bullet may add another 10 milliseconds to travel. To a player the slight delay can feel like added realism. To the programmers that slight delay lets the developers hide a round trip to the server. It also allows for players in motion to potentially react and avoid a shot, or for players to need to track their shot to hit where the opponent will be instead of where they are. And if you're talking about how you keep your animations matching the screen, that's usually a simple matter of parenting your animations to the camera, or parenting your camera position to the same root as the character. For most good art packages it is a simple thing for artists to address.
  2. Extending a standard library container class is almost always the wrong approach. There are very few things in the standard library designed for extension, and those are clearly indicated. It is possible to extend some of them, but it usually comes with unexpected ramifications. Your desire to mix smart pointers and raw pointers, as well as trying to describe what can be copied all reek of a common problem. Controlling the lifetime of objects is a critical aspect of software, especially true in games. What you describe sounds like a symptom of not understanding what code owns the lifetime. What is the REAL problem you are trying to solve here? You came up with a solution of trying to do complex things with a vector, but what problem drove you to that solution?
  3. Yes, the described game is far beyond such a team. I'd estimate what you described feels somewhere in the $20M - $50M range. It has potential, but the scope is rather expansive.
  4. Different schools have different programs. Many schools have a "game design" program that is primarily a programming course with only a few design topics. Others are highly focused on design, which has nothing to do with programming. I'm curious how the school's "Software Engineering" track is different from the traditional Computer Science degree. Often a program like that will issue something called a 'trade degree', which is different than what most people consider a university diploma. The programs are usually much faster but also less rigorous. If you decide to follow the programming route, I strongly recommend following the traditional computer science degree. It may take a little more time but you can use all the topics if you someday program games. If you someday decide to program something other than games you will have a degree that applies to non-game jobs, making that transition easier.
  5. First the Single Responsibility Principle applies. Finding a path and following a path are different. Give them both separate responsibilities. Second, finding a path is somewhat expensive, both in memory and compute time. It can potentially require a large amount of both when paths are complex. That's another argument for keeping them separate. Not everything moves the same way. If the code returns a path that can be used by anything, then whatever that specific thing is attempts to follow that path, it allows for customizing how things move. So another argument for keeping them separate.
  6. For prototyping, that seems exactly right time to explore it. Prototyping is a time to experiment with ideas and do things wrong, or do things somewhat well, so you can identify what works, what doesn't, and what works somewhat but needs improvement. I think in the talk they're in the right direction of discussing how many different play styles can affect things for some games. If it fits the game genre, and if you have development time/budget, then go for it. People are different, and if it makes sense in your game to adapt for that, then do it. Otherwise, don't.
  7. The judge makes findings of law. The judge interprets the law, rules on the law, and issues judgments based on the law and his own understandings. The jury (if there is one) makes findings of fact. (If there is no jury then the judge also does this.) Finding of fact means evaluating the evidence and deciding if there was in fact an actual violation or if there was not. When I have served on juries it is mostly about if the thing happened or not, or if the action rose to the level involved. In one case the law for one charge involved a pattern of behavior, but all we had in evidence was a single instance of behavior, so I argued that was not met. In civil cases there is often a claim of quantum meruit, that's Latin; quantum = smallest unit or step, meruit = earned; in other words, even if the person didn't earn the large financial reward the jury needs to answer if the person earned even the smallest reward. Jury nullification is where the jury decides that a thing is not a crime or does not apply. It may happen that a jury may decide even though the people did fight it was reasonable for the situation, thereby nullify a claim about assault even though the assault clearly happened. Or the jury may feel sympathy toward a drug user, and nullify a claim about drug possession even though the act clearly happened. Usually it is not about the jury sitting in the room declaring "We're going to invoke jury nullification!" Instead typically the jury decides that they don't feel good about a conviction, or decides that even though it looks like the violation happened they don't feel like it rises to the level of the claim, or much more rare, decides the legal claim is wrong or invalid or stupid and votes against it out of principal, which happened several times during racial segregation where juries refused to convict over laws aimed at a minority race. They don't say anything about nullification, they simply return a verdict saying "no" to the claim or "not guilty" to the charge.
  8. It all depends on the project. Games range from a single developer on their own for hobby titles, a team of 5, 10, 30, or even 50 for more common games. Some reach into the hundreds of developers. For that game there were hundreds of developers spread across multiple studios, developing the product for several years. And as I wrote, that type of non-distributed rebuild done on an individual workstation almost never happened. People would pull down intermediate files from build servers so they don't need to build them locally, and when they do need to build parts tools like IncrediBuild automatically distribute the build to several machines.
  9. I tend to agree. It all depends on the context. I love when games allow you to choose things like race and gender. Even better when they have effects on gameplay, for example, Dragon Age did this well. Start as a human male and you get some good social traits. Start as a human female and you get some slightly different social traits, a little boost to charisma but a penalty for being in command. Start as an elf (seen as a downcast race in the series) and you get a serious drop to many social items, with slight variations for male and female. Qunari get a big boost for some things as they are a military race, but a big penalty in other areas as they are seen as gruff and coarse. The choice of role like a mage, warrior, or rogue make more differences in how the player is treated by NPCs and social variables within the story line. Characters in the game were a good mix of races, gender, and skin colors that varied depending on your location across the game's countries. It made for a compelling fictional world. However, a WW2 war game striving for accuracy ought be predominantly white males, with a few other skin tones mixed in. Women will be citizens or non-combatants. Anything else would not be accurate.
  10. For reference, a "unity build" is different from the Unity game engine. It is one of the techniques to speed up builds, often giving dramatic performance increases when doing large code rebuilds. It extends the idea of precompiled headers. In a precompiled header instead of processing hundreds or possibly thousands of header files that are included through a seemingly endless chain of references, then re-processing those same files for the next compilation unit, all the macro expansion, file loading, preprocessing, parse trees, and other items are generated then saved and reused. With a unity build, you've got one file that has a #include for a bunch of .cpp files. This turns all those files into an enormous compilation unit. It is generally much longer for an incremental build because more files are touched than a regular compilation unit, but for large builds and engine rebuilds it means fewer files are touched overall, there is less parsing and processing done in aggregate, and all the complicated structures and grammar rules remain in memory as a few hundred .cpp files are processed all at once in a single process instead of the compiler being launched for each .cpp file individually with all the stuff getting dumped and re-processed for each. A full rebuild of the last project I was on, a AAA title, took just over five hours to rebuild the code for the optimized debug build when not distributed with IncrediBuild. The final gold build (with all optimization settings cranked up) took about a day when run on a single machine.
  11. I've seen many variations of delayed destruction. Managing the life cycle of game objects is sometimes tricky. For objects in the game world there are typically states of {created but no content}, {content but not in world}, {in world and inactive}, {in world and inactive}. In that case a call to destroy would remove the object from the world and mark it as inactive, but the actual destruction would take place outside the main update and processing loop. For objects like you describe, I've seen that pattern quite often. Make a second list of items to be removed, then process the dead list at a more appropriate time. Another option if items are often in flux is to add a flag to indicate if the node is live or dead. As the collection is processed each item is tested for life. To remove an item you simply mark it as dead. When another item is added it will replace the dead one. That eliminates the need to resize, potentially invalidate the container, or move items around.
  12. Just noticed the FAQ sidebar boxes are gone when someone asked a question covered in the former FAQ links. Hopefully they still exist somewhere.
  13. Not a game design topic. Moving to For Beginners. I was going to suggest you read the For Beginners FAQ, but with the site update over the weekend those seem to have vanished.
  14. Usually it is a person being in power, authority, or trust. The nature of the relationship, such as the ages of the people and the relative level of trust are generally considered by the judge. Teacher/student relationship qualifies. A camp leader over a camper, a security guard over those being guarded, police over a suspect, a boss over their workers, clergy over parishioners, physician over patients, each have various levels of authority and trust. Even if the teacher and student are in a university setting, with the teacher being a graduate student who is doing supervised teaching of incoming freshmen, a relationship between consenting adults of similar ages can still be a concern because of the position of power and authority.
  15. Moving to the career area of the site since it is a slightly better fit. At age 12 he should probably have a good idea of what he wants to work on. At that age I'd encourage him to follow whatever interests he has rather than trying to do the boring stuff. He should be exploring, tinkering, and learning freely as he goes to whatever interests he has, in addition to exploring ideas and subjects outside of computers. There will be plenty of time in life to do the grunt work, to fill in all the pesky implementation details, and to do the drudgery and daily grind. By freely exploring and experimenting he'll be highly motivated to do whatever he wants to do at the moment, and with that motivation he'll read and study more, he'll try more options and learn from mistakes, and he'll push harder to make the systems do whatever he wants them to do.