• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

spunkybuttockszc

Members
  • Content count

    100
  • Joined

  • Last visited

Community Reputation

100 Neutral

About spunkybuttockszc

  • Rank
    Member
  1. Quote:Original post by graveyard filla Quote:Original post by spunkybuttockszc Well, you're definately right about it taking a very long time, and a huge amount of dedication. But the true reason it's so difficult is the network programming. The network code behind a good MMORPG would be immensely complex, and would have to be integrated seamlessly with all the other game systems (very difficult to do on the scale of an MMORPG). Every single system has to be designed from the ground up to integrate with the network system. This requires quite the complex design, and thus leaves a lot of room for design mistakes, and of course coding mistakes. And generally because the codebase would simply be massive for an MMORPG, only the most skilled programmer could maintain it effectively during the course of the games development, which could easily be up to or more than 5 years for an MMORPG. So basically, you need to be a network programming genius to make one. And you need lots of experience designing huge class hierarchies and software architectures. This is why making an MMORPG is so difficult. But, as someone said, making the game is only *half* the trouble. Dealing with the the community of players afterwards can be truly hellish, as they will literally never be satisfied. A change in one section of the game could very easily offbalance another section. This would make a lot of people mad, and they would constantly complain and threaten to cancel their subscription if you didn't fix it. i dont know if i agree with that. i do think that the network code behind a MMORPG is very complicated, but i dont think you need to be a genius. ive been working on a 2d MMORPG for almost a year now, and i didnt have a clue about network programming when i started. in fact, i didnt even start learning about net programming untill i had a playable single player demo RPG where you could walk around a city and kill NPC's. when i started learning about network programming, i found a new passion for game development.. i personally love net programming because it is such a challenge, and is more art then science. i didnt design any class heirarchies and have little experiance with software architectures. id say im far from a genius.. i dont think im doing too bad so far. im just, very persistant.. which is why i stand by the fact that persistance > skill. Well, when I said that I was talking in the scope of games such as EverQuest 2 and World of Warcraft. A simpler, less professional MMORPG such as yours (no offense meant, it looks really good for a hobbyist game) as you said wouldn't require huge class hierarchies or software architectures. But something like World of Warcraft most definately would.
  2. Nobody knows? Is UML not popular anymore?
  3. For the tank's movement: every five seconds (or some other similarly small time interval), give the AI tank a new destination for it to travel to. Draw a line (not literally on the screen, but in theory) between the tank and the destination. If the player tank intersects this line, reset the destination point (to a random pos). Otherwise, reset the dest on some set time interval (like 5 seconds). For the tank's attacks: as people have said, define a range the tank must be in for firing to be valid. If it is in range, give it some percent chance to fire, and then just let it fire (of course in the general direction of the player, which would require some vector algebra).
  4. Quote:Original post by Anonymous Poster I believe you can still compile vb6 code in vb.NET. I also believe that .NET is much more than "just a couple of web site add-ons" Yes, .NET is a whole new iteration of the compiler. The language has changed slightly, and is now built on top of the .NET framework, which could be a good thing and a bad thing.
  5. I'm looking for a program I can use to design UML diagrams. My school has SmartDraw installed on all their computers, and I've messed around with it a bit. It seems to have good support for UML, and a lot of other types of diagrams. But is it really the best? I mean, since it supports so many other types of charts and diagrams, surely it can't have a full implementation of or support for UML. So basically what I'm asking is what program do you guys recommend for UML? Thanks in advance!
  6. Quote:Original post by graveyard filla Quote:Original post by v0dKA Just an aside question if you guys don't mind: Is there one thing in particular that makes MMORPG development difficult, or is it many factors combined? Let's say I have full mastery of C++ and some graphics library, have adequate experience with networking, and have good knowledge of game design (i.e., code organization, AI, etc.). What then? Is there still something hard about coding an MMORPG at that point? I'm not as experienced as I described myself, and neither am I planning on actually making an MMORPG anytime soon. However, such a high number of people have posted that they wanted to make one and they all got the same reply, "It's not easy", so I became curious about why. IMO, its less of a "difficult to do" thing and more of a "takes a really damn long time to do" thing. yes, being able to actually write the code is in itself a difficult task, but the real hard part is actually writing the code. it takes ALOT of code to make a MMORPG, between the client, server, and editors. personally, i feel that making a MMORPG (or doing any game development for that matter) is more of a persistance issue as opposed to a skills issue. getting the skills to make a MMORPG is a lot easier then being persistant enough to make one [grin]. Well, you're definately right about it taking a very long time, and a huge amount of dedication. But the true reason it's so difficult is the network programming. The network code behind a good MMORPG would be immensely complex, and would have to be integrated seamlessly with all the other game systems (very difficult to do on the scale of an MMORPG). Every single system has to be designed from the ground up to integrate with the network system. This requires quite the complex design, and thus leaves a lot of room for design mistakes, and of course coding mistakes. And generally because the codebase would simply be massive for an MMORPG, only the most skilled programmer could maintain it effectively during the course of the games development, which could easily be up to or more than 5 years for an MMORPG. So basically, you need to be a network programming genius to make one. And you need lots of experience designing huge class hierarchies and software architectures. This is why making an MMORPG is so difficult. But, as someone said, making the game is only *half* the trouble. Dealing with the the community of players afterwards can be truly hellish, as they will literally never be satisfied. A change in one section of the game could very easily offbalance another section. This would make a lot of people mad, and they would constantly complain and threaten to cancel their subscription if you didn't fix it.
  7. Quote:Original post by doho Just remeber to start out easy and NOT dig into 3D. Start writing some classical games such as tetris, pacman and astroids. This is excellent advice, except if you're already a very skilled and experienced programmer, just not with games. In that case, this is still good advice, but you could probably start more advanced, like maybe with a tilemap based game (eg. mario). As for online stuff, these very forums will probably be one of your greatest sources of knowledge and ispiration. Read all kinds of threads, whether they're related to your specific problem or not. You'll pull in a lot of knowledge that way, and be much more capable of solving new problems in effective and innovative ways.
  8. Quote:Original post by Raymond_Porter420 I read that somebody said they had heard it was good practice to expose the x and y members publicly. I disagree, as I think they did. Though it may seem OK since it's just a simple vector class, there's is always the possibility that you need to change the way the data is accessed. This would be very troublesome if the members were exposed and accessed publicly. why do you say he wants to keep private in case the vector changes. The vectors functionality shouldnt change as it isnt some cool class you made up but a mathematical data type that has both direction and magnitude. They are not some new thing that came out to help you in computer graphics. They are a concept that has been around for hundreds of years. The operations you can perform on vectors are very concrete and very well documented in many math books. Because, 1) There is *still* the possibilty you may need to change how it's accessed. Yes, it's very unlikely, but still possible. 2) Simply for consistency throughout the code. This makes the code much easier to read, and much easier to use. You should never find yourself asking the question, "Hmmm, I wonder if this class exposes its data publicly, or if I have to use accessor functions to get it. I guess I'll have to look at the source to find out, or just randomly try something and see if it compiles." 3) It's excellent programming practice to give classes a very clear, very concise, very consistent interface, and expose as little data publicly as possible. The benefits of doing this probably aren't apparent at first thought, but after working on a large project in which this wasn't a common practice, you would quickly relize how much easier the code is to maintain if every class has a simple interface, and keeps all its data private/protected.
  9. For an MMORPG, you need C++ for performance and speed reasons. It's as simple as that. Plus you need dedication, skill, some more dedication, and some more skill, and so on. Plus, you better be a absolute network programming genius, or you'll fail quickly, and very quickly.
  10. I've just skimmed through this thread, so I may repeat something, but here's my thoughts: Firstly, you need to inline those functions! They are small, and will be called many, MANY times during the game's execution. These could serve as a minor performance bottleneck. Inlining will help tremendously, as no actual function call (and thus no grabbing the memory address of the function) would ever be made. I read that somebody said they had heard it was good practice to expose the x and y members publicly. I disagree, as I think they did. Though it may seem OK since it's just a simple vector class, there's is always the possibility that you need to change the way the data is accessed. This would be very troublesome if the members were exposed and accessed publicly. And last but not least, somebody mentioned adding operators + and -. I disagree. I realize that having those operators would make the class much easier to use, but contrary to what the person who suggested this said, temporaries *aren't* something good to have being made behind your back when writing games. It wastes time because the constructor of the temp object is called when the temp is created. This can easily be wholly avoided with some extra typing. BTW: I'm sure you're aware of this, but sqrt() is very slow! To combat this, maybe add a method which will return the length squared, because this would work fine in several situations (tho I can't think of any as of now). Other than these things (which are more of tips than actual things wrong with your code), everything looks fine. I didn't check the math, as it seems others have already verified it. Well, I hope this helps.
  11. It sounds to me like you need this book: "C++ for Game Programmers" by Noel Lloepis. It's excellent, and it's sole purpose is to cover how to effectively use the exclusive features of C++. Templates actually has an entire chapter devoted to it. In the book, he writes a linked list class using templates as his main example. Here's his class declarations so you can see templates being applied to something slightly more advanced and useful: template<class T> class ListNode { public: ListNode(T); T & GetData(); ListNode * GetNext(); private: T m_data; }; template<class T> class List { public: ListNode<T> * GetHead(); void PushBack(T); // ... private: ListNode<T> * m_pHead; }; // here's some examples of using the List class: List<int> listOfIntegers; List<string> listOfStrings; List<GameEntity*> listOfGameEntities; I'm sure you can see how incredibly useful templates are in this case. Without the List and ListNode classes being templatized, you would have to rewrite both the classes for every single type of data you might want to use them to store. Plus, doing this would rule out the possibilty of using polymorphism (which is VERY useful for storing a list of game entities). Well I hope this helps, Zach.
  12. With great power comes great responsibility. :)
  13. If you're thirteen, then you should probably hold back on the 3D programming. Like you said, start with the basics. The math behind 3D, frankly, will be too difficult for you to use efficiently and effectively. Maybe get a copy of "Tricks of the Windows Game Programming Gurus" by Andre LaMothe and "Data Structures for Game Programmers". These should get you writing some cool 2D games in a few months or so. If you're really ambitious about C++, then maybe try "C++ for Game Programmers" by Noel Lloepis. Be warned, however, that this book is fairly advanced, and assumes a working knowledge of C++ already. It is a book of concepts and ideas. Only get it if you're very, very familiar with OOP and the syntax of C++. However, the book is most excellent, and will *greatly* improve your programming skill. As for APIs, SDL I hear is pretty good, tho I've never personally used it. I use ClanLib for my 2D projects. It's very object-oriented, so the learning curve could be slightly higher than what you want. Just Google on either of these for more info. Other than books, your very best resource for game dev will inevitably be these very forums. Come to them often, and read a lot of threads (even unrelated ones), and you'll find yourself learning things you may never find out on your own. Plus, more often then not, when simply browsing through threads, you'll read about somebody's solution to a problem, and then a month later, you'll have that same problem and already know it's solution. Well, I'm running out of time, but I wish you the best of wishes.
  14. Jingo: Thanks for the elaboration! What you said makes sense, but had you not said it I probably wouln't have ever understood it. I think it's so fascinating how much freedom you have in C++ when it comes to memory. I mean, you can basically grab any memory address you want if you know what you're doing! Of course that wouldn't be wise, but knowing that it can be done is a little daunting. I can definately see how some people have been using C++ for over a decade and are still learning things.
  15. Thanks, Jingo! That fixed it! I wouldn't have thought something so small as that would cause that. I guess I have a lot to learn... For helping me, you get a rating++.