Rydinare

Members
  • Content count

    775
  • Joined

  • Last visited

Community Reputation

487 Neutral

About Rydinare

  • Rank
    Advanced Member
  1. Reducing game development costs

    Quote:Original post by Steadtler Quote:Original post by Rydinare Well, I never suggested it was non-profit. But, when there's newbies out of school who will take $30k to get into gaming or $60k for non-gaming, the gaming companies get used to underpaying. I'm not specifically referring to artists, because I'm not familiar enough with what artists get outside of gaming; it's very possible they do as well or better in gaming. However, this is definitely not true for developers. As far as the stigma, I'm not saying game development pays like crap. But it does pay below the competitive average for most industries. Compare it to finance; not even close. Considering that game development can be among the most challenging types of developer roles, the salaries don't really match where they should be. The reason why the stigma sticks is because there's some truth to it. I'm happy for you with your personal situation, but yours is the exception, or maybe the situation is just better in Canada. *Good* studios dont hire the lowest salaries they can. They try to recruit the best they can find. Because the industry's grown so much, the demand for qualified people is higher than the offer... Anyway, I see I wont convince you. I hope not too many people avoid the game industry because they think they'll be underpaid. You gotta make some sacrifice (no more than most nurses or accountants I know), but it can be quite lucrative. If you wanna have a good career tho, you gotta be mobile. Thats true for most hightech jobs. Anyway, sorry for highjacking the thread. I still dont think that high marketing budget means devs should get paid more, your salary is based on your skills and your negotiation power. Top games are more and more complex, requires more and better qualified people which can negociate for better salaries, and that certainly increase the cost. The downtime between projects can mean that you're paying a lot of people that dont have much to do in pre-production. Its a management problem, especially for a small studio with one or few teams. Getting bigger helps, some outsource assets production. A lot of studios just end up firing a lot of people and hiring them back 6 months later (unproductive IMO.) I'm fine with agreeing to disagree. I also apologize for hijacking the thread, if I did so.
  2. Reducing game development costs

    Quote:Original post by Steadtler Quote:Original post by Rydinare Okay, well first, I think you may have read more into my post than what I actually said, so let me elaborate. I've worked in the gaming industry, so first, I've experienced this before. People are willing to take considerably less to work in a gaming job than other jobs, despite often having more hours. Is this true for every gaming company? Probably not, but has certainly been what I and others have seen. In my experience, the salary reduction is often anywhere from 10% - 30%. True everywhere? No. But, it is common enough to be noted. This has nothing to do with being qualified, in my experience. Paying well and paying competitively well are two different things. I would say that your success in doubling your salary is not the norm. As for advertising, it simply follows proportions. If the company is spending only 20% in development, then raising developer salaries 10% is almost negligible. The 10% salary boost would only increase total costs for the project 2%. Simple proportions. Overall, seeing that so much is being spent on advertising when at many shops, developers are spending most of their lives working through the project and getting paid subpar salaries is kind of disturbing to me. Game studios aren't non-profit organizations. Like any business, they'll try to keep their cost as low as possible. If more money spent on advertising brings more revenue than more money spent on salaries, it make sense to spend more on advertising. I'ld just like to get rid of the old stigma that "game development pays like crap", which isn't true anymore. Average game programmer salary is 80'000$ US, and its much higher with experience. Average Art&Animation is 71'000$ US for a job that doesnt even require a college degree. I dont know a lot of artists outside of game development that earn those numbers. Well, I never suggested it was non-profit. But, when there's newbies out of school who will take $30k to get into gaming or $60k for non-gaming, the gaming companies get used to underpaying. I'm not specifically referring to artists, because I'm not familiar enough with what artists get outside of gaming; it's very possible they do as well or better in gaming. However, this is definitely not true for developers. As far as the stigma, I'm not saying game development pays like crap. But it does pay below the competitive average for most industries. Compare it to finance; not even close. Considering that game development can be among the most challenging types of developer roles, the salaries don't really match where they should be. The reason why the stigma sticks is because there's some truth to it. I'm happy for you with your personal situation, but yours is the exception, or maybe the situation is just better in Canada.
  3. Reducing game development costs

    Quote:Original post by Steadtler Quote:Original post by Rydinare You read numbers like that and it just reinforces the fact that the gaming industry pays way too low in comparison to other industries. I dont follow you. Why would high money spend on advertising means that the game industry pay less than other industries. Advertisement budget has nothing to do with salaries. You think the movie industry doesnt spend on advertising? What was the advertisement budget on Windows 7 ? They spend on advertising because they get a good return. Advertisement works (sadly, people are easy to influence). Besides, check the latest Game Developper report. The game industry pays really well for -qualified- people. I myself nearly doubled my revenue when I went from programming robots to programming games. I dont get why so many people in here are trying to downtalk our industry so much. Okay, well first, I think you may have read more into my post than what I actually said, so let me elaborate. I've worked in the gaming industry, so first, I've experienced this before. People are willing to take considerably less to work in a gaming job than other jobs, despite often having more hours. Is this true for every gaming company? Probably not, but has certainly been what I and others have seen. In my experience, the salary reduction is often anywhere from 10% - 30%. True everywhere? No. But, it is common enough to be noted. This has nothing to do with being qualified, in my experience. Paying well and paying competitively well are two different things. I would say that your success in doubling your salary is not the norm. As for advertising, it simply follows proportions. If the company is spending only 20% in development, then raising developer salaries 10% is almost negligible. The 10% salary boost would only increase total costs for the project 2%. Simple proportions. Overall, seeing that so much is being spent on advertising when at many shops, developers are spending most of their lives working through the project and getting paid subpar salaries is kind of disturbing to me.
  4. Reducing game development costs

    You read numbers like that and it just reinforces the fact that the gaming industry pays way too low in comparison to other industries.
  5. Who uses QT?

    I'm pretty fond of Qt, overall. It's certainly light years ahead of libraries like MFC. It's pretty simple to use and you can do a lot of great things with it. The only nuance for Qt is what I think holds true for most third party libraries. It's going to provide you a wider range than what you might need: For example, Qt also gives you its own containers, string classes, XML parsing facilities, etc... Qt's facilities are pretty reasonable, but at the same time, I think it's important to be cognizant of vendor lock-in. So, for example, I only use things like QString in code that's specific to a Qt GUI. If not, I use STL string or wstring. This reduces the vendor lock-in effect.
  6. Major Rewrites - how do you go about it?

    Quote:Original post by Washu Evolution. Not revolution. I like. Short, sweet and right to the point. I have to agree with Washu here. I've gone the major rewriting route before. The problem is that unless you rarely have or expect to have enough time and/or motivation to do it all over again. Getting a perfect code base will never happen unless you have infinite time and nothing to ever distract you from the goal. Instead, from experience, I'd suggest it's better to refactor. In other words, only change code when you have a problem that you're specifically trying to solve. When you refactor, you change only enough to make your goal achievable. When you clean it up, you know you're taking a bit of a time hit this time, but the next time you need to add feature X, you'll get the benefits of the work. Slowly you can evolve a codebase in this manner. It's true, you'll rarely clean up 100% of the code base, but at least you'll have results. I will also say that refactoring is one of the most difficult things in software engineering. Many people can design systems that "work" (note the quotes), but a lot of people have trouble designing systems that are maintainable enough.
  7. I listened to the whole thing. Very impressive, good stuff. Thanks for sharing it.
  8. Infinity Ward v. Activision

    Quote:Original post by Calabi Quote:Original post by frob Quote:Original post by Calabi Well thats the thing, I think, the bonus's paid to developers are usually contractual. Its not a discretionary payment at the whims of their boss's its an agreed on amount after a certain amount of sales or something like that. Surely this be a game development forum, someone should know about this? I have never worked at a company where bonuses were contractually specified, or where rank-and-file employees were able to demand it. I am in the industry and have seen quite a few contracts. There was a time, decades ago, where royalties were sometimes specified with employment, but those days are long gone for rank-and-file workers. Now days it is generally not contractually guaranteed, but often offered. It may be based on some formulas about how well the company is doing along with an individual modifier assigned by the company. This allows star performers to get a bigger bonus and poor performers to get a small bonus or even no bonus, at the boss's discretion. Fair enough, I guess that means West and Zampella, are screwed then. I don't know about that. Everything posted is just speculation. Nobody really knows the truth. Also, the sorts of bonuses people are talking about here are paltry in comparison to the type of bonus that West and Zampella were set to receive. There are certainly examples in legal history where the judgment has come down with exorbitant amounts to discourage immoral business practices, if that's what this was. I say let's just wait and see. I'm not going to make a prediction, because I could foresee scenarios where it could go either way, and without having all the facts, it's hard to know what the real situation was. Besides, most cases are settled out of court anyway. That's probably the most likely outcome, actually.
  9. Quote:Original post by jwein Ah, it's true. I should have said interface and not abstract class :-) Quote: If you're derived from an interface and all members are in the derived class, what's stopping you from initializing everything in the derived constructor? I guess that is the part I don't understand. It's because I tought it would have been more correct to provide a sort of template to let people write the derived classes, because parameters for the pure virtual functions are specified, but it's not the same for the parameters of constructors. However maybe I have a wrong idea and the constructors of the derived classes don't have to necessarily present the same parameters. My project is still growing up and I don't really know the kind of problems I'm going to meet :-) Ahh, I see what you're getting at. I remember thinking of virtual functions that way a long time ago. But really, it would be better to think of virtual functions as ways to implement polymorphism, not so much as a cookie sheet for what methods a derived class should implement. Just my two cents.
  10. Quote:Original post by Sneftel It's always a pain having to remember which version of VS (including service pack!) I need to use to develop for each version of Max/Maya/Gamebryo/whatever. But it is TEN TIMES as much pain to deal with certain middleware packages which have, for ABI-agnostic shits and giggles, reimplemented virtual function binding and discarded traditional RAII and standard library classes. ABI problems are annoying, but then you get them right and they stay right. The workarounds are infinitely worse. No arguments here. It's why I dislike the use of COM in C++, unless it's utterly necessary, because most C++ paradigms are broken in COM. But, that being said, COM had a broader purpose. If you simply want to wrap custom classes with a C-API underneath and serialize the rest, I think it can be ok.
  11. Quote:Original post by Yann L Quote:Original post by Rydinare Well, the problem can go deeper than that. For example, a standard class, such as std::string has been different between versions of the same compiler and different for debug and release builds, which causes problems. Namely, it can blow up if created in a module that "sees" it one way and then if used or deleted in the other. It's very easy to violate the one-definition rule across DLL boundaries. Of course, there's solutions for this if you're always using a version built with the same settings and libraries. Well, it depends. The main problem is DLL-boundary memory and resource allocation. But this can be solved in many different ways. Also, under Windows at least, each DLL is a separately compiled unit. Internal symbols are resolved at compile time, and only symbols that are explicitly exported are runtime linked. This is different under Linux, btw, which will always runtime bind everything, even internal dependencies. This is a major pain in the ass when developing plugin systems for Linux or OSX. Anyway, if you're careful, then the CRT versions don't have to match 100%. You can, for example, debug a plugin (compiled as debug, linked with the debug CRT) while it is running as a host on a release application (compiled as release, linked to the release CRT). Good points. I was referring to a specific case, in the case of STL containers, starting with VS 2005, there is extra storage used for debugging purposes, so if you're using STL, you can no longer mix debug and release builds even from the same compiler version, which is obnoxious.
  12. Quote:Original post by jwein Rydinare, your example is very similar to what I was saying, but I define interfaces as classes which don't have any member variables, so I couldn't provide constructors in the base class because I don't have a string member in the base class but only in the derived ones... Ahh you said abstract class in that last paragraph, so I didn't realize you meant interface. If you're derived from an interface and all members are in the derived class, what's stopping you from initializing everything in the derived constructor? I guess that is the part I don't understand.
  13. Quote:Original post by jwein I was thinking in this moment about the case you suggested. Should I initialize in the constructor even if the class derives from an interface? I have, for example, an abstract class Effect, which represents a wrapper for the Directx effect class. The abstract class (interface) requires the filename of the .fx effect file while the derived api-specific D3D10Effect class requires two directx objects, too. I can't obviously define a virtual constructor. What should be the best way to go? class Effect { public: Effect(const std::string& p_effectFile) : ... initializer list ... { ... some creation logic ... } }; class D3D10Effect : public Effect { public: // Calling the DirectX objects DXObject for short, don't know what you're actually using :) D3D10Effect(const std::string& p_effectFile, const DXObject& p_object1, const DXObject& p_object2) : Effect(p_effectFile), ... other initializer list code ... { ... creation logic ... } }; Edit: Now having said that, I realized it's possible you may be referring to a object cloning or factory mechanism. Let me know if this is the case.
  14. Quote:Original post by jwezorek One case I can think of in which you would want to defer initialization is if you want to make the initialize() function virtual i.e. you can't have a virtual constructor. True that you can't, but what purpose does that serve? The constructor has to call a base constructor, either implicitly and explicitly, anyway. Unless you're saying all of the base constructors don't apply to how you want to create the object, but then I'd be concerned that you might have an improper object hierarchy. Can you give an example of when you've found this useful?
  15. Quote:Original post by Yann L Quote:Original post by Markie Or should I just go with pure C++ (perhaps that's just easier in the long run) and forget about cross-compiler and cross-platform compatibility? This. Quote: (But then, that seems to negate a big part of what's so cool about plugins, namely that EVERYBODY, no matter what compiler he has, can create and program an add-on...) Who cares, be pragmatic. Don't make your life miserable ("C objects"...) just because of a few who don't use the main compiler for a given platform. Just tell them to use MSVC on Windows and gcc on Linux or OSX. Problem solved. A lot of professional software does it this way. Well, the problem can go deeper than that. For example, a standard class, such as std::string has been different between versions of the same compiler and different for debug and release builds, which causes problems. Namely, it can blow up if created in a module that "sees" it one way and then if used or deleted in the other. It's very easy to violate the one-definition rule across DLL boundaries. Of course, there's solutions for this if you're always using a version built with the same settings and libraries. I wonder if there's a library that does kind of what SWIG does, except using a C interface to bridge C++ DLLs instead of using the C interface to bridge between languages.