Aspirer

Members
  • Content count

    149
  • Joined

  • Last visited

Community Reputation

544 Good

About Aspirer

  • Rank
    Member
  1. Well, what brought it up was reading up on using lists in Unity, and their example was    List<T> myList = new List<T>();   To me, it should be a no brainer, "Hey, I said myList was "List<T>" so it should probably be a "new List<T>"
  2. I tried google, but can't find a good way to ask this question... lol   For instance:   myClass anObject = new myClass;     Why do you declare a myClass, then specify "new myClass"   In my mind, it's the same as: int myNumber = new int.   "No shit, it's a new int! If I wanted a f***ing float, it woulda said 'FLOAT myNumber'!!!" If I wanted a "new yourClass", I would've typed "yourClass anObject"         And for that matter, what would be a good search phrase to find info on this, cause "why double declare class" and "why declare a class instance as new" and all the related phrases that come to mind don't turn up a damn thing....   Thanks, cause this is really bugging the shit outta me.
  3.   Which makes it identical to choosing a language--choose the one that most applies.  If you want cross-platform, C# is less applicable than C\C++.  Want a simple, single player web-game?  JavaScript is probably more applicable than Ruby.  If you want a mobile game, Objective-C is probably more applicable than Python.
  4. Feel free to expand on anything that may help.
  5.   If I don't like an idea, I will tell you.  Generally, I'll automatically tell you why.  (If not, then ASK me)....   It's then your job to explain to me how I'm wrong, or why my thoughts/worries/dislikes do not apply to your situation or can/will be avoided.  If I don't like your idea because it reminds me of Halo and I hate Halo (true story), explain to me why your game isn't like Halo.  If I think your idea is a re-hashing of a failed idea or one that's been done N-teen times in the past, explain to me how your idea is original.   In other words, it's not MY job to convince me I'm wrong--that's all presentation is good for, making me change my mind.  It's the substance of your argument/sales-pitch that will waver me.  WHAT you say, rather than HOW you say it.   My stances are generally from an artistic point of view, including my ability to relate with your idea, if applicable.  In other words, if I think your RPG idea is a plainer-than-vanilla game, but the characters/story is relatable or intriguing, I would want to be a part of "a game with an amazing story."  If I think your game is a re-hash of Tetris, but it's well themed, and the pieces fit without forcing them, I'll want to be a part of "a cleverly thematic game."     So, your GAME'S presentation can sell me as quick as content, usually quicker.  A DESIGNER'S presentation will never sell me as well as the content...
  6. the importance of understanding theory?

      This I think is true only for the most simple things, but the more complex you get, the more likely it is to end badly....   Playing with a television remote before understanding how to use the remote-- Okay Microwaving things before knowing what happens when you microwave metal-- Potentially not okay. Driving a car before knowing how to drive a car-- potentially less okay.
  7. Lord, Highness, Alpha and Omega areare some of my more preferred titles. I've not worked on any group projects, so as I handle everything, I prefer developer.
  8. I've seen one sketch program in the Google play store. It made me wonder if any of you used them, if they're sufficient to do indie developer needs?
  9. Do you believe it's important to understand the theory behind your applications? For instance, using state machine to control animation. Unity uses a graphical representation of it to help set your animations. My understanding of what a state machine even was, was nil when I started, but I still managed to use it correctly without understanding it. I have a habit of needing to understand those things though, if just for peace of mind, so I learned a bit about it. Its not rnoiugh for me personally to understand "this works," I need to know "why and how does this work?" Any of you feel that way, or do you feel that its pointless to research theory so long as you manage to accomplish your goal?
  10.   I'd like to know a bit more about this...  I honestly had considered trying them, and hadn't heard anything like that before.  (Obviously, I never thought I'd have to see if that was an issue, though...)
  11. Unity Unity Engine

    I've used Unity for a couple projects.  The pro's to Unity are pretty obvious and have been listed en masse by the above people.  Here are the cons, as I've seen them.     --NavMesh's and NavAgents are unavailable in the free edition.  This means it's up to you to code your own pathfinding in a 3D environment. --Point lights are a bit awkward.  If I put a point light up in a building, I can see it illuminate the ground outside the building for some reason. --Dynamic shadows only available via one directional light in the free version. --MecAnim system is a little touchy, in my limited experiences with it.  Your 3d models and armatures have to be correctly positioned for it to recognize them when importing.     Now... ask  yourself, how many of these cons even apply to the game project you're about to do?
  12. '     I'm not nearly as experienced or knowledgeable as the gentleman above me, but I'm sure he would agree: if you just barely decided to do "a little game," then neither one are probably going to help you as they're both loaded to the maximum with features and abilities that most people who are just starting game developing and wanting to do a small project would find over-powered and unnecessary.  Not to mention it's not considered really user-friendly from what I've seen/read in comments (unless you've got a fair bit of experience in game development.)     With that said, I also take the stance "which game engine is best" == "which programming language is best"...
  13. Just found out Unity's NavMeshes, etc. aren't available in the free edition, so I'm going to have to take to pathfinding the old fashion way--coding it myself.  This is going to be an entirely new endeavor for me.    Any advice?  Like things to avoid doing, what topics are basics/which are advanced pathfinding topics, what I should definitely have an understanding of before jumping into it (theories, programming aspects, etc.)?       Also, just out of curiosity, is this the hardest part of AI programming? If not, what do you think is?
  14. You definitely should remember a couple things though...   1) You're part of a generation who in general couldn't tell you the difference between your/you're, there/they're/their, or to/two/too... 2) You're part of a generation who in general would spend 15 minutes writing a text, than making a 3 minute phone call... 3) You're part of a generation who in general gets all their knowledge and opinions of world-events through Facebook...   So don't expect those people to be able to hold a remotely intelligent convo for more than about 90 seconds.