• Content count

  • Joined

  • Last visited

  • Days Won


frob last won the day on July 27

frob had the most liked content!

Community Reputation

44902 Excellent

1 Follower

About frob

Personal Information

  1. The words are a little rough, but I think the answer is yes. The template portion is a part of the total signature. People commonly write it on a second line, but that is just for readability. You could put every word on a new line, or squish the code down to a single line of text, the language doesn't handle it differently. The first template is: template <typename T> bool within (T var, T min, T max) {...} Defines a single template, basically a cookie cutter, with T as a replacement. When the function is encountered, all the options for template types "T" are tried as replacements for the symbol "T", the best match is found, and new function is automatically generated where "T" is replaced with the template type. That is the entire definition of the template, it stops at the end of the function body. The second template is: template <typename P> bool withinTest(T var, T min, T max){...} Defines a second template, basically a cookie cutter, with P as a replacement. When the function is encountered all the options for type "P" are tried as replacements for the symbol "P". Unfortunately the compiler cannot find any type called "T", so compilation will fail. Again, that is the entire definition, it stops at the end of the function body. A class template is: template <typename A> class foo {...} Defines a class template, basically a cookie cutter, with A as a replacement. When an instance is created all the options for type "A" are tried as replacements for the symbol "A", etc. It stops at the end of the class body. Both template classes and template functions start with the word "template", then some type parameters inside a < > block, then provides the rest of the class or function that is basically a search-and-replace with that symbol replaced. I think of it more like a cookie cutter rather than actual code. You make the cookie cutter in the right shape. The cookie maker tries it on all the options, perhaps trying it on gingerbread cookies, sugar cookies, oatmeal cookies, vanilla cookies, wafer cookies, and all other cookies it has ever learned about, eventually finding the version that works the best. On rare occasion you will expect there to be one match, perhaps expecting apple-cinnamon flat cookies, only to discover the choice was chocolate pistachio sea salt cookies that you never thought was an option. Similarly, template code takes a long time to compile because it has to consider all the options (and sometimes "ALL the options" is hundreds of thousands of types, references to types, pointers to types, typedefs of types, parameter packs, enumeration types, deduced types ...) and considering all the options takes time. In rare cases the best option the compiler finds is not the one you would have thought, which may be an unexpected neutral surprise or an unexpected defect. Also somewhat critically, something many people forget is that templates are not actual code. One excellent writeup is on cppreference: "A template by itself is not a type, or a function, or any other entity. No code is generated from a source file that contains only template definitions. In order for any code to appear, a template must be instantiated: the template arguments must be determined so that the compiler can generate an actual function or an actual class." The template tells the compiler how to generate a function with the proper types. This subtlety helps explain many of the quirky behaviors templates seem to have.
  2. Perhaps that didn't come across clearly. In some regions, if you don't have a bachelor's degree you won't get hired. There will be a pile of job applications and yours will be one of the few without a bachelor's degree. Unless you've got a long list of accomplishments and published games, the lack of a bachelor's degree will visibly stand out, and the job application will never make it past the HR desk to the people who have the power to interview or hire. In one region I lived, a bachelor's degree was basically required for every job since education was plentiful and cheap. This was wonderful for employers because candidates met a much higher education standard, but it made it more difficult for people who did not want to go through higher education. There are also regions at the opposite extreme, where higher education is extremely rare and degrees are heavily touted. And there is everything in between. Good. It is an excellent guide to help discover where you want to take your career. I've heard of schools where it is mandatory reading.
  3. That still suffers the same problem. The comparison (a <= b) for (float <= int) is still going to result in the same question: Should the compiler convert the float to an int, or an int to a float? (The rules are well-defined, but may not be the one you are expecting. ) Both options are exactly one floating-integral conversion so both remain equally valid. The compiler will do the conversion it believes is correct through implicit conversions, which may not be the one you believe to be correct. It is still better to explicitly pick the correct value rather than rely on an implicit conversion. I suppose yet another option is to explicitly provide those options, but it seems even worse to me: bool within(float v, int a, int b) { return within( v, (float)a, (float)b);} bool within( float v, int a, float b) {...} bool within( float v, float a, int b) {...} Explicit is better than implicit in cases like this. If you want the float version pass floats. If you want the int version pass ints. Don't mix and match with the hope that implicit conversions will convert the way you want.
  4. You've got a few good Your location matters. The nature of your "Game Programming at a college level" can matter. In some regions a bachelor's degree is nearly required for HR because nearly every applicant has the degree. Your "Game Programming at a college level" might satisfy HR requirements, or they might not. In other regions it is mostly about prior work experience, demos, and portfolios since higher education is more scarce. Ultimately you aren't in a vacuum, you are competing against others who apply. That is a good soul-searching question. I recommend the book "What Color Is Your Parachute?" The book has several chapters devoted to helping you figure out many different paths you might want to explore, and many different methods to get wherever that destination happens to be.
  5. How do you balance gaming and game dev?

    The easpouse thing from 2004? That was a specific project team that was widely known both inside and outside of the company as being terribly mismanaged. There are a smaller number of teams in specific studios that have problems, but usually they are fairly localized. Good teams and bad teams, good managers and bad managers, good projects and bad projects. I've found this to be true of every organization. The smallest companies and startups have less variety, but only because they are small and have so few projects. It has very little to do with a person's ability to play games on their own, except perhaps how working at an abusive company --- which is universal to ALL companies in ALL industries --- a bad company will require you to work extensive overtime which eliminates your personal free time. In a good company you can go home at the end of the work day and do whatever you enjoy. (Note that in many companies there are people who stay late and work long hours because of their own reasons, but that does not mean you are obligated to stay the same hours. I know people with no real life who work 12+ hours per day, there is no reason for that apart from not really living. Put in a full day's work and go home guilt-free when the time comes.)
  6. You've got parameters (float, int, int) there. The compiler needs to do some type conversion to make it work. The problem is that you've got more than one valid conversion, and there is no requirement the compiler can use to pick one over the other. Even if you go with template versions you're still mixing types, the (var>=min && var<=max) is doing an operation between the first and second parameter and the first and third parameter so the types need to have compatible operations. If it were a template function then the rules became a little more strict for the inequality operations (greater than, less than) in C++11 and C++14 but it would still have the same fundamental issue in older compilers. There are a series of implicit conversions that the compiler can do automatically, but in this case it is ambiguous: Is it supposed to turn the float into an int, or turn the int into a float? Conversions in either direction can potentially lose information. Neither one is inherently right or wrong as far as the compiler is concerned. The compiler has a long list of potential conversions and two of them are both valid. The details of that floating/integral conversion are implementation defined. It could convert them to int, it could convert them to float, it could generate a warning or not, all of that is implementation defined. That's an implementation decision. Through history most compilers would warn by default, but different warning levels could be used that would enable or disable the warning. For your old code, old versions of Visual C++ were more lax about many conversions, silently choosing conversions that may lose precision or deciding between versions when they were equal in precedence. In particularly, VC++ before 2008 were far more lax about several of the standard-required conversions. The code was technically ambiguous but the standard allows for implementation defined behavior. The compiler made some implementation-defined choices about which conversions to take and accepted it without generating a warning. As the compiler teams in VC++2005 and VC++2008 pushed for better standards compliance there were many of these errors that started popping up in some code bases. The warning there is correct, pass all three as the same parameter type. If that means using floating point constants like 0f or 1f, then do it, just as in the 16-bit world people would write constants like 0L or 1L, or in today's world many code standards encourage 0ULL or 1LL and similar. Make sure your parameters are the correct type so the compiler doesn't have to guess.
  7. How do you balance gaming and game dev?

    I've worked at EA and also worked as a business contractor for EA for nearly a decade. The first point is that EA is HUGE. There are dozens of studios, hundreds of project teams, thousands of small work teams and groups. Every studio is different, every project is different, every team is different, every group within each team is different. Some projects have horrible constraints, particularly those tied to movies or other external products where poorly-designed features (particularly from external requirements) cannot be cut, and where deadlines cannot be adjusted. Some managers are bad, having been promoted to the Peter Principle with no good management skills. Some teams and groups are bad, with toxic views or terrible work practices. On the flip side, some projects are amazing, particularly when the team has the ability to negotiate features and designers, producers, and leads can figure out excellent games where everything can fit in a good schedule. Some managers are amazing, knowing how to keep projects within scope and ensure that everyone on the team is thriving. Some teams are amazing where producers and designers work with implementers and everyone knows their job, does it, schedules are kept realistic, and everything comes together well. Some groups are thrilling to be around where everyone is filled with creativity and enjoys the work. As mentioned above, it is always true that with a large enough group of people there will be some who don't love their daily job. That is not inherently a problem. There have been times I disliked the project but the people around me were so enthusiastic I couldn't help but enjoy something about it. I may not have loved the tasks, but being surrounded by (sometimes disturbingly) exuberant artists and some cheerful leaders who helped lift everyone up, so it was still a pleasure to do the work. If enough people are positive and enthusiastic then a small number of people who aren't satisfied with the project can still enjoy the workplace, and can still contribute to make the place fun. (When doing janitorial work we had tons of fun, we goofed off all the time. Even though cleaning toilets and vacuuming floors is not particularly fun, the work was punctuated with floor-buffing races and other shenanigans made the work environment enjoyable.)
  8. How do you balance gaming and game dev?

    There is a great book, "What Color Is Your Parachute?" that covers that in depth. I strongly recommend everyone reads it, it has been a best-seller for many decades so you can find many copies at your local library or used book store. Yes, you can do a job you don't enjoy. You can grow to love a job that you initially dislike. You don't need to be passionate about something to do it. For example, I spent some of my early years doing custodial work; I hate vacuuming and cleaning toilets. I also spent several summers earning money doing yard care even though I have severe allergies and needed to be heavily drugged to get through the days. However, I love software development and I can talk with people for hours about good practices, about algorithms and tradeoffs and software bugs. I also enjoy games and developing products that people enjoy. I also love several other fields, and I've turned them in to hobbies. Even though I love software development, there are still tasks I dislike. There are still software assignments I don't want to do, but I do them anyway because I'm a professional, just like I cleaned toilets and breathed pollen clouds while disliking the job. All jobs will have elements you dislike. In an ideal world you do stuff you love all day, every day. In the real world you can get occasional periods of bliss but most of the time you get boring real life. Sometimes you get difficult troubles, and in that case you can (and should) take any job you can honorably do. If that means doing a job you dislike that pays the bills, then for a time that may be a job you've got to do as you work to improve your situation. Anyway, go get a copy of "What Color Is Your Parachute?" which has several soul-searching exercises to help you figure out details of the things that you most enjoy in an effort to bring you closer to your own personal bliss, the things you enjoy most. I heard the quote years ago: "Life is to be enjoyed, not just endured." Endure when you must, but find joy wherever you can.
  9. PInvoke is one term, data marshalling is another. is a good resource, but even so, the effort involved is still an annoyance. In working with C you still need to operate in terms of sources and sinks, and when the C side function is allocating, you'll need a corresponding C side function to release it.
  10. There is a balance to it, and the balance is so difficult it is often a big part of what goes in to regular patches for long-term games. Balancing a game AI is tricky. Make a game too easy and players won't enjoy it. Make a game too difficult and players will hate it. Generally there are options for different levels of difficulty, often each needs to be fine-tuned individually. Nobody wants to fight a perfect AI. A machine that always makes the ideal decisions, always follows the ideal path, always makes perfect shots, always makes the perfect corrections and countermoves to the player's actions. On the other hand, nobody wants a stupid AI. A machine that always makes predictable decisions, that regularly makes the same mistakes, that never really plans ahead. And as for hidden stuff, you as a player realize things about hidden stuff all the time. You know the location of all the mines and resources. You have learned all the great positions for being a sniper, or the great positions for picking up tons of loot. That stuff isn't shown on the map, but it is something you have learned. The AI isn't doing complex machine learning, nor is it likely to retain knowledge between levels. The AI also needs a bit of unpredictability so it doesn't follow the same path around the map every game, always falling for the same traps, always routing through the same funnels. To compensate, most game AI's look at information that isn't shown to the player. Further, understand there is more to randomized behavior than a dice roll. There are many different distribution curves that can be used, various statistical models and probability options. Numbers can be biased high or biased low. Odds can be heavily skewed. Distribution curves can be modified at runtime, adapting to skew right or left to automatically balance based on how the player is performing. Consider games like Mario Kart, the series has done well at dumbing-down the AI to make horrible mistakes when the player is trailing, or pushing the AI to perfect or near-perfect performance with full knowledge of the board when the player is performing exceptionally well. Even if the player understands the computer is 'cheating' and occasionally loses to it, the players still adapt and play the game because it is fun and challenging.
  11. How do you balance gaming and game dev?

    That was probably me. Based on the tone of some people's messages, over the years I occasionally ask if some people are trying to develop games because they enjoy consuming games rather than because they like creating games. Usually it comes with this example: Enjoying the symphony is different from being a concert violinist; consuming a delicious meal is different from being a gourmet chef; watching high performance racing is different from being a high performance driver. Similarly enjoying completed video games is different from creating games. There is nothing wrong with being a consumer rather than producer, and we are creating the products for you to enjoy. Even if you don't do the work professionally, learning a little of the craft can help you appreciate it even more. That depends on your role. A game programmer doesn't need to be a gamer to be successful. They need to understand what they are creating, but that can be done through careful descriptions and maybe some videos or drawings. A game artist doesn't need to be a gamer to be successful. They need to be a great artist, and need experience with drawing a wide range art styles. A game animator doesn't need to be a gamer to be successful. They need to be a great animator with experience at making compelling animations. A game producer doesn't need to be a gamer to be successful. They need to be great with people, great at scheduling and organizing, great at working connections between people. A game designer doesn't need to be a gamer to be successful, but at least in this role, it actually helps designers. A designer needs to know and understand what makes games bad, what makes them good, or great, or awesome. They need to study the games they play much like a surgeon studies other surgeries and cadavers. Designers also need to follow and understand the trends of what is rising in popularity, what is beginning to become stale, and what is falling out of favor. Obviously you need to have some passion for the field in order to enjoy it, and if you don't enjoy your work I'd recommend finding a field you enjoy better, and keeping your hobbies as hobbies. That doesn't mean "being a gamer", but it does mean enjoying the field. If you love programming but think games are a waste of people's spare time, you might find programming for tools, or programming for broadcast television, or programming for shopping portals, or programming for some other field more enjoyable. Similarly for art, if you enjoy being an artist but aren't passionate about games, there are many fields using art for marketing, there are many styles of entertainment, there is art in product design, you can find art in a field you are passionate about. If you don't like your job (even if you enjoy the profession) you can find a job that suits you better. Most of the designers I've worked with accomplish it by sampling and studying things. They need to understand the mechanics of every game in the top 100 list, especially those that are quickly rising. They need to understand the detail of what makes the game fun for the top 50 games. They also need to watch the indie scene to see what is rising, what the reviewers are talking about, and understand those. They also need to take an occasional view of the games that people dislike, watch what people are complaining about, and understand what the problems are. Many of these require only a cursory study. Some can be accomplished by watching a video review at high speed, slowing down and possibly rewatching segments with gameplay videos that demonstrate the key elements. Other times it can be done with 2-3 hours of playing the game. It is still good to occasionally play games through completely, and if you've got free time and enjoy a game you might try to be a 100%'er for the game. But it isn't strictly necessary for success.
  12. Leaderboards Without a server?

    You will need somewhere to connect to, somewhere that has the data. There are many hosting sites that can handle it for free or extremely low cost. That doesn't mean it must be complicated. Wordpress is easy enough to set up for free, and with minimal PHP and WordPress knowledge you could set up a page that handles it. You'll want to make sure the host provider allows the use, but assuming you're also redirecting people to your web page and not showing up oddly in their site statistics, you should be fine. As you suggested in your post, you could then use standard web calls to serve up the data and to post new entries in the table. Note that you'll still need to figure out how you'll handle attacks, cheaters posting fake scores, people attacking the server, and so on.
  13. Not mentioned yet: You don't compete in a vacuum. You are being compared to other applicants. If one candidate has experience and another doesn't, that counts in the first one's favor. If one candidate has a degree and another doesn't, that counts in the first one's favor. If one candidate has some great demos or code samples or other porfolio items and the other does not, that counts in the first one's favor. If one applicant has experience with a specific skill and the company desperately wants experience with it, that counts strongly in that applicant's favor. For mainstream positions the company needs to fill n job slots. They'll ask for applications and do interviews and usually hire the best n people they can find. You don't need to be the best in the industry or the best in the world. You instead need to be one of the better ones they interview. When a company is struggling to find developers, that can be a relatively low bar.
  14. They are common in larger systems where the is a bundle of information to be passed around. It may be a structure with pointers to subsystems. Maybe pointers to the rendering system, the audio system, the networking system, the input system, and so forth. This decouples systems so developers are more likely to avoid troublesome patterns like singletons and well-known instances. A caller can fill in values that it cares about, or can replace values with an alternative such as a debugging proxy or a testable mock object or an easily swapable system. This becomes more useful as systems grow more tendrils and it is easier to pass a structure than to pass fifteen individual parameters to every call. Of course, that is also a code smell that code has grown more tendrils into unrelated systems, so the pattern is also sometimes an anti-pattern. For some systems it may be a structure that contains an enumeration saying what type of data it uses, then a union of structures for the various types of data. A fairly common example is event systems. It is somewhat common to have a structure where the first value is an enumeration like KeyUp, KeyDown, KeyRepeated, MouseUp, MouseDown, MouseMove, TouchActive, TouchMoved, TouchReleased, etc. Then there is a union of structures with the data for each type of event data. It allows for a similar processing that you'd have for an event inheritance tree moving the conditional logic to the consumers of the event to process the event rather than keeping the processing polymorphic within the event. In both cases you simplify your system by passing around a pointer/reference to a structure rather than a bunch of individual parameters.
  15. Over the years I've noticed the things that make IntelliSense choke are also the systems that disturb my sense of rightness. Usually code based heavily on macros to construct things that probably shouldn't be macros, but instead use things like CRTP. There is often code that is "valid C++", where it only compiles after the compiler has had to go through multiple rounds of substitutions and various gyrations to figure out exactly what things can go in and still produce valid results.