• 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.


  • Content count

  • Joined

  • Last visited

Community Reputation

261 Neutral

About weeska

  • Rank
  1.   You're just wasting time by asking those questions. If you wan't to make games, they're totally irrelevant. They just stop you from doing something. Also, it seems like you have a fixed mindset of the answers to every question you ask, so there's no point in answering your question, either.   You'd be better off appreciating the detailed answers like those from Hodgman and AllEightUp, because they seem to know what they're talking about.   Try to make games or program what you want to, and if you get *really* stuck, ask for help, there are some great devs around here.
  2.   now i got your first comment on that^^
  3.   It seems to me that you want to flame and/or complain about c++. There's no problem with that, but it won't come to an end, either. The points that are mentioned here as disadvantages of c++ are more or less problems of the people using it.   Sure the, oop-fizzbuzz example is funny, but that's because it is completely exaggerated.   I think there's no point in "being a fan of language x". It's a question of what feels best, what is best for the project in aspects that are important for the project.
  4. I'm not sure if i got you right. With unique_ptr, you don't need to delete the object, it takes care of that itself.
  5. I'm not quite sure, but couldn't this be done with std::bind?   Not with default parameters itself, but you could just bind the first parameter being the default value of Func (making it a 1-parameter function) and call it with whatever you need to as the second parameter.
  6. That would depend on the type of map, i.e. its granularity and dimension. You could use an array big enough to fit your needs for two-dimensional maps. If it's 3d it gets more complicated and you should at leasst use some sparse grid.
  7.   That one was with a bit of irony. Sure the opener can learn both, but i think it's better to learn them one after another. In any order ;)   I know this feeling when you want to learn everything instantly, but i've made the experience that things get out of control very fast this way. It's important why one wants to learn both APIs at the same time.   If it's for game programming, i don't think it'll give any benefit in the short run. If it's out of technical curiosity, it's worth a try.  If it's about learning graphical theory, there are more things to learn than an API, so i'd go with one of them.   Also, it's important, it's never useless to learn OpenGL/D3D in the first place and later switching entirely to the other one, because the concepts used are the things that matter most and require the most efford in learning.
  8. Programming is always a good thing when learning, and the points you mentioned are worth implementing. But i don't think i got your question right :D
  9. I'd say it's not even easy learning one of them at a time for most people, at least in the beginning phase.   If you have some basic understanding of what you'll have to do, and maybe a bit programming experience with libraries that are similiar, it might be okay. But i guess the frustration level is much higher, not only because you have longer phases of coding without seeing a result.   Also, the setup for both APIs is (in my opinion) quite different, so i'd suggest you start with one (=OpenGL) and then, when you're feeling comfortable with it, try something in D3D (or stick to OpenGL :)).
  10. What you have to ask yourself is, why you want suggestions when you already used pygame? Are you just unsure if it fits your needs? Then we'd need more information to give you advices. Do you "just" want to learn a new library? Then pick one and see if you get along with it. If you do, fine, if not, try to see what might be the reason. The first two libraries that come to my mind are sfml and sdl which have bindings for python and others as well. This way you'll sooner or later have some knowledge about the libraries available, and can make decisions that fit your needs ;) Another point to think about is if you "just" want to see the game implemented to actually play it, or if you want to improve your programming skills.
  11. This Rotation Matrix rotates a vector around the x-axis by 90 degrees. Your vector initially points toward the z-axis and after the rotation it points in y-direction. I think this is counter-clock-wise as it's written in the article.
  12. [quote name='CombatWombat' timestamp='1346517134' post='4975471'] First off, is this generally considered to be an "abuse" of OOP, or is this a valid solution? [/quote] It's a State Pattern, a standard Design Pattern. I like the solution with the stack for managing multiple states. I just don't see a point of [CODE]void ChangeState(CGameEngine* game, CGameState* state)[/CODE] in this code. It seems that it isn't used anywhere. I don't know if it's a good solution, but since the states get a pointer to the engine anyway, and one of the responsibilities of an engine is resource management, i'd give the engine access to a resource manager class that can be queried for specific resources. At this point, it really depends on what kind of resources you need. Will there only be images? Will there be sounds? I guess it would be valid to use a different resource manager for sounds than for images, but with the same interface for external access.
  13. Hi, i don't know how specific you need your bullet points, but steps involved would be something like this:[list] [*]initialise your graphics API of choice [*]create a landscape (procedurally or from a source like a height map) [*]implement navigation [/list] The landscape part can basically done by using a vertex shader to displace a sufficiently subdivided plane's vertices. The navigation part depends on the kind "flying" you want to have, but can be done with some translations and rotations depending on keyboard input.
  14. [s]I never used lwjgl, but i think you're missing a swap-operation in your render method.[/s] No it's called automatically, and i guess you're already seeing your scene. Greetings, weeska
  15. [quote name='AgentC' timestamp='1345200283' post='4970502'] The rules should be more relaxed on OpenGL 3.0 and onwards. However if you look at [url="http://www.opengl.org/wiki/Framebuffer_Object"]http://www.opengl.or...mebuffer_Object[/url] it still says: "There's one more rule that can trip you up: The implementation likes your combination of attached image formats. (GL_FRAMEBUFFER_UNSUPPORTED when false)." [/quote] It also says: "Basically, don't concern yourself with GL_FRAMEBUFFER_UNSUPPORTED too much. Check for it, but you'll be fine as long as you stick to the required formats." The way i understand it is, use the formats that have to be supported, and there shouldn't be a problem. Checking for support on OS X is no option nor needed at the moment, but it's always good to know who's strict with these optional parts. Thanks for the answers so far ;)