• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

45187 Excellent

About frob

  • Rank
    Moderator - Mobile & Console Development

Personal Information

  1. Indirect references

    As a general rule, stay away from anything you didn't create. Don't reference it, don't add jokes about it, don't add a 'homage', don't add what you think is a parody (it isn't), don't use it for satire. It isn't yours, don't use it. After that general guide to stay far away from any products you don't own, everything else comes down to details. The amount you use, how recognizable it is, what benefits you get from it, what resources you have, how much you should have known, if you had asked for permission and had it denied, if the people who do own it actually liked it, if the people involved think you are worth the cost of enforcement or sending legal challenges, and much more. Many times the official answer would be "no" but because the product creators like it and there is minimal effect on their brands and products. the companies and brand teams will quietly overlook the violation and quietly enjoy it. I've seen that happen on several products. Everyone on the team loves it, but more than once I have been reminded that in the official forum posts we are not to talk about the violation: if we're questioned directly that we should say we didn't know if the people had authorization and that questions on the company's social sites should be told to ask the legal team instead of the social sites. Even so, everyone loved it and we knew as long as they didn't "rock the boat" by creating troubles for the product that the company would quietly watch and enjoy what people created. As you have already asked permission, it is best to abide by whatever they say. Even if there was a chance they would have ignored it, with an official no you need to respect it. On the other side, if you get an official 'yes" or even a semi-official nod to do it as long as it is minimal, then go ahead and enjoy the permission.
  2. C# Basic C# quiz

    Then why not ask them directly? Most of those questions seem to ask if the person taking the quiz can divine the answers you are searching for. Based on what you've said, neither your interview candidates nor the people on here fully picked up the nuances you were trying communicate. Even with those extra notes about why you asked the questions, I still don't think any of the questions solve the core questions about if they can do the job, or if they are smart about how they code, or if they can play nicely with others.
  3. C# Basic C# quiz

    My thought is that you are asking the wrong questions. Going through them... You have three "how could this be improved", or "what is potentially bad with this algorithm" questions, all are "aha" or "gotcha" questions. Either they recognize the thing you are looking for, or not. Most of these are inconsequential to the real world. Why are you asking? Are the improvements relevant to the job? Is this the kind of thing your programmer will be spending their day doing? They may be nice questions to ask if you are looking for something specific, but overall they don't tell if the person has the mindset of a good developer. Would you fire an existing developer if they got the question wrong? "Will it compile" is another "gotcha" question. Plug the thing into a compiler and look, don't waste my time trying to see if I spot the missing punctuation or typos. This has nothing to do with the logical process of writing code. If you're looking for someone to do proofreading or copydesk editing then keep the question. Would you fire a programmer for not noticing the issue? You've got two "what is the difference" questions. They're fine if you critically require someone who understands what the language is doing under the hood. But again, why does this matter to the job they're doing? Would you fire one of your other C# programmers if they don't properly explain the difference between abstract classes with C#'s single inheritance rules versus interfaces? Would you like to be fired if you didn't properly state the differences between generic methods and generic classes? I strongly dislike that type of programming quiz in general. The best places I've worked have not used them, and the worst places I've worked relied on tests and quizzes extensively. Except for cases where the pre-interview quizzes go too long (I tell them I will only grant them an hour max, I'm busy trying to get a job) I generally pass the quizzes, but so did a lot of other people who didn't get much stuff done or who liked to argue about unimportant minutia. I've also moved on to interviews after declining to answer quizzes after the hour is up, and I've had people agree that their company's standard written tests are a waste of time and my rules were a point in my favor. A simple "briefly explain question" is good, but deeper quizzing is bad. If it isn't must-have knowledge and if you wouldn't reprimand one of your own programmers for the answer, you probably shouldn't bother with it in that type of quiz. Good. An interview is a discussion, not a pop quiz. If they are discussions be careful that it isn't you talking and them agreeing, and be careful that it doesn't become a quiz show of "do you know this answer". Lines that start with "tell me what you know about..." or "what do you think about..." can lead to some interesting interview-appropriate discussion. Even better in my view are the questions "tell me about a time you used..." or "Tell me about any experiences you've had, good or bad, about ..." Some of my favorites are "tell me about some times you've made trade-offs in your code to accomplish a goal." If they look confused, ask about exchanging time versus space (such as a lookup table of pre-computed values) or swapped to a faster but less accurate algorithm, or switched to statistical methods, or tried a different language or tool, or otherwise showed they knew what kind of options are available to programmers. The amazing old Guerrilla Guide to Interviewing is always a good thing to re-read before an interview. You're looking for smart and useful. If they don't know a specific question but they're smart and useful they can find the answer online in an instant. None of those questions really seem to address those concerns. When I interview, my first thing is to look for interests and passions related to software, and ask about them if I don't see them immediately. Many programmers, being introverts, are highly passionate about what they do but some don't talk about it very well. I ask questions about what they've done, but I don't care as much about the specific details than I do about the words they use. Are they using the right vocabulary, are they describing solutions in ways that show they think like a programmer? I ask for them to write some simple code, but mostly as a simple sanity check. For more senior positions as you describe I look for big holes in their knowledge and experience. Have they worked on tools, on networking, on graphics, on gameplay, on engines? What have they NOT worked on? Holes aren't necessarily a problem, but are important to know and too many holes in critical areas to the work are a problem. We talk about what languages they know and how they have used them professionally and in a hobby. I recently (painfully) made a case against a senior programmer applicant. He had done some good things a decade ago, but nothing recently, he had big holes in his knowledge about too many things and he only knew a single programming language despite working in games for twenty years. Yes he was smart and everybody picked up on that, but he had pigeonholed himself into a role that was bad for a senior developer. He may have been an okay mid-level developer and may have been able to learn other languages and fill the holes, but for the role we needed at the time they were too big of an issue.
  4. Yes, that is exactly the issue described above. Repeating, A* is an optimization based on certain guarantees and requirements. When you start relaxing the guarantees (such as a range of values rather than a single value) then the quality of your results also relaxes. The more you relax the rules the worse the results become. You can try to mitigate it such as using the worst point in the range since you no longer have an exact point, but nothing will correct the fundamental issue that you're violating the algorithm's requirements. It gets back to the simple rules of computer science. Algorithms come with certain requirements. If you cannot meet those requirements then you cannot use the optimizations. Fundamentally A* is Dijkstra's pairwise shortest path algorithm with some optimizations when requirements are met; break the requirements and you lose the optimizations and need to do the full search. If you can start to restore those requirements through understating values, you can start to restore the quality of the results.
  5. Production in the AAA scene

    Also note that you are talking about massive projects. AAA games these days are hitting 9-figure costs. "Big" games are hitting $50M and more. It is sometimes easier to forget about that. Today's AAA project's total cost is becoming more easily measured as a fraction of billions rather than millions of dollars. While there are many steps that are common, there is much that is unique and different about each project. Much like other enormous projects there are similarities between projects but none are identical. Creating enormous skyscrapers or airports or major buildings have many steps in common, but each has unique building schedules and procedures. Building a large road network or rail infrastructure has many steps in common with similar projects, but each is quite unique. Individual teams have common elements that they do every day, as described. Many of those are common between everything; teams who create code, teams who create models, teams who create animations, teams who create object designs. But the questions regarding broad schedules and executive tasks over the entire projects, those elements are quite unique to each. The biggest publishers have somewhat refined their processes, but they mostly only bear superficial similarities at that level.
  6. MUDs also enabled mix through shared actions. As you write the resources were limited, but you could form campaigns and groups and parties who traveled out together. While each could be their own character type already, further specializations could be possible. You could have three different fighters in a group but each with different sub-specialties. One common factor was limiting inventories to the alphabet letters. You get 26 things, or if case is considered, 52 things. Some give an additional slot for money (the $ character) and there were also containers that could boost your number of distinct items, but the types were limited. Another was weight, if you carried around a fortune in cash you will be burdened by weight; if you carry heavy armor and heavy weapons you will be burdened by heavier weight; if you carry heavy spellbooks and you will be too burdened to cast spells. So include in your party a few people willing to be mildly armored to serve as pack mules, or get some pack mule MPCs while in town. There are many great MUDs out there still today, I strongly recommend spending time on them. You may be pleasantly surprised with what you find.
  7. My personal opinion is complete indifference about TTS. As I wrote above it depends entirely on the game. Some games with enormous budgets and high-end designs require voice acting that truly does need professional voice actors, speech coaches, and high-end recording studios. Other games can use -- and already use -- rudimentary audio tables for TTS that fits their game design wonderfully. Naturally the course of software is that it offers more options, higher audio fidelity, and more choices for encoding and use, but that is not an issue of the tech being suitable for gaming in general. To me the actual issue is the cost of a tech solution versus the cost and the (potentially enormous) benefits of the customized voice acting. If you've got the budget to create a game worth tens of thousands of lines of voice acting, or even hundreds of thousands of lines of voice acting, then you've got a budget to use a wide range of voice synthesis systems. At that point you can study what is out there, the costs involved, the benefits of the actual actors, and decide based on the details of the game itself. I already gave the example of Animal Crossing that has been using very simple TTS for nearly two decades with great appeal. For another example, when I worked on Tiger Woods golf there was an enormous corpus of audio from the announcers, carefully edited so it could be pieced together based on any situation. There could be comments about the distances, the lie of the ball, the quality of the shot, the wind and other environmental factors, and much more. The benefit of having specific well-known individuals far outweighed the costs. Even if we could have used a high end TTS system that made realistic tones and inflections it would have been a terrible mix. On The Sims series we had a wide range of audio. We had Simlish clips put together by real humans speaking nonsense syllables, but these could have been strung together by anybody and may have been a good fit for some TTS systems today. However, since the middle of the original Sims 1 series they have brought in big-name musicians to record their own music in Simlish. Bringing in Katy Perry, Lily Allen, Depeche Mode, Annaca, and other singers is not a choice about the quality of audio technology, but about the singers themselves. Bringing in the big-name singer is far more valuable to the game than any TTS system would be. In the Littlest PetShop series series we used a system similar to what Animal Crossing used. Players commented on how they loved it, it gave a great style to the game that a Simlish-style speech engine could not have used. These depend entirely on the game, not the quality of the TTS system. Some games have more than enough with yesterday's technology. Some games can use today's technology. And some games would not accept the TTS technology no matter how advanced it became, because the voice actors themselves are necessary. It is all about the games, not the tech.
  8. I don't know of any game that does that, for several reasons. First off, games don't actually cover that much area. Game worlds are substantially smaller than the world around us. WoW is around 60 square miles of actual content. Dragon Age 3 and Skyrim were both about 20 square miles of content. I'm not aware of other mainstream games that have more actual content. GTA5 is the still the biggest mainstream game area with about 100 miles (so in the 5000-8000 square mile range) yet mostly cookie-cutter buildings plus vacant areas. The actual modeled content covered under roughly 10 square miles divided into many small zones. Enormous worlds are difficult to fill with interesting content. If you are thinking about multiplayer games, population is also an issue. If you've got 27 million square kilometers and want people to interact with each other you'll need to cluster them together tightly and still be mostly vacant. Even if you had 27 million players spread evenly that means one person per square kilometer. Being a kilometer away from your nearest neighbor doesn't lend itself to interactions, an 27 million players is hard to come by. For reference, WoW hit 12 million active subscribers at its peak. Even if you decide to build up a giant world like those games, you still are unlikely to need a system like HPA* (Hierarchical Pathfinding A*). In the large games they build out by zone, and have each zone connect smoothly with each other. Generally the games are built so pathfinding of in-game objects stays within a small area within a zone. Players can travel between zones, but usually only through designated areas. Those areas follow a hierarchical system, but there are normally very few transition points so the connectivity graph between zones is extremely simple. Instead of a more complex HPA* system, the games typically use A* within the zone, and for inter-zone travel use a pathfinder on a larger (one, not hierarchical) graph that is carefully built by designers. The map designers designate a single point for each zone transition. So the inter-zone pathfinding might say to travel to zone 4, zone 19, zone 43, zone 76. The player would use a lookup table to find the transition point between zone 4 and zone 19 and route to it. Then after traveling there, they'd find the transition point from zone 19 to zone 43 and route to it. Repeat for the transition point from 43 to 76, and finally from that point to the final destination. And if you're looking for purposes other than games, I imagine there are better systems like those used by navigation programs. But they also probably rely on hand-edited transition points by the people who build the maps.
  9. Different systems support different things. Various tools from the day supported different things. The better engines supported fully-designed, partially-designed, and fully randomized areas. Fully designed areas were carefully mapped out. Partially designed areas had regions you would carefully map out, and others you could leave as open to fill out procedurally. Then you could also have towers with rooms and zones that were fully procedural. The fact that you mentioned Roguelike in your description generally implies it is nearly all rooms and mazes. Those are the easiest to automatically generate. Most Roguelike worlds are randomized levels of rooms and passageways, with small areas defined as special rooms, and occasionally as special levels. A special area may have wide areas of pre-defined stuff yet also have wide areas of procedurally generated stuff. There are (and were) many MUD and MUSH worlds that work that way. Hundreds of players in the same room rarely means hundreds of people in the same small area of the dungeon at once, they don't get too crowded.
  10. I think you just described the MUD and MUSH world. Some have been running for decades with hundreds of players online at any time, such as this one. I've heard compelling arguments that the MMORPG games of today are little more than highly graphical MUDs.
  11. Some games have used TTS for quite some time. It isn't fancy, but consider how Animal Crossing has done that for more than a decade. The text doesn't sound like professional voice acting, but when you've played for a while you can understand every utterance. There are many games where TTS is thematically appropriate. Games set in computerized worlds would be a great natural fit. Also less natural, but many text-based games have used it for years, particularly with vision-impaired players. So I think there is an item 0 on your list, the context of the synthesized speech.
  12. Be careful with what you described. The only reason the A* optimization works is because of the geographic spatial format of the map matches the heuristic function. The heuristic provides a sort, allowing the first match to be the best match. The more the nodes drift away from the actual map distances, the more the optimization breaks down. With a regular grid where cells represent motions exactly, A* works great because the heuristic is ideal. You can always estimate the amount left to reach the target by using the map distance. With nodes representing areas, the heuristic is more difficult because it no longer perfectly represents the sorting criteria. When the heuristic breaks down so it no longer represents the approximate best remaining solution, then you need to revert back to plain old Dijkstra's shortest pairwise path algorithm.
  13. Leaving a company at a critical moment

    For the ethics component, I don't think the things you mentioned are a concern. In my view, workers should be just as loyal to the companies as the companies are loyal to the workers. 50 years ago corporate loyalty meant pension plans for life, insurance for life, and contractually guaranteed partial plans if you were laid off, and workers were generally "company men", loyal for life. 30 years ago that meant companies giving heavy investments in retirement plans and good benefits, but nothing permanent with an expectation of a few months or perhaps a few weeks notice from either side. These days company loyalty means I'm loyal all the way up through payday, and I know I may be called into a layoff meeting because the corporate earnings call is next week. Why were you offered another job? Were you looking for another job? Did they headhunt you? If you were actively looking for an exit strategy anyway then take it. Are you happy there? If you find joy in your work you may discover the new workplace does not fill the same needs, leaving you better paid but unfulfilled. On the other side, if you aren't happy with the work you've got then a change may be good. The fact that you don't think your current company will be there in a year is a major issue. While it can sometimes pay to be the last person in the office, usually it means getting burned. Having a good job lined up means you don't end up unemployed with an emergency job search, so that's a good reason by itself. The extra 12K per year is good, and depending on your location on the globe that can be significant. But I'd wonder why the higher pay and better benefits? Is your current company that much below market? Have they not given promotions up at market rate? Is the new company more desperate? But be careful, you could be walking into a bad situation where they're looking for an emergency person to do a Herculean task. Go in with your eyes open looking for issues. Sometimes good deals and offers are made out of desperation instead of the much better reason of the company actively growing and looking for talent. If generally want to stay leave your company and are otherwise happy there, you might also consider another tactic. Without mentioning the job offer, tactfully ask your boss for a raise similar to what you expect at the other job, plus some extra as a buffer in case the company closes up within a year. Given wages and benefits, that may be 25K, or possibly higher, plus the additional time off. Be extremely careful about approaching it, the same as you would any other raise or increase. Do it in the morning, with mild trepidation, explain that a new project is coming up, you've got a new baby in the home, your wife is through maternity coverage, and you feel it would be fair given your needs, your past contributions, and your expected role on the new project. Make a case you think you're worth that much. Just be careful not to mention the other job, and do not make it to be a threat. Giving in to demands while finding a replacement is a common tactic for companies, they'll dump you when they get the replacement. Let the boss think you have some good reasons for needing significantly more money, not that you're about to bolt. Assuming you want to stay there and your current boss accepts the wage increase, congratulations, you'll be making more and staying where you are happy. If he says no or doesn't accept it well, that's another good reason to accept the new job offer.
  14. C++ precision

    Truncation like that is one way to do it, but most applications don't want that. For an example, a value of 123.000001 that has a floating point rounding error beyond the value would be truncated to 123.00. However, a value of 122.9999999 that has a rounding error below the intended value would unexpectedly go to 122.99 instead of the correct 123.00. There are several different rounding modes. The ones typically used in computers (and supported by hardware) are: Round to nearest, ties to even. This is also called "banker's rounding". Round to nearest, ties away from zero. Round up Round down Round to zero, aka truncation. This is the one you're doing. The default mode -- which is also the version humans typically expect -- is the first. The programming language provides string manipulation functions that correctly round the value. The printf family, the stream family precision functions, and Boost's string manipulation families all have the code to correctly round the result. The first two are part of the language directly, there is no extra cost to use them. The Boost version is an extremely common library I've had available in most professional projects. They are already present and included in the code. Use the tools that are available to you.
  15. As far as I can see, there is nothing specific on the matter. It looks like the standard defines several critical aspects, such a the numeric base (either 2 or 10) the sign/coefficient/quotient requirements, ranges, and so forth. Looks like you've got that covered. Section 5.3 covers the conversion, but doesn't provide a specific process. The conversion merely needs to happen and be properly rounded if narrower, exactly precise if wider. Nothing specific about denormalized numbers so I presume the rules are the same. I'm not exactly sure about your example values since an implementation MAY use reserved exponents used for +/- INF, SNAN/QNAN, +/- zero, and denormalized values, using the two lowest values for the markers. That's why 8-bit coefficients have a range of -126 to +127 instead of the more typical -128 to +127, 11-bit coefficients range from -1022 to +1023 instead of the more typical -1024 to +1023. Implementations are allowed to extend beyond that because the standard is careful to define the represented values rather than the encoding. In your example you give a 16-bit float with a 5 bit coefficient, but I think the representation allows for e-05 instead of e-08 since the two lowest values are reserved (excluding denormals). The 7-bit coefficient would have values -64 and -63 reserved so range from -62 to +63, meaning the lowest number would be e-19 rather than e-28 (excluding denormals). In that regard I agree with your assessments. Denormalized numbers aren't treated differently other than a special value for the coefficient. For a denormalized number I'd expect the mantissa to be extended or reduced in the same manner, rounding the mantissa if narrower, extending with zeros if wider.
  • Advertisement