frob

Moderators
  • Content count

    10796
  • Joined

  • Last visited

  • Days Won

    5

frob last won the day on July 27

frob had the most liked content!

Community Reputation

44908 Excellent

1 Follower

About frob

  • Rank
    Moderator - Mobile & Console Development

Personal Information

  1. If you're interested in studying something, that is enough reason to study it. You mention your scholarship. Having the money to pay for the classes is important. In that case you need to prioritize. You write you are focusing on a business degree, so those should be highest priority. If you can get all your business courses completed and have room for classes outside your major, take the classes, but be careful that it doesn't harm your primary study. It will take time, so if you aren't getting A's in all your other central courses then you probably should spend your time on those, first. Before you take classes outside what the degree requires, talk to your department's academic adviser. You might be better off by doing something called "auditing" the other classes. That can mean taking the class on a pass/fail basis, or where you attend but don't get a grade that affects your transcript. This presents less risk to your GPA and the things that are more central to your academic progress. Some schools charge different rates when auditing a class, which can also be a boon.
  2. Warfare goals in space 4X

    I imagine there would be similar strategic goals to regular warfare. For an attacker at the most basic level there are three options: Annihilation so they're completely defeated, attrition so they lose enough things they get worn down enough to do what they wanted, and exhaustion like blockades until they eventually submit. A defender has an additional option of survival by attrition, keep on not losing until eventually the other side is sufficiently worn out and stops spending resources on the war. Games usually focus on direct annihilation or large battles in the hope of attrition. Some strategy games may use that for a while, although I think it is mostly a tool to hold one player back while the opponent amasses an army sufficient for annihilation. As for specific objectives, I think they lead to basically the same premise. * Capture and return, with resources, information, prototypes, key people, and whatever else. Could be accomplished through secrecy and espionage, or a full-on attack team. The "capture" could instead be leaving something behind, or stealing/growing/harvesting resources and bringing them back. Get in, do something, get out. * Capture and hold, often with key infrastructure. Again you could fight your way in, or slip in unnoticed. Get in, stay in until others arrive. * Search and destroy, often with key resources, infrastructure, and key people. Similarly as above, can be covert. Get in, sufficiently break stuff. * Blockade, prevent infiltration. I don't think anything fundamentally changes with a "revolves around planets" game style. In real life, interplanetary and interstellar warfare probably won't be about what happens on the ground. The biggest thing is getting stuff from one planet to another planet, or intercepting things before they arrive. If you've got enough power for rapid interstellar travel then you've got enough power to destroy a planet. "Nuke it from orbit" is a viable strategy as far as we can see, and throwing a bunch of big space rocks could be enough. A few small space rocks -- maybe the size of a house -- could level a small city. Somewhat larger space rocks, maybe a few hundred feet around, could decimate a wide metro area. An even larger space rock could be an event like a dinosaur-killing meteor that would transform the planet so much the warfare stops being significant. An attacker could throw space rocks from any direction at any distance. At their simplest, an attacker can just fly an interstellar ship at the planet and not hit the brakes. As long as it hits the planet fast enough, the planet gets destroyed. Even if the defender breaks up the ship, if the debris hits hard enough the planet still gets sufficiently destroyed.
  3. Fur and Dress

    These days fur is generally made in shaders. More advanced systems will run some combination of physics code with data passed to the shaders. Search for terms like "GPU fur shader", or if you've got an engine like Unity or Unreal, add those to the search terms.
  4. A reasonably modern computer can handle pretty much anything an individual developer can create. Think of the most advanced games your computer can already run. Those games are developed by enormous teams with hundreds of experts investing tens of thousands of hours writing code that pushes the limits. Your hobby game may do a lot of things, but your hobby game will be a walk in the park compared to the work required for AAA games your computer is capable of running. The minimum requirements for the major engines right now (Unreal, Unity) is a 10-year-old machine.
  5. Every company I've ever worked with has had their own coding standards. They always include a caveat that if the code you're working on has other standards, do what nearby code does. Every project I've ever worked on has had their own slight variations of the company's corporate standards. Invariably there is something specific in the project, for this reason or that reason the team can't abide by the organization's standards. Every team I've ever worked on has had their own slight variations of the project's standards. Invariably there is something about a tool or a utility or a developer or a research paper, whatever the reasons, the project's standards and the organization's standards just don't quite apply. If the compiler doesn't care, I don't care. Like everyone else, I'll try to make the code look consistent with the code around it. But I'm not going to sit around all day adding a bunch of spaces so all the variable names make a nice vertical row, having all the parenthesis and commas in parameters lined up in neat vertical rows, or ensuring there are five lines of whitespace between each function. Every editor with even a modicum of code awareness will obliterate the formatting in an instant. Do what works for you. It doesn't matter what the style is. It doesn't matter how many spaces or tabs you use, if you put spaces before or after parenthesis or commas, if you put braces on above, below, or on their own line. NOBODY CARES. Make it look consistent. Since this is visual studio, that means opening the files, hitting Ctrl+K Ctrl+D. Clean out any extra newlines, and move on to things that actually matter. You've already mentioned using regular expressions for blank lines. Use that type of thing if you want, or just scroll through the files looking for violations that stand out. If you're trying to spiffy things up for an interview, just like some people will iron their denim jeans so they look nice, if you want to do something fancy to your code in the hope it makes you look like a better candidate, do what you want. Just be aware that beyond simple consistency, nobody in the real world actually cares. Make it consistent within the files or within the system, then be done.
  6. As for the "off year", that is a good utility function. If all your options are to buy then that's all the AI will do. The AI won't have an option to NOT buy because all the options available are to buy. If you want the AI to have an option of not buying, you need to add those in as well. The action could be something as simple as "don't buy". Or it could be "save for a bigger purchase", that could evaluate what is available right now versus speculation about what might be available later, and the costs of both. If you include additional options, "saving for the future", or "off year", or "nothing looks interesting", the new options provide an alternative to spending everything. Each could have their own weighting functions, and there can be more than one of them. A baseline "nothing looks interesting" is useful to have in nearly all scenarios, since you don't want the AI to spend every coin they've got.... unless you really do want them to spend everything.
  7. The Blizzard Taketh Away and the Blizzard Giveth Back: Battle.net Lives!

    I'm sure several people in their brand team had already been pushing for the change as they tent to recognize the importance of existing market recognition. It seemed odd that the company would throw away a brand worth many million dollars unless they were trying to get away from the "battle" persona. Hard to believe the executive team was 'accidentally' walking away from their long-term multi-million dollar brand.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.)
  13. 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.
  14. 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.)
  15. 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.