Misantes

GDNet+ Basic
  • Content count

    324
  • Joined

  • Last visited

Community Reputation

2092 Excellent

About Misantes

  • Rank
    Member
  1. Regarding Frob's comment: That may be how you intend to enforce the new rule, but it reads literally as :   (under problem topics): Discrimination (most commonly racism and sexism)   New Rules: No new discussions are to be started focussed solely on these topics. Any such discussions may be closed or removed without further notice. To anyone who isn't a moderator with access to how you intend to enforce the new rules, this states pretty clearly that the topics of discrimination, sexism and race are not to be discussed. I don't want to be repetitive regarding my early comments, but if this isn't your intention, this should probably be clarified. Again, if it's racism and sexism that you intend to be disallowed, why not just state that? The way the rule is stated now, you're sending a very different message to the community.   If you want to foster a welcoming environment, you may actually need to take a stand and enforce a welcoming environment.
  2. I'd say it depends on the game and different things. If you're setting up your own engine, you may want to implement various types. For static objects, using lightmaps or baking the shadows in the texture can be an easy and cheap way to implement shadows. If your game world is large, you'll likely want cascading shadow maps, or various other methods that handle large worlds better. If you have lots of light points, you'll want a different approach, etc, etc.   I'd start by examining what your current game would make the most use of, and implement that (or if you're just writing an engine, just start with your standard shadowmap and then go from there. They're tricky to implement at first, at least they were for me). For a robust engine, having the option of different shadow styles can be really handy, as different scenarios will call for different methods of shadow creation. But, this is also quite the work load to implement.   So perhaps just dig in with standard shadow maps, unless you're working on a game that has specific shadow needs.
  3. I recognize you're trying to do the right thing here, and that your intentions are good. And, I recognize moderating is rarely cut and dry, often subjective, and rather difficult. And, the toxicity that some threads have been reduced to is definitely something to want to avoid and bad for the community. And, as a stopgap measure, the current actions are understandable.       My apologies, but I kind of don't see a way around this, other than the blanket ban as this community is just far too large to hope that everyone is just civil. Perhaps clarifying the guidelines so it's not such a personal call. On a fundamental level, I see three options: 1-you can either let no one discuss these issues, or 2- let healthy and civil discussion happen and pass some judgement while moderating the discussions, or 3- go the free-for-all route and not moderate anything. Ideally, I'd say you'd probably like to cultivate civil discussion on these topics, as they are pertinent and important to a lot of people, which really only leaves option 2. To make option 2 more palatable and obtainable, I'd say you need to evaluate and decide what guidelines for behavior are acceptable for everyone and least discriminatory. Make them really clear. And, then enforce them, however imperfectly.   And, I'm going to be quiet now, as I've posted way too much on this thread. I'd just urge to consider that while the toxicity is bad for the community, the topics themselves are important, and to try to find a solution that encourages the latter and minimizes the former.
  4.   I don't mean this as tongue-in-cheek as it'll come across (or hostile, but I have a dry presentation and I could see it coming across that way), but isn't that the point of moderation and having guidelines? You lay out the guidelines and people obey and stay, or don't and leave? I don't see how changing the guidelines alters that dynamic. You're just enforcing a different set of guidelines now (an even broader one, I would say). The widened ban to include any topics on race/gender seems like it would be more difficult to enforce, and as I mentioned, I think that actually serves to homogenize the culture. Additionally you'll be faced with now enforcing those guidelines on otherwise respectful and well-intentioned people (see: earlier comment regarding a hypothetical post addressing issues facing minorities in the game industry). You also mentioned that you "arbitrarily ban those who misbehave," but I don't think that's quite accurate, as the ban aren't arbitrary, but due to offensive behavior (behavior that is against the guidelines). Anyhow, I don't see how enforcing behavioral guidelines would be considered discriminatory or homogeneous, unless the guidelines themselves were.       It seems like instead you've just bent the guidelines to accommodate people who can't keep reprehensible views to themselves, at the risk of pushing away others who may actually have productive, respectful things to say regarding race and gender within game development or who might actually find those topics pertinent and relative.   Any guidelines regarding behavior are a form of censorship. But, I'd argue that outlining acceptable behavior within a community is completely valid for any community whose membership is voluntary. It's certainly not a violation of anyone's rights (you're not the government). Anyhow, as moderators, you have the ability to shape what type of community this is, and the guidelines you set and enforce determine the outcome.   I guess the easiest alternative I could propose is actually enforcing the previous guidelines, and creating a space where everyone is welcome and can discuss things like adults, provided they're not espousing views that reprehensible, hateful or alienating others? But, as you mentioned that wasn't working out, as moderators seemed reluctant to enforce the guidelines and risk the blowback and anger from doing so (also due to borderline behavior, but I would think issuing private warnings could alleviate and course-correct much of that). I couldn't propose anything that didn't involve the moderators enforcing respectful dialogue between members. But, it seems like you've decided to blame the topics rather than the problematic people and views. The topics, I think, are important and relative to game development, whether or not the moderators are able to enforce civil discussion. Maybe just really clarifying what the guidelines are, after crafting them carefully to be inclusive to everyone, and then enforcing them (it doesn't have to be a 1-strike implementation or anything. Behind the scenes moderation can go rather far, sometimes), I think would be a good approach. Ultimately, any time you're dealing with a large community, you'll have your share of problem people. There really isn't a way around that.      As a suggestion then, I'd propose making sure the guidelines are clear on not providing a platform for discriminatory/hateful language and opinions.     I didn't realize this was a stop-gap measure, so my apologies. I assumed these were the new guidelines. Stopgap away   **to note: I totally understand moderating is extremely difficult, and I don't envy the position in the least. It's not something I would want to do, and I don't mean to oversimplify or be too harsh in my criticism of the moderators here. The current solution just seems to be rather broad, and have some unintended consequences to the community, and in my opinion, probably won't really resolve the issue in the long run. Anyone who ignored the previous guidelines will likely ignore these as well. Anyhow, respect where it's due, I think in general, you all often do a really good job, and the forums are more or less civil, and I recognize I'm armchair-quaterbacking here, to a large extent.
  5. The discussion of game development absolutely includes discussions of gender and race (they might not concern you, though). And, to outright ban discussion of these topics is to say to individuals in those groups that their issues within the game development community are unwelcome.   For example, if one were to start a topic on finding a job in the industry, then great, no rules broken. But, if one were to try to discuss the issues facing women or trans women or a person of color finding a job in the game industry, suddenly you may be breaking the rules for discussing one of the banned topics. This would absolutely be a game-dev concern for many people, and is only a "fringe" issue if it doesn't affect you. But the policy is basically telling people that there's no place for those concerns here.   Because certain elements of this community are unwilling to have a civil discussion regarding these issues, to outright ban the topic, rather than the person, is really ceding victory to the unruly elements. And this site really becomes only welcoming to anyone who isn't considered part of the "problem" minority groups.   There is plenty of discussion on this site that is not "technical" in nature, so pretending that the discussion is limited to that is misleading, they're only banning the topics that have loud, hateful elements, and instead of dealing with those elements, they're just banning those topics, to the detriment of anyone who may be concerned with them.   It's easier sure, and many people who aren't affected by these discussions will be perfectly content. But, it's a large disservice to many other people.   You can ban racism and sexism without banning discussions of gender and race. The latter approach only helps ensure that the industry largely stays its current predominantly-male, predominantly-white demographic.
  6. While I completely understand the need for moderation, and the reasons for the current rules, it does feel a little like sweeping issues like racism and sexism under the rug, which I'd say is detrimental to a healthy community. Refusing to allow discussion on the issues facing women, people of color, transgender individuals, and others in the game industry seems unfair to those groups and feels a little like pretending those issues don't exist. Which, while moderation becomes easier, you could see how from the perspective of someone within those minority communities, calling out any unfair behavior to yourself in the game development world would suddenly be against the rules. If the issue is hateful speech from members, I'd say a better approach would be to apply rules on hateful speech, and not gag the people you're trying to protect in the process.   Anyhow, my two cents. But, as I see it, blanket-banning discussion of discrimination really, in the end, protects the people doing the discrimination.   I understand the issues with these topics, and the difficulties moderating them, and while other solutions are imperfect and this solution seems cleanest from a moderation standpoint, I'd urge you to consider the wider impact of such a policy, and perhaps try to find a better answer that doesn't silence the people being affected by such topics.
  7. Unity Unity or C++?

    If you're set on Unity though, perhaps consider picking up C# (or Javascript). Syntactically, C# is rather similar to C++, and for scripting purposes, is fairly painless to pick up (currently going through this process myself, from C++). Depending on your goals though,I wouldn't abandon C++ entirely, or move wholly to a game engine (using and learning the engine is fine, I'm suggesting not entirely abandoning your process of working on smaller projects without them, as there's a lot to be learned down that route).   As far as what Unity handles, much of that is up to you. But, it's capable of handling most of your rendering processes, physics, input, sound, even pathfinding and AI and such. You can get by with very little scripting, other than handling how game objects interact with each other, or you can code most things yourself. It's pretty flexible.   Regarding employment and Unity/C++, I've no experience in this, but I imagine it depends pretty heavily on the requirements of the position available :P 
  8. For blender, in the dope sheet / action editor, make sure your  animations are saved separately, and push them down to the NLA editor. I've had some issues with unity not recognizing some of them, but that usually does the trick for me. Also, when adding new animations, don't save the .blend to the same file but make a new one, if you've already added it to the project. (Unity, at least for me, doesn't add additional animations when I try to overwrite the existing blend file).   Anyhow, apologies I don't have an answer to your original question, but hopefully this will help.
  9. This doesn't quite answer your question, but have you just tried dragging your blender or maya file directly to Unity3d? I feel you may be over-complicating things.    Anyhow, Unity3d does support just importing directly from blender/maya. It ought to have all of your animations/materials etc included (though you will need to drag the appropriate material/texture onto the object in the scene). Then use the animation/animator panels to set things up. The animations will be included (expand the maya or blender project in the hierarchy to find the animations).   Just place the .ma or .blend file into your assets folder. The nice thing is you can edit them and Unity will update automatically. http://docs.unity3d.com/Manual/HOWTO-ImportObjectMaya.html http://docs.unity3d.com/Manual/HOWTO-ImportObjectBlender.html
  10. The only thing I'd add to the above responses for opengl is to make certain that the resources you're using are for modern opengl (~3.3+). If you're using online resources (or offline ones as well, I suppose) you'll save yourself a lot of confusion avoiding older tutorials as many methods for drawing (and otherwise) changed rather drastically post-3.3. Offhand, I believe the nehe ones are mostly outdated (though, still contain a lot of useful information, just be aware).   Personally, I found http://www.opengl-tutorial.org/ to be the most useful, along with the official opengl reference pages.
  11. I like Mondays, and yet I hate weekends.

    To be fair, that headline seems to miss the content of its own article The two categories being "Not engaged" and "actively disengaged." Ultimately, 13% of workers feel "engaged" at their job (which still is a far cry from 'loving what you do.'   My genuine apologies for the nitpick But, 30% just seemed remarkably high.
  12. From the website, you have 3 options.   The first, using the build in the repositories, doesn't work for you since you're on the old lts and want the newer version of SFML. While, there are certainly valid reasons not to upgrade to the newer Ubuntu lts, if you're able, I'd suggest upgrading to 14.04, if only for access to updated programs, including sfml 2.1 (and lot of other reasons. I mean, it's ostensibly free, so, provided it works with your hardware, why not? I realize the real world has complications though. Maybe it's not your computer alone, maybe it's a work thing, or doesn't work on your hardware, etc. etc).   The second, downloading the premade builds, is actually pretty nice. Everything is built for you. You just unzip and copy the files to your system. If you're still having issues with this route, you may want to narrow your question down to how to use SFML with your IDE/editor of choice.   The last option is building it yourself. Which isn't that much more difficult (if this is your first time building a package like this, it can be confusing, but stick with it and you'll eventually get through it. It eventually becomes rather easy, and if you're going to be programming on Ubuntu, this will decidedly not be the last time you need to build something), but does require you to know how to build it. The sfml page on this is pretty good, but doesn't go into detail on how to install the dependencies, if you're unfamiliar with that (I recommend using something like the synaptic package manager for installing these, but it can be as simple as typing in "sudo apt-get install "name-of-dependency-dev"". But, it's possible to run into some issues if you're not careful. Personally, I like using cmake-gui to run the cmake files, and don't have a lot of experience with the other methods. I won't go into details on this choice, if only because it would take a considerable post to describe properly, and the aforementioned site goes into enough detail. If you did download the SDK and would like help knowing how to build it on Ubuntu, just clarify, and we can try to walk you through it (though, it's the same process for building anything on Ubuntu, and the internet is full of guides on this. Just use the list of dependencies on the sfml site, and any other guide to building an sdk will be sufficient, in all likelihood. I'm genuinely not trying to be snarky or unhelpful. But, it's a complicated process that I wouldn't do any better job explaining than the sfml site, and/or the dozens of people on stack overflow who have answered it).   Anyhow, I recommend you clarify your question a little. Which sfml version did you download, the prebuilt one or the SDK? What have you tried so far, and where exactly are you getting stuck? Are you going to link dynamically or statically? I'll do my best to check back for your clarification (I sometimes forget to follow up though, so my apologies in advance if that's the case ). If you need help building the SDK from scratch, I really do recommend you follow the sfml site's instructions on this, and googling anything they're vague on, and then asking here if you get stuck at any point, with a specific question of how/why you're having trouble building it. It's difficult and confusing at first, but you'll get through it   Edit*  going over your other post, it looks like you may just need to configure code::blocks to find the sfml files properly. You need to make sure to link correctly, and in the project options, make sure you configure which folders code::blocks will look for the libraries and headers.
  13. How can I use sfml with codeblocks in Ubuntu ?

      It is very far behind. Ubuntu 12.04 has SFML 1.6 in its repositories, whereas the current version is 2.3. I have already tried this 1.6 version but it was totally messed up. The syntax of its functions were very different from the new SFML versions. So I downloaded the latest SFML for linux, placed its header files in usr/local/lib and placed the modules in usr/local/include, which are the standard locations for installing libraries. Now it is giving me these undefined reference errors in code::blocks, and also when I compile and run from the terminal.   Ah, I was anticipating you were at least using the latest lts (Ubuntu 14.04). I believe that's been updated to 2.1 for awhile now, which isn't the latest build but also not that far behind, feature-wise.