• 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

713 Good

About Tesshu

  • Rank

Personal Information

  • Location
  1.   If you're using the NDK then I would strongly recommend you learn the JNI stuff. Some stuff is WAY easier to do in Java. Using JNI you get the best of both worlds. The original glue code Google code included was really just a sample IIRC. I made my own glue code using theirs as a guide. The code starts a native thread and puts an exception handler around it. When a C++ exception is caught, I re-throw it using JNI to the JVM. So it gets logged as a normal Java exception and I get a crash report on the Google Play Developer Console. I even log Java exceptions that happened when my C++ code called some Java code.   The other thing I have is a custom build I give out if I have a user that is willing to work with me. The app logs everything to a file and makes sure it's flushed after each entry. Next time the app starts, if it sees a file it blocks while it sends it to my website. Then it deletes the file.
  2. I thought ferrous was suggesting that the tool shouldn't have flagged it as an issue when clearly the tool got it right. As to what the code wants to do is hard to say for sure without seeing it all. It's likely not up to the tool to know what the coder wants...
  3.   It's actually correct. If the status is Aborted then the first test will always be true anyways. So it's redundant. Really what I dislike about the code is that the reliance on order of operations instead of brackets.   Oh and it's great to see another full page Ad for PVS-Studio!
  4. There is also GL_OES_element_index_uint extension that allows u32 indices.   I still think you're making more work for yourself than needed. I would get it to run on ES 2.0 and then add and extensions or ES 3.0 as a bonus if time permits. It's pretty trivial to write and index buffer class that handles the breaking up for you as long as you're drawing the whole thing instead of ranges. If you're drawing ranges then you have already broken the index buffer up somehow.
  5.   That one is awesome but I have to say it's not thread safe. Are you telling me you only get tasks from one place!
  6. If you have managed to write support using ES 2.0 then why bother with 3.0? I'm still at ES 2.0 and won't change until I have no other choice or becomes the dominant version. Why limited your target audience?   What I do for this sort of thing is have abstract classes and then check extensions and make run-time choices. This is basically how I do my platform independence also.   The indices problem I solved off line by breaking the assets up as part of the asset pipeline. This rarely happens and I would somewhat question why you need that many indices on a mobile device. VertexArrayObject* OpenGLGraphicsDevice::createVertexArrayObject( VertexBuffer& vb, const VertexFormat& vf ) { if ( isOpenGlES3() == true ) return new OpenGLVertexArrayObject( vb, vf, vb.getTag() ); if ( hasOES_vertex_array_object() == true ) return new OpenGLVertexArrayObjectOES( vb, vf, vb.getTag() ); return new OpenGLVertexArrayObjectEmulated( vb, vf, vb.getTag() ); }
  7. Maybe I exposed that bad, it is not a shorthand at all. Differently from the "typical use" of creating short-hands, I'm here proposing a good(at least according to my opinion:P) use of "using directive".   There are no problems of include order etc. and there is no stuff like 2 different versions. Semantically is exactly equivalent to declaring a class with no side-included headers (go back and read sentence again).   I know it is a subtle difference and hard to notice at a first and at a second read.     I took a better look at what you are doing (waiting for a build to finish). While my initial comments are true they don't fit the scenario you are talking about, as you pointed out. Sorry. I made a poor assumption that you were trying to solve a different problem. Your solution is actually still looking for a problem and it pains me that someone would spend time on this.   I would strongly suggest reading what the master has to say about it in Large Scale C++ Software Design by Lakos. A dry piece of text but the guy knows exactly what he is talking about and I got a lot out of this book.   The issue is that your header should include everything it needs to compile itself and nothing more. Forward references whenever possible. If it doesn't I would pretty much say it's an error in waiting. Also the cpp that includes it should include it's header first to enforce this principle.   The insanity of having two header files with the same name makes me cringe. Anyone trying to read your code or yourself in 6 months is in for a world of hurt...
  8. Well done! IMHO you have hit a home run.   I often counsel people to drop their 3D MMORPG and do a 2D pac man game. Why? Well it's because they don't know what they don't know. They don't realize that their 3D game isn't even a really small tech demo. It maybe 5% done at most and go no where. Small games like yours get finished and have allowed you to experience the WHOLE process. You have gained skills in all areas and are far more equipped to know what goes into a project and get it shipped. Again well done!
  9. Ouch, that's not the same at all. Something like "using namespace std" is really a mess and is potentially able to pollute namespace and causing very much problems, in my case I'm just exporting 1 name for header (or if it makes sense, just a bunch of names) wich is very different from importing a whole namespace.   namespace myPublic{ using K = myPrivate::K; // results in myPublic::K name => same as declaring K inside "myPublic" } Yes you're correct. I noticed this after I posted and thought it might make it under the radar :) I used to do this sort of thing to make short hands for stuff like the following but I stopped this practice. using dmath = dwarf::math; Still there is some truth here and it's really nitpicking but I still wouldn't do it. Headers get included in different orders all the time and having code that compiles two different ways based on include order can be hard to find. Namespaces are designed to prevent this sort of thing and making shorthand versions is really just circumventing the system.   Sure the compiler should point out ambiguity for you if there is a problem but it doesn't protect you from old C headers with macros. I would also say the code is harder to read now. Don't spend time on stuff like this as it only takes away from finishing a project.
  10. The problem is that you should never have a using declaration in a header. These should only be in cpp files. Use fully qualified namespace names in your headers. Looks bad at first but eventually it will be normal.
  11. What about NDK these days? Is it well supported?
  12. I would work VERY hard to get this game to be much smaller. Yes there are bigger games but to think your game is so good that people will dump 250MB isn't realistic. It's not an insult or meant to pull you down, it's just reality. There is a reason apps can be sorted by size on your phone and you don't want to be in the top ten in that list. It is SO hard to get people to even try your game and that file size is a deterrent.   Have you looked into doing an expansion file on android? It does require work and is one more point of failure you have to deal with.   Perhaps I am wrong but I get the feeling this is a small 1-2 person team. If so realistically, I doubt you could have generated that much content. Spend sometime looking how you could reduce the size. Can you tell me what kind of resources are using the most space and perhaps I could offer some advice?  Textures, geometry, audio etc
  13. Well I still think it's code shaming as it's a one sided unsolicited code review. If they have in fact asked the authors if they could do this then I am very sorry but there is no mention of it in the article.   With that said, what is to say they are errors or issues in the first place? So many time people have come running with 'The Bug' that isn't a bug actually (myself included) because they didn't know the big picture or understand the code.   V670: this error could actually be fine if the constructor just wants a reference or address of the variable.   V668: if the project doesn't use exceptions and/or has a custom allocator then the test makes sense. Still not even an issue really.   V719: is there a compiler known to man that won't report this?   Half if not all of these so called issues could be caught with full warnings on and warnings set to errors, which you should do anyway. These aren't articles by the way. These are full screen ads that use the assets of reputable projects. Ads that they run for free...