Jump to content

  • Log In with Google      Sign In   
  • Create Account

Dan Mayor

Member Since 14 Jan 2011
Offline Last Active Oct 22 2016 01:35 PM

#5026135 Beginner Programmer, understands C++ but doesn't know where to start.

Posted by on 27 January 2013 - 11:48 AM

I believe that the most important thing to do in order to get started on designing a game of any sort is to write out a complete game design document.  Something that explains the mechanics, story boards (if applicable), level progression, character progressions and general flow of events.  This in itself will then give you the questions to ask and provide a guideline of the solutions you will require to achieve your goal.  Your game design document should be fairly large (spanning at least a few pages even for the simplest of ideas.)  You want to focus on defining what the game is completely, imagine that your game design document is being given to someone that know's what a video game is but has never played a platformer, side scroller or 2.5D game.


The key notes you want to address in the game design document are "what platform am I targeting " "what is the game about?" "how does one play the game?" "how does the game start?" "what can the player do?" "what does the player do throughout the middle of the game?"  "how does the game end?"  "why does the character do what he does in the game?" "how do controls work?".  Expand on these with as much detail as possible.  The point behind all of this is that it will start letting you address individual aspects of the design in such a way that you kind of set up a road map all on your own as it relates to you'r project.


Some examples, "What platform am I targeting?" this in itself now gives you the question of "What engine or libraries do I use?  What hardware API is available (Direct X or Open GL) and what should I learn next?"  "How does one play the game?" Will get you to start thinking about how to build your framework to support aspects of your game.  In the idea of a 2.5D sidescroller / platformer you already know that you will be looking at basic collision, basic dual axis (2d) movement systems, running and jumping support.  If it turns out that there will be some beat em' up aspects of the game you know you will need to add in support for combat / attack animations, health, strength and defenses and so on.  As you continue down this road you will start getting to more and more specific questions, questions that later can be answered using a Technical Design Document.  As you go through the process of writing a technical design document you will further narrow down exactly what it is you need and what order you will work on these things for.


In short there is no standard work flow or road map to game development, each game requires it's own unique technologies and functionality.  Granted most games follow a similar path where you start at the bottom building framework that could support the methods and properties you would need to get the game up and running but how you get those going and where you put them is very dependent on what you are doing.  Your game design document and technical design document turn in to your guide on where to go.

#5025830 3d models

Posted by on 26 January 2013 - 12:51 PM

<fanfare> Here comes captain obvious!


A model file in itself is simply a definition of rendering data.  That is to say that when you export your model to "whatever format" from 3DS or any modelling program for that matter it saves a file that defines where the vertices are in relation to a specific point (eg 0,0,0 of the model itself), the relationship of the vertices (how to wrap them to make triangles) texture information, UV mapping and so on.


Now every file format can be a bit different in what it contains and how it contains said information but the important part to remember is that by some means you are simply loading the information from the file into memory (video or ram) for use by the video card.  Once loaded the information is identical to what you would manually put in by code.  There are different libraries that expose different means of interacting with this information after it is loaded in to memory and in my opinion this is where you want to base your decision.


"What file format contains the data I need?"

"What library / method loads this information in a way I am comfortable with?"


The programming language is simply the means of doing this, the library is just the previously written code that makes it easier to do this, the file format is just the way that this information is stored on disk.  Know that and you are a little better equipped to move forward.

#5025594 Pushing objects

Posted by on 25 January 2013 - 05:28 PM

You want to provide more details and information.  In short all we can do right now is say "When the two objects are touching have them move together".  You might also want to take weight into account and slow down the movements to simulate the first object struggling to move the second.

So say A is pushing B. If A is coming from the left, upon collision it will push B to the right.

If A is coming from above, it will push B downwards.


Without counting physics into the mix yes it's that simple.  I was trying to point out that your post is to vague to hold a real discussion about.  We don't know what the problem is, we don't know what you did.  With lack of any relevant information all we can do is guess that you don't know how to detect the collision?  You can't figure out how to translate two objects at once?  What's not smooth, have you somehow poorly calculated the movements resulting in frame loss?  Are you unsure on how to apply the same movement vectors to the objects?


In short what I was getting at is don't be so vague.  Tell us what language you are using, what engine you are using what is happening and what the expected result was supposed to be.

#5025593 How long would it take to...

Posted by on 25 January 2013 - 05:21 PM

That's not what I use it for (nor what the article actually says, if you ignore your knee-jerk reaction to the title and really read it).


I don't think this article should be used to smack people in the face who want to write an engine and I don't think it should be put on any kind of game development pedestal.


I'm merely pointing out a trap a lot of newcomers fall into, and sure, if the OP is purely looking for a learning exercise, then no one will stop him, but it never hurts to inform. If the OP had asked about "a primitive, but functional 3d game, something on par with say, the original QUAKE or Half-Life 1" I wouldn't have mentioned it at all...


I have to agree with you on this one swift coder.  People need to be made aware of complications and heart aches of what they are getting in to and they need to weigh those equally or even more so critically than the idea that things are easy.  I seem to have been on a rampage of "Game Development is hard!" today (probably just gripes coming up from a difficult week) but it's still something VERY valid to say.


Engines power games yes, games can get very complex and time consuming yes.  This is my big argument when it comes to building games and engines together.  Simply put engines are extremely complicated maybe even the most complicated things that are ever coded.  Games can also be complicated and in some cases just as complicated as building the engine they are powered by.  This is why to me it's NEVER a good idea to do both.  If you want to make an engine just to learn things and your making a game using it just to see how it all ties together, great!  If you want to make an engine that other people may actually use is another story all together.  You will need to invest LOT's of time on making it high performance, easy and providing a wide range of tools.


Game content, development, coding and logic are also complicated and at times can take quite a large time investment.  Same as with the engine if your just doing the game to learn how things work and your coupling it with the development of a simple engine GREAT!  However if you want to get other people to actually play your game (not just test it for you but actually play it) you need to put in some effort and make it worth playing (keep in mind there is a lot of competition out there and tons of really good games).


So here's where I jump in on the argument between making engines and making games.  Both are required and both have nearly equal importance to each other.  That is to say without better engines we don't get better games.  Without better games we don't advance the engines to power them.  However when we get into the world where everyone builds their own engine and their own game at the same time we completely negate the first statement of this paragraph.  You build the engine to power your game and you build your game to run well on your engine and neither receive the proper attention that they deserve!  So my opinion on this whole thing is the more people try to do everything the more nothing gets advanced.  To me the argument isn't saying you can't build an engine it's that it requires just as much if not more dedication than the game itself.  As independent and or a small game studios we simply can't afford to take a year and a half to make a half way decent engine followed by another year and a half to complete the game itself and by the time we hit the shelves we're 2 - 3 years behind all the competition in performance and quality!  Even the larger studios that do build their own in house engines to go with their games have two different departments.  One focused entirely on the engine itself and another focused entirely on the game itself.


So if it's just for hobby then writing an engine is perfectly fine.  If there's any concern for profit you need to compete with the big boys who are dumping money into the development of their engines by the truck load.  Your one or two people working in your spare time you'r not likely to ever get on par with them.  However making a game with two or three people can be profitable...  Make a few games and get some money coming in first then take your experience and knowledge from making games and apply it to making the engine that powers them.  When you do make that leap into making the engines make sure that those involved are dedicated to just that and not the both at the same time (otherwise you will end up cutting corners and sacrificing performance and tools that will lead to loss of money and less chance or sales).

#5025587 Need help on how to write out a TDD to make a budget

Posted by on 25 January 2013 - 05:04 PM

I normally take the nay sayer side of discussions as I try to get people to keep their head on without getting lost in the clouds thinking that this field is easy but I think I'm actually going to be the nicer guy this time (for once).  In short there's two ways to determine time estimates on coding and audio projects.  The first is to get someone you trust and can rely on that does these things and ask them "How long do you think this will take?".  The other way is to do extensive research on similar projects, time frames and number of people involved on the project.  However I would say that this second method is riskier ground.  Using this method where you set the deadlines you lose interest of many people who fear not making the deadlines.  At this point to keep people interested in meeting their deadlines you're going to have to pay them regularly.


I say this because I personally am a freelancer programmer and this is one of my picky points when I consider which projects to accept and which ones to decline.  I'm very lucky in that I have gotten to a point where I get multiple offers and I can be in this position, however it has molded me to just not be interested in something that I think the project coordinator has underestimated the time frames.  That is to say if I think it's going to take 400 hours and the deadline is 2 months, I'm probably not interested.  The only way that I would commit myself to something like this is if the payment is well worth it (double what I would charge if I had 4 months to do the same project).  Simply put the more demanding you are the more of a professional you need.  A true professional treats his deadline like his life, he will never lose it!  Now what if I was wrong and it's going to take 450 hours?  I have to cram that into 8 weeks?  That's a little over 55 hours a week that I have to dedicate to you'r project.  What if I have other clients with emergencies that I have to attend to?


So a little secret I would suggest is to go to a freelance hiring website, register a free account and post your project.  Get quotes, find the average and throw out all of the bids under that average.  Take whats left and average those out again.  Use that as an idea for a realistic time frame / budget that you'll need.  I say to do this double average method because you will undoubtedly get untalented / incapable individuals bidding and just cutting prices to try and get work that they probably can't handle in the first place.  The higher bids are more realistic 9/10 times.  Example, you have 10 bids.  7 of them are $200 or less and the other 3 are $600 - $1000.  Those 3 people are most likely the ones that know what it's really going to take and that's why they are bidding more.  It's safer to assume that you'r looking at somewhere around $800 than it would be to assume you can squeak by around $300 - $400.


Following that bad example on the same note if your budget simply can't afford the "realistic" cost, not all is lost.  You may still succeed with the lower bidding individual with less experience but you now have to extend deadlines and understand that he will inevitably end up having to learn as he goes.  Granted you're the one paying but when your not paying well you HAVE to accept these delays.  (Or scrap it all and find someone else).  I'm sure people will have some contradictory tales but it's always better to be safer than sorry.  Either accept the higher cost quotes or the longer time frames, never try to get a happy medium between the two.

#5025577 Advice need for business plan

Posted by on 25 January 2013 - 04:37 PM

I believe Tom was more so trying to say that you should focus on the more immediate and realistic goals.  The overhead (cost) of supporting 1.9 million users that you don't have can kill you while you are waiting for the project to sustain itself.  Also purchasing top line systems now and taking 3 years before you even need them will cause them to be nearly obsolete by the time that you actually need them and therefor be a complete waste of money.


You would be best to do your research and see what kind of fan base that you have now along with how much interest you have in your game and how easy it is to get people to your website and facebook that are early pitching the idea.  If you can't get 1,000 likes on your face book your not likely to get 100 people to play the game and as such you can set your initial budgeting goals much lower.  Personally I tend to set my budget goals on a basis of how much I am willing to lose and for how long more so than trying to figure out how much I might need in 2 years from now.


I guess in short what I'm saying is that one fairly modern or better server is a good place to start and will most likely last you a good long while before you will need to worry about adding more or upgrading.  It is also much easier to sustain lower costs for a longer period of time ensuring that you have a better chance of actually reaching a sustainable or even profitable age.  Not sure if you are looking at how much of you own money it's going to require, how much of an investment to ask for or how much of a loan to take out but it all comes down to the same question...


"What is the cheapest way that I can adequately launch this idea?"  The example is that a modern server should be able to support at least a few thousand simultaneous connections of course dependent on your bandwidth requirements (which should be tuned to be as minimal as possible for MMO games anyway).  With that being said how many people are going to start playing your game today?  None?  Well there's your starting point.  You have 0 players how many servers do you need to support 150% of them?  You have 100 people that are interested and will begin playing immediately?  Well how many servers do you need to support 150 players?  I think you see the point here, it's more about how many do you expect to have, then judging your requirements a fair amount over that but not astronomically   9/10 MMO games on the internet don't even have 100,000 players let alone 2 million.  Maybe some day you will but chances are far more that you won't or at least not any time soon.  Why waste you or your investors money for years to find you never hit your goal?


One more thing, if it's for investors they just want to make a return on their investment as quick as possible.  They don't care that you think your game will be played by 2 million people.  They are quicker to give me some money to sell 1,000 copies if it returns 20% profit on their investment within a year (or is likely to).  The more you ask for the longer it's going to take you to get them their money back and then some and the less interested they will be.  If it's your money, it's more about how much can you afford to throw away and for how long?  If it's for a loan, it's more about what can you afford to pay back?  Also note that the price of the computer is not all that is involved with the server, you also need to host it somewhere.  Either a few thousand a month to get a nice fast line to your house (and potentially tens of thousands just to get that wire to your office in the first place).  Bandwidth costs money, the rack space costs money.  All in all too many factors to take in to account, base it on more realistic concepts, being how long can you afford to fail.  (Because you will fail for a while before you get the required fan base to sustain the game)

#5025562 How long would it take to...

Posted by on 25 January 2013 - 04:03 PM

I would like to chime in and address the second part of the question from my view point.  Programming itself is more of a proper implementation and understanding of the way that a computer thinks.  C++ or any language for that matter is little more than an instruction set that allows you to implement commands that the computer (or console) can act upon.  What I see quite a lot of are people that read a book and they know some commands in the language but they don't always make the underlying connection of what the command is doing.  For example (all be it possibly poor as I'm just making a quick reference example here..)  In C++ many people learn to declare and reserve dynamic memory through new or memset methods, but very few actually understand what this is doing.  The common and quick answer everyone will spurt out from memory is "It makes a dynamic variable in memory duh!"....


What is a dynamic variable in memory?   Something that can be constructed and disposed as needed...  Ok but what does that mean? ...  It means that the computer is reserving a range of memory addresses in RAM to store a variable that could be of the size requested.  And when you release or dispose of this dynamic memory the systems reservation of these memory sectors are made available for anything and everything else to reserve and use later.  How about using Direct X for another quick example.  There are many many many programmers out there that know how to use Direct X and if you ask them what it does they will answer (It renders graphics to the screen).  Which actually is a bit of a false statement to be made.  Direct X is an API layer that exposes command sets that allow you to activate capabilities of the video card's GPU hardware, shaders and on card ram (as well as many other features).


I'm sorry it seems vague but the point I am trying to make here is that learning the language is actually very easy.  "cout prints text to the console", "if compares values"  "for loops until it's end condition is met".  The thing that makes a difference between someone being able to play with the language (and maybe even effectively produce some software) and the guy that can reasonably do whatever is asked of him is more the underlying understanding of the language actually causing physical things to happen on the computer and even some understanding of how the hardware itself works.  This is the level at which you become more of a problem solver where in you know a solution you are aiming for, you can quickly think of the logic behind it (and in gaming / engine writing what the most effective use of the hardware may be).


So to the answers, how fast can the average joe learn C++?  I don't know, how fast can you memorize a few hundred commands?  How long will it take to elevate above that to the point where someone tells you "Make a thing to do this" and you can figure it out?  That depends more on how long it takes you to make the connections between the commands your using and what they are actually doing not what the results they produce are.  Especially when your getting into something like a game engine that requires advanced knowledge of hardware capabilities, hardware api's and advanced performance oriented design of the code.  It's not just knowing how to use DirectX to render some geometry you need to make it "smart" enough to still work well when your users use it wrong.


This is why you can't really get a definitive answer on a time frame to expect.  Everyone learns differently, many never make the underlying connections but they still get results, these people normally do better using someone else's engine and they can eventually get pretty good at it.  However should you ask them to build an engine you'll start finding they will tell you "Um I don't re invent the wheel" or "Why? <insert favorite engine here> already does it good enough".  This isn't laziness, more so this is actually the more experienced answer where in they may not know it but they are really saying "I don't understand how these things work I just know how to use them".


Just as a little more information as it would pertain to making an engine, here's the first few questions you should be asking yourself before writing a single line of code on an engine.  "What is the most common video card type that PC gamers are using?"  "What shader models are most common?"  "What are the differences between the various sharder models?"  "How GPU expensive are these various shader technologies on the most common video cards?"  "What Direct X API's impose the greatest bottlenecks when attempting to trigger GPU calculations?"  "What is the fastest and most efficient way to transmit the shader apps in to the pipeline?"  "How can I manage my code to maintain lower bandwidth even when my users are trying to render a bajillion polies?"


I'm sure that many people will chime in after me on this and say that none of this matters.  Compare their engine to Unreal.  Why is Unreal so much more powerful?  Is it because they use something that you don't?  No it's because they address issues like these (and I do mean LIKE these maybe not particularly these).  So all in all learning to "Program" and learning to use a language are different things all together and their importance varies based on what you are attempting to accomplish.  When your not talking about games performance actually goes right out the window in favor of getting the expected result.  Thus making it not so important that you understand how the language works just how to get what you want.  However when you get into engines an the like the question is different.  How can I leverage the hardware to get the result I am looking for.  Amount of time for people to make these connections and actually start doing the proper research vary more than snow flakes, you are the only person that can have any idea how long it would take you to memorize the functions, learn how they make hardware level things happen and then making the connection between those and learning to solve problems.  Basically I guess I'm saying learning the language is learning to get results using what is available.  Learning to program is learning to solve problems.  It's like detailing a car versus building a car, you can give anyone a sponge and a bucket and they can make your car look shiney, that doesn't mean they can actually make it go faster.  So how long would it take the guy at the car wash to learn to make your car go faster?  How long will it take billy anybody to learn to wash a car OR make it go fast?

#5025535 Hello

Posted by on 25 January 2013 - 02:37 PM

Hello, I'm a freelance programmer myself.  Not exactly the same situation but I believe that I have some advice that applies to any and all forms of freelancing and "self marketing" so to speak.  I'm going to list out some points of importance from my personal experiences both as a freelancer looking for work and a buyer who outsources work to other freelancers.  Most of these points are equally as important as each other so don't think the order that I say them relates to a specific path or road to success.  More so consider it as a bulleted list of things that will increase your chances.



  Ok, I know I said everything is pretty equal but this one here is by far the MOST important tool in a freelancer's arsenal.  You absolutely 100% need a portfolio showing lots of examples of your work.  Many buyer's don't know any better, they know that there are thousands of freelance musicians out there, they think it's easy and that anyone who says "I can do it" can do it.  After they get burned once or twice they will be looking for examples of you getting a LOT of work done not just one or two amazing tracks.


Social Profiles:

  This one I mention because I noticed you have not filled out your profile here.  Buyers look at this as a lack of dedication or care.  I know this is Game Dev and not a freelance service and your not marketing here to get potential work but you are discouraging people that are looking to buy assets.  We are all game developers or at the least aspiring game developers here.  Although we may go to the Unity store to buy premade assets or we might look on freelancer.com to hire project based contractors but on the same note many people are associating your name with lack of dedication and care.  If your other site's profiles reflect this at well it is more likely that interested buyers don't think you will actually complete the job.  It is VERY important that everywhere you post on the internet shows your attention to detail and drive.



  You linked a pretty nice loopable track that shows us that you have created... One track.  This is good as that it does show your quality of work but it doesn't really make people think that you do this on a regular basis.  It's more important to a potential buyer (at least the serious ones) that you get acceptable quality work done in a timely manner than it is that your work is perfect.  Post more and make it easier for people to get to your examples of work everywhere.  Do you have a range of talent?  Can you do action / rock styled tracks?  Can you do classical?  Would you be a good fit for a mystery game?  These are questions whose answers are normally answered at a glance depending on what you show us not what we go to find.



  This is another really really big one.  Buyers want to talk to you, they want to see things you have said to others, they want to see that you are capable of good and quick communications.  This is actually easy to demonstrate and forums are the beginning of this.  Post on forums, A LOT!.  The more you post the more people start paying attention and the more they remember "hey it's easy to talk to that guy".  Get more active on as many forums as you can keep up with.


Make it easy to find you:

  Coming back to the portfolio and profile ideas.  Many people are spoiled by the speed and abundance of information on the internet.  Anything you ever want to know is normally a quick google away.  We tend to get trumped pretty quick when a potential buyer finds it easier to get to someone else's site, portfolio or profile.  I don't mean to suggest you should spam links all over the place but you should always make sure that your link's are available on every post that you make everywhere.  For example, I'm in the position to recruit a composer right now for one of my clients (sorry but I already contracted him).  However the point here is that if I hadn't found who I was looking for yet I couldn't have even tried to consider you because I have nothing to show my client (I can't find any more than the one song you posted).


Contribute don't spam:

 You never know who a potential buyer is in this world.  Like the above example that just a week ago I was a potential buyer is a great example.  You may have never thought that Game Dev would make a connection that could lead to requests but you shouldn't ignore the possibility.  Game Dev is a bit of a bad example because we are game developers or aspiring game developers here, it's pretty obvious that people here will be looking to buy assets at some point in their career.  The important thing to remember is that you want to make it obvious that you are available without outright spamming about it.  The easiest way to do this is to contribute and participate on different forums and sites, and make sure that your link is in the signature.  You will quickly be amazed at how much traffic exponentially increases as your link appears in quality contributions to sites.  Again I don't mean to make this about me but take head in the fact that I'm talking to you about freelancing your audio works making very little mention of my programming.  However I know that at least 3 people that read this thread will click on my site and see who I am and what I do.  (I run analytic's on my site and I see how much traffic Game Dev and Facebook drive in..  It's more than google).




    So in recap what I'm saying it's not just about where you advertise yourself but how you advertise yourself and how much dedication you show.  It may or may not be true that your offering your services over a poor medium but it might also be that your being out shined so to speak.  The remedy for this is one of the hardest things you will ever do and it involves not sleeping.  I assume you like everyone else have a day job, have a family and responsibilities.  I know you can't spend every waking moment at your computer making things happen but you absolutely must find time every single day to make progress.  You 100% need to get your profiles updated, you need to display your portfolio everywhere, you need to talk more and build reputation.  Selling yourself as a freelancer is less about buying an ad on a website or getting into Google's adsense rotation.  It's getting people to know you, getting people to talk about you, getting people to see (or in your case listen) to your works.  The little known or at least little discussed fact is that completing things is more important than quality.  I'm sure people will argue this and I should mention that you can consider this my opinion less than fact but I have seen this time and time again.  I know very very high quality artists (I mean like they should be working for square soft they are so good).  Guess how much they freelance?  Never, they are flipping burgers.  I also know some artists that maybe shouldn't even be called artists.  Granted they are better than I but they're quality is very poor but they have hundreds of completed sprites, models, interfaces and other assets.  How much work are they getting?  So much I barely get to talk to them anymore.


    I believe (it's my opinion) that completing work is more important to buyers than having the best quality.  Although they will not pay for absolute crap, they will pay for someone half as good as you who can show lots of completed jobs.  As a freelancer getting started this is difficult to overcome, your facing off against others who may have been doing it for years and they have dozens of completed works.  How do you start getting your foot hold and making yourself a consideration?  Do stuff.  Do lots of stuff.  Complete stuff.  Talk to people.  Pay attention to details like profiles and portfolios.  Show the buyer you do things, it will make or break the sale almost every time.  The less they see you have done both musically and contributorily the less faith they have that you will do something for them.  I hope that this is a grossly incorrect assumption I am making and that your response is something along the lines of "Here's my portfolio with 300 demo tracks, here's my profiles on every other service everyone 100% complete".  At which point you'r looking more at nsmadsen's points that you're probably just advertising in the wrong places and it's time to look for more outlets.  If my assumptions are right and you don't have very many demo tracks (maybe because they don't sound so great and you don't want to show them), maybe you haven't been wasting your time on profiles because no one checks them (false that's the second thing I did, clicked the song came back and clicked your name), then I suggest you address these concerns immediately (like yesterday).


    Again I must make the final note that I am speaking from my experiences.  I am mentioning things that have made a difference in my career.  I am not saying that these are absolute facts or that you will have the same experiences.  I'm not a teacher, I'm not a sociology expert or anything of the sort.  Take my words however you want, try it my way only if you want to.  If it does make a difference well I'm glad that you found the same networks that I did.  If it doesn't?  Oh well at least you got experience in a few things that do relate to what your trying to do.  However do not think that what I say is a definitive answer on how you get work as a freelancer.

#5025451 where to start

Posted by on 25 January 2013 - 09:35 AM

I don't have much to add but must agree jbadams and SelethD very good points on both.  I'm another of those 15+ year coders and the best I can say is that you should expect at least a few years worth of learning (and practicing).  Coding is not easy no matter how much the book's tell you it is.  The theory behind it is but programming is more problem solving than it is typing.  Knowing the language is one thing, understanding it is another and applying it is yet another.  The book only teaches you to know the language, you learn to understand it through using it and hopefully after a LOT of experience and practice with the language you can learn to apply it.

#5025091 Creating a class to load .x files

Posted by on 24 January 2013 - 07:25 AM

Sorry I can't give you a straight answer, but I can ask some questions that can help someone get to the answer.  When you say that D3DXLoadMeshFromX doesn't succeed, do you mean it returns a failure value but does not affect the program (eg no crash?).  If so what does it return?  Is there a method to poll the last known error?


When crashing getting the pointer to the material buffer, is this a silent crash or is it throwing an exception?  Have you tried stepping through the code in your debugger and evaluating the pointer / variable values leading up to the erroneous sections?  Can you notice or announce what values of materialBuffer, numMaterials and meshTextures are just after D3DXLoadMeshFromX and prior to GetBufferPointer are?


It's a bit more of standard debugging practices than anything particular to DirectX but it will start arming you with more information that helps lead to an understanding of the issue.  Adding in answers to these questions on the thread might help someone else to have an answer for you.

#5024860 Rights to a song?

Posted by on 23 January 2013 - 03:15 PM

Contact the copyright holder of the song.


I'll second this, songs are just like artwork, stories or any other intellectual property.  The copyright holder is the final authority on what terms you will need to adhere to (and maybe what you'll have to pay depending on the song) to use their works.  Be sure to get your authorization in writing to cover your legal rear, just a simple IM or E-Mail saying you can use it will not stand in court should they later decide to come after you for damages, loss or copyright infringement.  If there is an active copyright on the work I would highly advise that you seek legal aid as well.  Never trust their lawyer to give you a fair deal and you may not fully understand the implications of the license that you are binding yourself too when agreeing to terms with the author's lawyers.

#5024817 Location-based Action-RPG [Mobile]

Posted by on 23 January 2013 - 01:22 PM

It seems to be that you are over complicating your end goal or at least over explaining it.  From what I gather your simply asking can one character be "aware" of any / all other characters within x mile radius of themselves.  Yes, large trigger area attached to characters, although on a large scale you might expect some performance dropping.  Watch the video tutorial linked below especially paying attention starting around 2:15 that will give you an idea of the theory behind this.




Unity 4's Free license will suffice for the collider features that you would need, I have not yet looked much into the networking myself so I can't comment if the free license would suffice there as well.


I do completely understand the rush to get something done but I would also HIGHLY suggest you scale back and create something a little more obtainable for your first few game builds.  Building games is difficult even with great tools and abundant programming knowledge.  It's not likely that you will create something amazing right out of the gate.  Focus more on smaller game demo ideas, maybe even small snippits of the overall idea and watch your confidence and experience raise, start with something large (especially considering your in a hurry) smells more like a recipe for disaster.  If you'll be upset not finishing this project, don't have experience with the tool set you are starting in and have not completed game projects in the past you might just be in for quite a let down.  I think we've all been there, we see an engine or tool set that has great power we start playing with it and things happen we jump into our live long goal and barely make it past the title screen before we start realizing it's a lot more intricate than we had expected.  A way to avoid this path is to step back and make a little one on one fight game.  Make a little town with 2 NPC's, 1 Character and have it a quest to talk to one then go to the other to win.  Sounds stupid but it's easy and you'll be learning valuable skills that you can later apply to something fun.

#5022324 Making a game. Need some tips

Posted by on 16 January 2013 - 04:20 PM

I guess I'll be the guy to jump in to this conversation on a bit more of he nae sayers side.  I don't mean to directly contradict what seems to be emerging as the popular opinion but my personal feelings are that no you can not learn the programming language as you go.  To put it simply yes you can learn features pretty easily, but properly using and implementing features in programming relies quite heavily on having a good base understanding of programming itself.  Think of it like speaking to someone in a foreign language you have never spoke before (maybe not the greatest example but here we go).  Say you don't speak Chinese and you move to china.  You may be fine with your little pocket translator to ask for directions or to order a beer, but will you be able to have an on going conversation on the side of the road concerning the financial situation of the world?  Likely not, although you can look up the phrase "where is the bathroom?"  and between their answer and where they point it's pretty easy to "talk".  But in order to have a real conversation you need to understand the grammar, the words and know in your head how to put them together, otherwise is it really likely that your chat partner will engage in the conversation with you if every other word (or maybe every word) you have to look up before you can talk?  Not likely...


With that said and keeping with that same example programming is no different.  All be it that the words you type might appear to English it's not exactly your every day English that we are speaking right now.  That is to say in order to hurt a player for 10 points of health you need to tell the computer (eg your game) to do that in the programming language.  So where you and I might say to each other "Player A takes 10 damage" you need to tell the computer...


PlayerA.Health -= 10;


Ok, that's simple right?  I'm full of it so to speak that's very easy to learn, heck you just learned it!  But what is PlayerA?  (Duh it's "Player A").  False!  Player A in this example is a class object and the health is a public member of said object defined as an integer value that stores the amount of health that "PlayerA" has.  Why?  Cause I say so.  I'm the one who wrote up the class and defined all that behavior outside the scope of this message.  Now why would this matter and what is the big deal that I'm trying to portray here?  Simply that just because you can easily learn to type "PlayerA.Health -= 10;" would remove 10 points of health from the PlayerA class that we are using to store our player's information doesn't mean that you can check that player's defense rating to see if it should have been less or more damage than that.  You don't necessarily know how PlayerA came to be, what else you may or may not want to interact with and so on.  Ok that's fine, more reading.  You can go backwards now and figure out how to write a class, you can learn about data types, declarations, definitions, functions, methods, members (the list goes on and on and on).


This is why I personally believe that it is imperative to first learn the basics of coding and a good portion of the actual language itself.  You need to learn the grammar that the computer speaks in (the syntax of the language), you need to learn key words and operators (excuse me I'm not an English major but the "And", "Is" "The") and all those fancy little words that actually make a sentence first.  I might know that "Konichiwa" means hello in Japanese (Or Chinese not sure exactly) but do I know how to say how do you do?  Is that even how you pronounce it in the Chinese equivalent or would it be "How are you doing?"?  Granted in real life people can look past proper grammar and still understand what you mean but a computer isn't built to do that.  It expects absolutely perfect grammar and it will follow your instructions to the T.  If you write something slightly out of order, even though your human eye understands what you mean the computer will do it exactly as typed and in some cases this can lead to horrible distastes


Now with that said and hopefully I make a bit of an impact with some of that there are other vital parts of programming that aren't writing code that also matter.  Namely the design of the end result.  Programming is an art of speaking a foreign language, to a computer, issuing instructions to obtain and end result or your choosing.  With that said how is your game design?  Let's assume that your making a simple action beat em up game, something that seems pretty self explanatory   Player moves around the levels, punching kicking and smacking down all those nasty bad guys in the way.  Cool, easy enough right?  Well lets ask a question that would be very important to this game working correctly.  What is the mathematical equation that is used to determine how much damage is done to an enemy when you flick him in the eye?  Sounds stupid and not important right?  Wrong!  The computer needs to know this, even if the answer is "That's one hell of a flick, one hit one kill that easy".  This is why I've always said that the design document is the first and most important step for game development for any and all members of the team.  Programmers need this design document so they have reference and knowledge of what they are telling the computer to do, artists need this design document to know what they are drawing, writers need this document to know how to wrap their story around game event and how to keep the suspense going so your player keeps playing, composers need this document (and maybe more so the story) to get a feel for how to compose their works...


So in the end, my suggestion is that if you are just getting in to game development for ANY reason, be it as a coder, an artist, a writer, a composer or hell even just the idea guy.  Start by writing up as many pages of design documentation as you can, something that you can hand to me who knows absolutely nothing about your game, and as I read through it to the end I should know everything about it.  I highly recommend doing this right now, ignore everything all of us are telling you about C++ an write your design document.  It will have an enormous impact on your selection of programming languages, technologies, engines and so on.  A good example, if you plan to target iOS you don't use C++ you use Objective-C, if you plan to target android you should be using java, if you plan to target XBox you either need C++ and an official publishers backing like say capcom or you need to go with C# and XNA.  You may just come to find out that C++ is not the appropriate language for your goals as a game designer and as such you may not want to invest 3+ months learning a good foundation of something you won't be using.


So all in all, I would keep in mind that you should NOT be expecting to have a playable demo in front of you any time soon.  I would recommend that you start with the design document even if you don't have a particular project make something up as a practice project.  You are actually worth 100% more to development studios if you can do design and coding (or art or whatever).  So this is something good to learn anyway.  Once you have a good thorough design document outlining what it is that you are trying to create you will be able to use that to ask informed and educated questions on what language you should be learning, what engines, api's or technologies you might need and why and so on.  Once you determine what language, engine and technologies you might be using you should "start from scratch".  Meaning that you should get a book or a good LONG online tutorial set that starts out as a beginner and works up to advanced topics.  Do the entire book or the entire tutorial set, and it is highly likely that it will have nothing to do with games.  That's fine, your learning how to talk to the computer so you can tell it how to run your game later.  The more important knowledge is knowing the syntax and operators (grammar and sentence structure), once you know that it's actually very easy to to tell the computer what to do.  Be it a program, a network server, a video game..  Whatever you have the power and knowledge in that you know HOW to talk to the computer and you understand how to properly issue instructions.

#5021855 Learning C#?

Posted by on 15 January 2013 - 11:34 AM

I am not personally aware of any "C# For Beginners" that actually start from a 0 programming knowledge standpoint.  Seems to be the majority (if not all) reference material on C# assumes that you are coming from C++ or Java and have a general understanding of programming techniques and verbiage before getting started.


I would say that if you are trying to learn C# to learn to program with it (as in not just for Unity games but for Windows Applications, Windows Phone apps and so on as well) then you will want to start learning the basics of either C++ or Java first.  Once you have a decent understanding of the basics from really any programming language it's just a matter of learning a new syntax (the way you write it) and the different API's that are available.  The good news is that C++, C# and Java all use a very similar syntax, meaning that once you learn one learning any of the others is really easy.  C++ is extremely difficult for a beginner and offers little to no protection from newbie mistakes.  To quote a line I saw in another thread "The C++ compiler assumes that you know what your doing".  This means that unless you make a really really big mistake Visual Studio will compile and run your program without warnings or errors.  Unfortunately this means that all your minor newbie mistakes will cause the program to crash with little to no reason as to why.  This is a good thing in the means that it will teach you to debug your work and to do error checking as you code but it will make it seem like it's a nearly impossible uphill battle.


As you get more into C# and Java the rules are a little more strict and the compilers can discover your newbie mistakes easier (giving you more concise warnings that help you from making the mistake in the first place).  Also the JRE and .Net runtimes (the power behind java and C# respectively) have better chances of recovering from minor mistakes for you.  Although this might lead to garbage values in your program it's more likely it won't crash as often.  Anyway, back on point here.  If you are simply learning C# so that you can script for Unity powered games and have little to no expectations of using it for anything else I would suggest stop and learn Unity Script instead.  You will find much easier tutorials to follow that directly teaches you what you want to know.

#5021841 How important is the iostream in gamedev?

Posted by on 15 January 2013 - 11:01 AM

In practice, 99.9% of your usage of cin will be calling std::getline(std::cin, ...), and of cout will be simple stream operators (i.e. std::cout << "Hello, World!" << std::endl). If you stat working with actual files, you will probably be paying attention to eof() and good(), but generally not a whole lot more than that.


However, it's all useful knowledge to have, so you might as well learn it...


    Good advice swift, I would like to expand a bit on this.  "Streams" in general can be a very helpful tool in creating anything including games, the cin and cout feature families (for lack of a better term) are not the only way to handle streaming of data.  In more modern cases they are actually being used less and less as coders are preferring more versatile streaming options.  It is wise to have a base knowledge of streaming in general and the cin / cout feature families are a good entry level exposure to this information but I wouldn't spend excessive amounts of times learning the specifics of these two functions exactly.  More so the << and >> operators and the idea that a stream is a buffered portion of memory (be it in RAM or on DISK) are the important part.  When you get into file i/o and socket i/o you will find streams start making everything easier and more expandable.  Beyond inter process communications (thread to thread or app to service type techniques), file streaming and socket communications there won't be many cases where streams will be very important.