• 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

322 Neutral

About MichaelDwan

  • Rank

Personal Information

  • Location
    Flagstaff, AZ
  1. The first thing I notice is that it looks you're issuing a draw call for every single tile. Not to mention (potentially) changing texture and shader state unnecessarily. I'm assuming, except for position, all these tiles are being drawn in essentially the same way. Instead of drawing once for every tile, just bind your shader and texture, submit _all_ the vertices and indices at once and issue a single draw call.
  2. Been playing with the BlackBerry Z10 lately. I have to say, for me, its the most navigable mobile OS on the market. One hand, and you can swipe your way around very comfortably. Looks like iOS 7 is going in a similar direction, with more touch/swipe based navigation, as opposed to endless button tapping. Good stuff.
  3. If the government thinks I should be in debt for school... I think I should pursue a life of anarchy. I started by jaywalking two days ago. It was intense. Then, I pushed the walk button to stop the oncoming traffic!
  4. How are you projecting the points? Where on the 2D view-plane do you expect the point to be projected if you do the math by hand?
  5. [quote name='W4L33D' timestamp='1314288997' post='4853699'] How do I fix that? I've also tried putting & and * before Rectangle, and I tried SDL_Rect Rectangle:: etc. [/quote] Your return types don't match. In the declaration you use SDL_Rect* as a return type, in the definition you're using the struct keyword as a return type(which doesn't make sense, any way you hack it) [code] SDL_Rect* Rectangle::make_rect(int x, int y, int w, int h) { } [/code]
  6. [quote name='teddybearzero' timestamp='1311017039' post='4836972'] Hi all, How can I get Lua code to compile on a Mac? I've been using Scite on Windows, but a Mac version doesn't seem to be available. Can MonoDevelop be used? And if yes how do I set it up to recognize Lua. Thanks in advance. [/quote] Lua code compiles to run in a virtual machine. Just use the command line tools to compile it. http://devthought.com/2009/03/17/how-to-install-lua-5-in-mac-os-x-leopard/
  7. OpenGL

    Exactly. I guess it may be a misunderstanding. That is, perhaps the reviewers mean that the authors spend 7 chapters DEVELOPING the GLToolKit (the ins and outs) instead of going straight to GLSL. But that would mean the tool kit has shaders in it, which leads me to think they are indeed just black boxing the whole thing. I was hoping someone here had read it and could shed some light on it. The two ebooks linked, I think, would do a good job of filling in the holes the SB5 would inevitably leave. So, I think it would still be a safe investment, I'm just boggled as to how a thousand page book would feel the need to approach the material that way.
  8. OpenGL

    I've read often that the SuperBible 5 is really biased toward the author's GLToolKit or whatever its called. I understand what they were going for in order to introduce graphics programming, but its an OpenGL book, I don't really see the logic in wrapping OpenGL. Unless of course the ToolKit is built and explained during the book's progression. I think, if what I've read of the SB5 is true, that, maybe a better route (besides the two ebooks posted earlier which are very good,) is something like the Orange Book(OpenGL Shading Language) and OpenGL ES 2.0 Programming Guide.
  9. Hahaha. Very true. I get into old school mode when you start talking about P&C adventures, though.
  10. Alternatively to cutting the image up and layering it, you could use a pseudo depth buffer as well. In it you would have key-values (graphically for editing you could use something like Magenta or some other stand-out color), then, when drawing your sprites, check the buffer at the sprite's position and don't draw anything that collides with the Magenta value. Just a thought. I do think it would be more difficult to implement this efficiently than just layering, but, from a development standpoint it it would be quicker and simpler than chopping all your map screens up in randomly sized chunks.
  11. You only have one option in Linux to work with the old VGA modes and DOS era game programming: Get DOSBox, and run you executables there. Otherwise, set yourself up a Win 3.1/Win95/Win98 machine. If i remember correctly, all of those will still let you screw things up if you want. Its been a long time, though. You'll also need an old Real Mode compiler, I always preferred Borland's Turbo C/C++. Another choice is DJGPP which will let you compile 32-bit protected mode programs as well as 16bit Real Mode. That will let you work with extended memory regions and SVGA stuff. As cool as all of that was, to be that close to what you were doing it isn't really reasonable nowadays. Instead, just choose an API that will give you access to to a "frame buffer" Like Direct Draw/SDL Surfaces, or Direct3D/OpenGL textures. Once you have that its just as old school: draw your pixels to an offscreen buffer and copy those to whatever your API choice is using to represent your "frame buffer"(this is probably just generating a texture from the raw pixel data in OGL/D3D) I suppose I should have left out all the DirectX stuff since you're on Linux, but you get the idea. I miss the old days, too, but really, there was a lot going on behind the scenes then too, it only seems simple because all we had to do was load some registers and "int 13h", now you just have to call a new blackbox entry-point, whichever you choose.