• 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

199 Neutral

About MatrixCubed

  • Rank
  1. I would also suggest Code::Blocks, if only for the reason that the community is extremely active, and very friendly. I've dealt with them while working on my game in Windows and Linux (Mac OS X planned!), and I wouldn't look at another IDE.
  2. Come to think of it, that's when I noticed this behavior: right after my GDNet+ membership expired.
  3. Hi Dave, I seem to be having the same problem, which occurs across multiple browsers (Firefox 1&2, IE 6) across multiple computers and operating systems (Windows XP SP2 on my work computer, Ubuntu "Edgy" Linux and Windows XP SP2 on my home computer). The only common factor involved is my account. Best regards, - m³
  4. Hey all, I've been putting off asking for a while, but I thought I would throw the question out: is the forum theme selected in my user profile supposed to revert back to the default blue-on-white theme? I've set different themes at different times, on different computers, in different browsers, and each time the forums revert back to whatever is default, after what seems to be a cookie expiry period of some kind. I don't suppose this "feature" is limited to GDNet+ subscribers...?
  5. Quote:Original post by Pete Michaud I might as well ask now: the game I'm planning is meant to have interactivity with the environment. For example, one of the player characters might want to break through a wall. Obviously under normal circumstances with something like a Diablo clone, you could just draw the wall graphics to the screen with a passability map for collision, but if the player is going to be able to break it, then it'll have to actually be a GSO or Actor, or whatever you want to call it. That's great in theory, but if almost everything on screen is an actor, will that be too much data to crunch? Obviously for a Gauntlet clone computers are powerful enough, but what if I want a Diablo clone (which isn't far from accurate) in which walls and objects can be interacted with? Will that burn up too much processor, or is it feasible with current average hardware specs? In the example I gave above, you could add a feature to the map to have tiles (it will be tile-based, yes?) which have a "health" or "can be damaged" factor... for example a wall with -1 health might be un-damageable, 0 health is 'broken through', 1-50 health is 'slightly damaged', and 51-127 is 'normal strength'. This then could be represented with 3 graphics: rubble (for the broken-through wall), a wall with cracks (slightly damaged), and a normal wall. Also, it could be represented with a single signed byte. Also, the way I handle state-change of different objects such that there isn't overload of number crunching, is to set up a state machine for different objects, and only change the state in an event-based manner. For example, let's say you have a WallTile class, an Actor class (for monsters and player characters), an Object class (for potions, food, doors): std::map<int, WallTile*> map; std::vector<Actor*> actors; std::vector<Object*> objects; Each frame you'd run some sort of update on each list, moving movable objects based on time: void UpdateActors(void) { for each actor in actors { actor.update(time_since_last_frame); } } And again each frame, render every object that appears onscreen: void RenderEverything() { for each walltile in map { render(walltile); } for each object in objects { render(object); } for each actor in actors { render(actor); } }
  6. Without doing a lot of research on the language itself (and having never coded a verb of it myself), the question comes to mind: why does any major IT company (or any company, for that matter) introduce a new product? There's no simple black-and-white answer, but here's my crack at it: - to stay ahead of the competition - to reduce the R&D time for its own products - to (indirectly or directly) create employment (teachers, programmers, book authors, etc) I don't personally think any language is better or worse than other languages, but rather take into consideration their suitability for their intended use. Given the language-creator's track-record and ethics, I'd be hard-pressed to adopt it myself. But that's my personal preference, and not necessarily that of the greater programmer body.
  7. Hi Pete, It's good that you're asking these questions early on. Getting into a game project without fully realizing at least what's partially necessary to complete the game, is a good exercise in stress :) Having said that, it's also important that you understand that mistakes will be made, you'll rewrite portions of code you think suck, or you'll totally trash a section of the game, and write it another method. That's OK. Indie game developers do it. Professional development houses do it (look at Windows Vista). But it's important that you understand concepts early on, in order to circumvent problems that you described as effectively as possible. I don't have any links for you, but I can give you some advice gleaned from working on my own game engine. You can start by break a game down into logical interfaces which are (for the most part) unrelated: graphics, sound, input. Then you have objects upon which the interfaces interact: textures, sound files, and key-press events. Once you have a basic game shell working that allows you to capture, manipulate, and respond to these very basic elements of any game (e.g. play sounds, render sprites, etc), you can start with the next, more interesting section: the engine. At this point you should be thinking in terms of 1) game-specific objects, and 2) game-specific object-managers. GSO's are those things in the game which can be manipulated, shot, eaten, thrown away, sat upon, or whatever. GSOM's are the managers of the GSO's; they maintain lists of each of the objects, sort them, search through them, and add/delete them. GSOM's can be made from arrays, linked lists, or if you're feeling particularly adventurous, STL containers. Let's say you're working on a single-player Gauntlet clone: The engine contains your game-specific objects, as well as an event manager. This means you have Creatures in the game (heroes, monsters). You have Power-ups (potions, food). You have miscellaneous objects (monster-factories, portals, locked doors, keys for the locked doors). And to link all of this together, you have game maps. You also have counters for health and score. You'll likely have at least two separate lists for creatures, and for powerups/misc objects. Once all of these are working, you should be able to implement the following limitations and features: - walking around on the map - colliding with walls - colliding with items (causing increases to statistics such as health, magic, score) - moving between areas and maps using portals - and so on The last large part of this game would be to design a simple AI which moves nearby creatures toward the player. There are lots of things which could be done with a game such as this (for example, competing with Diablo!), but this should give you a general layout of a game. If you have any questions I'd be happy to help.
  8. OpenGL

    Thanks for pointing out the blatantly obvious I was searching for a much more complex solution, without realizing the simplicity of the question!
  9. Hello all, I've developed a sprite engine using OpenGL, and one of the features I'd like to have is the ability to render sprites' shadows. Each sprite in my engine uses a 32-bit RGBA texture. Is there a method of rendering a textured (unlit) polygon with alpha testing (for color-key discarding of pixels) to the color buffer such that I may use only the alpha channel to define a "shadow-texture"? For example, using the stone on the left, which uses its alpha channel to define color key (e.g. the green area), whose pixels I reject using alpha testing. I'd like to somehow use that alpha channel to define a texture similar to the one on the right, such that I might blend it with the color buffer to create a sprite "shadow". I can pre-generate such textures at texture load-time, but I'd like to know if there is a method of doing this realtime? Thanks in advance,
  10. This has to be one of the more creative game ideas I've come across. As well, bravo for completing an in-depth game design plan. I look forward to seeing a demo sometime in the future.
  11. Quote:Original post by Will Vale [example of] float result = dot( v1, v2 );Excellent example. I'd just like to add that some C++ purists of the attitude that everything needs to be encapsulated, might create a Math class, and do something like...float result = Math.dot(v1, v2);IMO this is an exercise in redundancy. When developing my own game engine, I follow the simple concept: if there is one instance of it, use C functions to handle it. If there are multiples, then use a C++ class to encapsulate it. Something to watch out for: getting bogged down in complex coding guidelines.
  12. Considering the myriad of games with excellent gameplay which predate shaders (or 3D acceleration for that matter), I would argue that shaders have little, if anything, to do with gameplay.
  13. If you go the fully 3D route and simply rotate/position the camera such that the view is isometric or near-isometric, you gain the advantage of light sources for shading, which can certainly add depth to the game. I considered going this route, however due to time constraints and general lack of knowledge I went with a fully 2D engine instead. YMMV so if you have the knowledge and time, absolutely go for a 3D tile engine.
  14. Hi all, I've written a fullscreen/windowed mode toggle functionality for my game engine, and the code works great in Windows. However, the same code crashes under Linux. I've tracked the crash down to glDeleteTextures. The code is pretty simple, as follows: if (glIsTexture(m_iglTexture) == GL_TRUE) { glDeleteTextures(1, &m_iglTexture); // crashes here } I'm really not sure what to do at this point; I need some way to reload invalidated textures, and unloading textures/destroying/recreating app window/reloading textures seems the cleanest way to accomplish this. Any suggestions would be appreciated.
  15. Quote:Original post by horizon981 What choice [do] the game developers have? SDL - general media control layer, replaces DirectX SDL_image - image file loader, replaces some DirectX functionalities OpenGL - 3D rendering API, replaces Direct3D OpenAL - 3D sound management API, replaces DirectSound ENet - reliable UDP network API, replaces DirectPlay Lua - scripting library for game extension XML - generalized file format wxWidgets - GUI toolkit for tool development, replaces Win32-specific APIs PhysicsFS - resource manager/loader All of these technologies and libraries have one major feature in common: all are usable cross-platform. They work in Windows, Macintosh, and Linux, which are the three largest potential OS demographics for gamers. Typically it seems development houses first choose technologies, then whinge about the costs of porting their software to other platforms, citing development expenses vs. return as the primary factor when choosing not to port their software. I say, why port at all? Develop your game using cross-platform libraries and ideals, avoid using anything which is platform specific, and produce a game which is not locked into one operating system!