• Content count

  • Joined

  • Last visited

  • Days Won


frob last won the day on November 20

frob had the most liked content!

Community Reputation

45064 Excellent


About frob

  • Rank
    Moderator - Mobile & Console Development

Personal Information

  1. Generally no. Studios hire many testers so there are many people constantly viewing the game hunting for issues. What one person misses another person probably notices. Even with many testers, games can have bugs that go unnoticed or unreported for months, and games ship with bugs that were not discovered during testing. As one example, in a long-running franchise I was in, at the end of each round a cash tally was shown and added to the player's accumulated in-game wealth. A tester decided to record the funds before the round, record the cash that was shown added during the round, and discovered that it did not equal the amounts shown at the end-of-round tally. More in-game money was coming from somewhere but not reported on screen or in the wrapup screen. No idea how long the bug was in place, but it shipped on at least two prior years and no testers caught it, nobody reported it online.
  2. Persuasive Games

    Exact age rather than range, gender, ethnicity, national status, questions about known biases regarding immigrants and refugees ... Getting that far in the survey persuaded me.
  3. Code review for the monthly challenge.

    Assuming your code works for you, that's a good first step. A game that works is better than a game that doesn't. Players generally don't see or care about the game code. Like a few others who requested reviews of their code, it looks like you have a few places that could be consolidated or eliminated. In your menu scripts you have two single-function scripts and one empty script. Often a Unity UI script has a single class that responds to many different inputs, and buttons/sliders/etc from many UI panels all use that single script for their events. You also have many one-line functions through the code that could probably be consolidated or eliminated. For example, colliding with a wall calls HandleEnterWallCollision(), which only has one line to call BounceBallAgainstWall(), which only has one line to call InverseVerticalMovement(), which only has one line to ChangeBallSpeed(), which only has one line to pass along to a different form of ChangeBallSpeed() that optionally caps the ball's speed by calling a one line RectifyBallSpeed() that changes a parameter to consolidate two values and pass along to a different RectifyBallSpeed(), which immediately splits out those same two parameters. Why all the redirection? If it bounces of a wall you know you need to play a sound and reverse vertical movement, nothing more. If you bounce of a paddle you play a sound, reverse horizontal movement, shift the direction of travel, and ensure the speed is appropriate. No need for the long chain of functions. Along the same theme, you've broken up functionality that could be handled more generically. For example, the queries of CanMoveUp() and CanMoveDown() do nothing but return flags. Those flags are set and cleared every frame, even if they are never queried. Personally I'd rather allow code to send the move commands all they want, but when they set it always clamp the results to within the valid range. You only incur the cost of checking against up or down if they actually attempt to move, and that cost is a single clamp call. The way you use Unity's 2D collision system means you end up with more scripts than you probably need. In Pong the only thing needing collision response is the ball. You've got them also on the PongController and the Goal objects. The ball controller already detects against wall and pong tags, you could add a goal tag to handle those, and remove the other two responses. Dump the Start() and Update() functions if you aren't actually using them. Unity automatically generates them since they're used in so many scripts, but they have a small cost. You have several variables that probably should be private --- you don't want others messing with the variable --- but you want them exposed in the inspector so you can attach a GameObject. Keep them private, but add the [SerializeField] attribute above the variable. For example: public GameObject pauseMenu; // could become [SerializeField] GameObject pauseMenu; In larger projects you will want to wrap the scripts in namespaces. Sadly Unity doesn't automatically do this, by default new scripts are placed in the global namespace. Your project is small so it isn't really need it, but it is something to know about as your projects grow. Since the game works for you that can be good enough. Most of these changes are minor structural changes to simplify the code.
  4. Yet Another Pong

    * Moderator hat on* This is a gentle reminder that we are in the For Beginners forum, discussing a project being implemented by a beginner asking for help with is code. Discussion on the poorly-defined meanings of object oriented-ness are not appropriate. Discussions in For Beginners should be focused on the actual problem the beginner is having. * Moderator hat off* Now, on to the updated code. I think that code is much more readable, even though it takes up more lines. Hopefully you agree, as it is your code and you're the one who gets to live with it. If I use the code-collapse feature of my IDE, the code is broken up into easily understood blocks: main(), Initialize(), Move_ball(), AI_Movement(), Player2_Movement(), and Reset_all(). I can look at that and understand your game. Expanding any one of those gives me logic that I can easily understand. For example Player2_Movement() opens to keypressed up and keypressed down. Each of those actions is easily understood when I expand them. Those are good, especially in beginner code. If I were looking to improve it -- even though what you've got in there looks like a runnable game -- I would next try to simplify by merging duplicate functionality. Moving up and moving down seem like the same operation, the only difference is that one is positive and the other negative, you can use a clamp function to limit movement both at the top and the bottom. That's 7 lines removed. The AI has different logic controlling if they move the paddle up or down, but the actual logic of moving of a paddle is the same as you're only modifying the y value. Extract the duplicate paddle-moving logic to a new function that accepts both a reference to a paddle and the direction it moves, and you remove another 10 or so lines of duplication. Moving the ball also has a lot of duplicate math that depends on ballsp_x is positive or negative. That duplicate math can probably also be merged. I'd also look at more consistent naming conventions. Sometimes they start with uppercase or lowercase, sometimes they have underscores, sometimes they have abbreviations. There are automated ways to rename all variable instances in most IDEs, so it is usually an easy thing to clean up. Games are shipped but never really done. There are always improvements developers want to see and bugs that could be fixed. Players don't normally dig through the source code, and if they did often they'd encounter nightmare fuel. If your code does the things you want to do and fits whatever performance criteria you've been given, you can call it good enough, even when it could be better.
  5. A good way to avoid extermination in RTS?

    There are multiplayer games where once you defeat an enemy by capturing their base, you gain all their resources. Others you gain their resources but all come at a reduced rate, or come to you damaged. Gaining their resources can be a factor in larger games. You may defend against a larger opponent but focus mainly on defeating smaller opponents. Or you may attempt to strategically attack a powerful opponent while you know they are sending resources elsewhere. When different players have different types of resources you may target opponents not because of their immediate power but because a combination of resources will improve your standing. These aren't just new games. Long-established games like Monopoly (played by the official rules) use the tactic. A bankrupt player turns their assets over to their creditor, which can make the creditor extremely powerful in the game. If the creditor is the bank, all the assets are auctioned off which can help a cash-heavy player tip the scales. Further, a player can strategically help to bankrupt a heavily mortgaged opponent to another of their opponents. Since the creditor must pay a penalty for mortgaged assets transferred to them, the automatic payments due to acquisition can cause a trickle-down bankruptcy. In turn this leads to a secondary strategy of purposely mortgaging property in the hope of becoming a poison pill, others do not want to bankrupt you because of the damage they will inflict on themselves. Thus the complete acquisition of the opponent's resources can dramatically impact the game, perhaps in favor over their victor or damaging their victor in a Pyrrhic victory. Resource acquisition can be a powerful feature in a game.
  6. Distributing a game with stolen resources

    The best answer is that this is a creative industry, you should be creative and not take other people's stuff without permission. The much harder answer is that when you take things, even simple thematic things that are probably legal to take, you enter a gray area. There are things that are completely okay and are standard scenes and tropes. There are other things that are clearly illegal. But there also stuff in the middle that isn't clearly legal, but also isn't clearly illegal. At that point it mostly becomes about risk management. A company may discover it, or they may not. A company may discover it and decide the infringements are small enough that they take no action. Or they might take action, which may be anything from an email to a C&D order to a full lawsuit. The company may even quietly encourage it when the project is small and not interfering with anything, but when it grows and becomes popular suddenly issue takedown demands. The risk can be enormous, up to and including killing the product or losing property or even bankrupting the infringer. The oft-given analogy is like speeding on a highway. Any speeding is illegal and a small percentage will get caught. The more flagrant the offense the more risk of being caught and the more the penalty increases. A few people will recommend speeding a little bit because you probably won't get caught and the penalty is usually small. A small group will recommend you ignore it completely because that group can afford the cost of a speeding ticket and don't particularly care about the safety and welfare of others. But the only right answer is to recommend people follow the speed limit and obey the law.
  7. That is one of the most difficult balancing acts within the business of games. There are some highly vocal, high profile people who will complain about the existence of microtransactions. There are some highly vocal, high profile people who will decry any game that requires people to spend time on games, that everything should be unlocked and available instantly. There are highly vocal, high profile people who will decry any games that use a progression system or story mode to advance, that anything requiring effort by the player is actually grinding and should be removed. There are highly vocal, high profile people who will shout to the world how whenever a player must pay for a game it is extortion. There are highly vocal, high profile people who tell others that the games are a great value. No matter what the company does there are highly vocal, high profile people who will shout it down. The tricky part is to balance them out. You want enough people giving positive feedback and actually paying for the game, but you also want a portion of the people to be offended because otherwise you won't make money and will go out of business. It further hurts the entire industry that many communities are highly toxic, where threats of felony crimes against the developers are commonplace and even encouraged. I've had co-workers get death threats before, including some where FBI agents came to talk to everybody after finding the death threats to their family members were actually credible threats. There are also other developers, even a few amazing indie developers, who have left the industry due to the highly toxic players and repeated threats from so-called fans. There is nothing "just learn how" about it. No matter what developers and publishers do there are people who will be deeply offended and will publish it all over the Internet. A good balancing point is incredibly difficult to find.
  8. C# + AS3 + C++?

    Some of the first steps are to hire a large team of experienced editor-developers, and spend several million dollars over multiple years on technology developed across multiple studios around the globe. EA has an enormous body of tech tools and libraries that cover just about anything you want. They've been built up for game after game, from project to project for decades. When I was working there I noticed and pointed out a date in a comment. It was from nearly two decades earlier, the comment stated that it was the third rewrite and they were hoping it would be the version that would solve all their issues. The tool worked great, we were adding our own useful bit of functionality which would be added to the suite.
  9. Yet Another Pong

    Pong is an extremely simple game, and it is easy to over-engineer. I'd ignore the comments about classes for Pong. The code you've got there does not need them. The only variable really are the position and velocity of the ball, the position of the paddles, and the scores. You can add more fluff, but that's all the game requires. That does not lend itself to game objects with classes and interfaces and interdependencies. I've put together a pong game for the Challenge this month and it was about 90 lines before I started adding the fluff. Pong does not need to be complex since typically the complex stuff of graphics and sound are handled by libraries. That is partially why Pong it an excellent beginner exercise. Larger projects certainly need it, but this doesn't. For a code review... Lines 15-47, you don't need to make all of those static. Global variables are static by definition. I thought it was interesting that you made some global constants, but you also scattered numbers around the code. You should probably put all your constants up there, but more on that below. Overall you place multiple statements on a single line, that is not a typical pattern. For example, lines 69-75 contain 32 statements. Why did you do that? Typical C++ code has one statement per line, even one declaration per line in most cases. Trying to cram 32 statements into 6 lines makes the code difficult to read. If each is a block of functionality, consider adding a comment to each block, or pulling it out to a function. From your code example, perhaps instead of three lines, try this: //Old code, this seems difficult for me to read ball.setRadius(10); ball.setOrigin(10, 10); ball.setFillColor(ball_color); ball.setPosition(640, 360); paddle1.setFillColor(paddle1_color); paddle1.setOrigin(8, 60); paddle1.setPosition(35, 360); paddle2.setFillColor(paddle2_color); paddle2.setOrigin(8, 60); paddle2.setPosition(1245, 360); // Suggested version // Initialize ball and paddles ball.setRadius(10); //TODO: Replace all these numbers with named constants ball.setOrigin(10, 10); ball.setFillColor(ball_color); ball.setPosition(640, 360); paddle1.setFillColor(paddle1_color); paddle1.setOrigin(8, 60); paddle1.setPosition(35, 360); paddle2.setFillColor(paddle2_color); paddle2.setOrigin(8, 60); paddle2.setPosition(1245, 360); In that snippit of code you've got a lot of magic numbers. These are difficult to maintain. It is usually easier to provide named constants that are all found in one convenient location. Then you can change one constant and it is reflected everywhere in the code. As written you may decide you want to change the paddle origin value from 60 to 48, and so you'll be searching the code for everywhere that has a 60 in it. Then when you find a 60, you'll need to make sure it is the right 60 and not used for something else. And even then, maybe for some reason you didn't use 60 but were using another value to represent something, or maybe you already added to values together but now you want to modify one of them. Lots of reasons, always use named constants. They should be added up near your other constants used for colors up around line 20. As for dividing code between files, typically the approach is to block them together by functionality, which usually means by feature or by class. Sometimes a third file will be used when using something like the pImpl paradigm, where the publicly used interface doesn't need to contain all the inner details which can help reduce build times on large projects. For organization, it depends. Often (but not always) directory hierarchies follow namespace hierarchies, and often (but not always) large subsystems and external subsystems go in their own hierarchies. The exact details vary from project to project depending on what works for the team. Overall it looks good for this skill level, and looks like it does the job of being a good pong clone.
  10. Nested namespaces useless typing?

    Namespaces are part of the interface. Used well they help tremendously. Used poorly they are nothing more than extra typing. Designing efficient interfaces, including bundling into namespaces, is a difficult task generally requiring refinement over time. It is also highly dependent on context. Namespaces are a powerful organizational feature, and the types of organization depend on the nature of the code. At first glance your example of my::system::io::path::ExtractFileName() seems an example of the poorly-executed variety, although it if the system happens to be rather complex with many systems and subsystems regarding the system, and many subsystems with in IO, and many operations and systems within path management, then it may be executed well.
  11. Get yourself a copy of the book "What Color Is Your Parachute?", any edition within the past ten years or so. Your local library probably has several copies if you don't want to buy it. The whole book has assorted gems to answer your questions in depth, but one part in particular would be useful. The book has a section called "the flower diagram". Some people work through it in a few minutes, but I recommend you spend a few days of serious soul-searching and work through it thoughtfully. The diagram specifically can help you identify what values/purposes are important to you, what skills and talents you want to use, the work environments and people environments you thrive at, the places (geographically) you want, and the salary and responsibility levels you would like. Done thoughtfully I've seen that transform lives, where the person suddenly realize the thing they want to do. Most people have minor corrections, but I've also seen complete redirection of careers, including a game programmer becoming a music instructor, and an artist moving to botany, where both people reported later how satisfied they were with the decision. As for the masters degree, I'd recommend that if you discover you want more education, otherwise probably recommend you get your job. It makes very little difference to most employers. There are exceptions, jobs in teaching or research or certain advanced disciplines require masters or doctoral degrees, but that's not typical of the workforce.
  12. Typically there are several representation of objects. For terrain you often have visual models, physics/collision models, navigation meshes, and object footprints with reserved rigs and similar, along with potentially more representations. For game objects usually there are visual models, physics models, and sometimes a navmesh footprint. Sometimes the physics mesh is created directly from the model mesh, but often they are different. You know a character is moving uphill by checking the terrain's physics model and looking at the slope of the physics polygon underneath it in the direction of travel.
  13. The first stop with that is your lawyer. Any time where you give real money or things of tangible value to players, the developers must ensure they are on the correct side of gambling laws. Violating gambling laws -- even if you didn't realize you were violating them -- can land you in prison. You seriously need to discuss with a lawyer before proceeding.
  14. A* is an implementation of Dijkstra's shortest path algorithm. It is an optimization based on having additional information that prioritizes the most likely work before the less likely work. Dijkstra's version finds the shortest path between nodes on ANY directed graph with non-negative weights. While game maps can be interpreted as a connectivity graph making a dense grid, they are only a single type of graph. The graph could be any thing at all that uses a directed graph. Not just maps and roads, but ANY data. All the web links on a site, dependencies between systems such as software modules or food chains, trees ranging from data storage trees to infectious disease trees or spelling dictionary trees, flow trees that can optimize finite state machines or data processing patterns or flow control. They can remove loops of logic during code compilation. The general algorithm finds connectivity on ANY of these directed graphs. Processing the shortest path on a map is a big issue in games, but in math and data processing such maps represents only the tiniest sliver of all problems. It is only for that minuscule percent of problems where the A* optimizations can be used. In the vast majority of graph searches the optimization cannot be used.
  15. Console How to make a console racing game?

    Whatever language you know. I've seen racing games written in many different languages. If you decide to use a major existing engine, know that Unreal uses C++ and Unity uses C#. If you go back a hardware generation where Microsoft had much better support for hobby X360 development, XNA used C#. For other engines, you'll need to research that yourself. Both Unreal and Unity have game console support. You need to be a licensed developer for the platform before Sony, Microsoft, or Nintendo will let you access their add-ons for the platforms. If you have lots of money for equipment and business contacts at the race courses, sure. Nothing so specific. There are tool kits out there where people have some code libraries about race management or driving through checkpoints, but you're expected to know most of the details yourself. Unless it comes with wages, probably none. Most people would rather work on their own ideas instead of other people's ideas.