• 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

134 Neutral

About greggman

  • Rank
  1. Interesting and informative article. It seems to have little to do with real bomberman though.   Bomberman is a product of an 8bit/16bit era and ran on systems that had very little ram and weren't programmed in higher level languages. As such there were no "powerup components". Powerups were just tiles placed in the map. Making them components and or having them as active game objects would have taken too much ram and too much processing. As tiles they are effectively static. The player tries to take a step in the direction of the powerup. The code looks at the tile, sees it's a powerup tile, replaces the tile with a ground tile and sets a flag in the player they he now has that powerup (or one more bomb).   As another example bombs don't expand. They blow up at their defined size instantly. (Google SNES Bomberman video to see). The article is a great introduction into ECS but it's also arguably an introduction into over engineering. Sorry, that sounds like a judgement and arguably anyway your game works is fine.  It's just the limits of old systems forced or suggested different solutions. Those solutions have their own advantages and disadvantages. For example, using the tile based (non GameObject) solution you can easily make a level that is filled with bombs because the bombs themselves are tiles. They can only be placed on tile boundaries. When you place one the ground tile is replaced with bomb tile. That means having 1 or 1000 bombs takes the same amount of processing. They only become gameobjects when they are moving and usually only a few are moving at any one time. Possibly max 2 per player. In other words the bomb is tile, if the player kicks a bomb tile (and has the kick powerup) the tile is replaced with a ground tile, a gameobject is spawned, the bomb moves down the hall until it hits the end or the player stops it, the closest ground tile is changed to back to a bomb tile and the gameobject is destroyed.   The bombs can appear to "tick" using tile animation. Rather than a gameobject per bomb all you need is an array of bomb tile locations and a time they were placed. A single function walks the array, any bomb who's time is up explodes the tile. So much less overhead. In fact because bombs are added to the array/queue as they are placed the code only has to check the oldest bomb. So in general only one bomb needs to be checked each frame to see if it's time to explode (or 2 or 3 for those rare occasions where 2 or more players put bombs down on exactly the same frame)   Even explosions are tiles. The moment a bomb explodes the code goes and replaces ground tiles down the aisles with explosion tiles. That means all the aisles on the entire board can be explosion tiles and again there is no processing. (tile animation effectively free on those old systems and can be replicated to be free on modern GPUs. Similarly it makes collisions easy. Each player just checks the max 2 tiles they are straddling. If they are explosion tiles they player dies.   In gameobject terms, the original bomberman likely only had 1 gameobject per player and 1 gameobject per moving bomb. Everything else was tiles with a few arrays to remember which tiles to change later (like changing explosion tiles back into ground tiles when the explosion is done)   Having bombs as tiles also has other advantages. Collisions are simple. The player checks if the tile he's on is an explosion tile, if so he dies, then he checks in the direction he's moving. If that's explosion he dies, if it's a powerup he changes it to a ground tile, if it's ground he moves, if it's anything thing else he can't go that way. So, bombs become barriers without any extra code. I wouldn't even be surprised if kicked bombs sliding down hallways weren't placing tiles in the hallway as they slide down it. Either tiles with a bomb image offset or some tiles that looked like ground but were actually "bomb is sliding here" tiles. That way if another player tried to enter an aisle at the exact time a bomb is sliding by his tile checking code will prevent him from walking into the tile and so you wouldn't need any special "is there a gameobject version of a bomb here" collision code. Similarly the tile/tiles under each player might also be special "play is standing here" tiles so similarly a bomb sliding down a hallway will know to how to stop just by checking the tile in front of them instead of having to check gameobject positions.   All of these solutions make this type of game possible on a 1mhz 6502 or 65816 machine but they also have benefits. Collisions are easy, explosions, bombs, powerups, take nearly zero processing time.
  2. Great article.   I did some test on jsperf.com and I found objects are fast than arrays but typedarrays are faster than objects, at least on Chrome 34   http://jsperf.com/raw-array-vs-typedarray   http://jsperf.com/raw-object-vs-raw-array-vector   (this one array will obviously lose as this.array is still a properties access). http://jsperf.com/object-vs-array-vector   Anyway, you might want to update to point out that you have to use TypedArrays to get the speed?
  3. Okay guys, I see your point. I've been in GL land for the last few years where all the state that's on a DX10+ sampler is actually directly on the texture. In that land, I've never needed to decouple a texture from a sampler (which I would have to effectively emulate). My artists have never come to given me a file with one texture used multiple ways.  So, the ability to use 2 samplers with 1 texture, while I understand it, isn't something I've ever needed to do.    The ability to use 1 sampler with multiple textures adds something I guess but only because samplers are detached from textures on DX10+. Not because I actually need that functionality. Though I can see how if I did need it and I didn't have it I'd be screwed (would have to duplicate the texture).   thanks
  4. There's a feature of DirectX called "samplers" or "sampler state".  A sampler has the clamping/repeating/filtering settings used with a texture. This lets you use the same texture with in 2 different samplers with different settings   My experience is, except for the examples in books, I've never seen that ability used. I've never seen a game asset (shipped 17 games) that used a single texture in such a way that 2 samplers would be needed, one with the settings one way and other with the settings another way for the same texture. For the stuff I've worked on there's always been a 1 texture to 1 sampler mapping.   Do you know of any games that have needed to use more than 1 sampler for the same texture?   If you know of one please name the game and where in the game the feature is used.
  5. awesome post. Just to keep the discussion going. It probably goes without saying but there is such a thing as bad tools. Tools that hurt a project rather than help it. Tools for which it would have been better if you'd use something off the shelf. Something debugged. Etc. Would you write your own image editing program? I wouldn't. Photoshop may cost $599 but it's worth every penny if you are editing images on a regular basis and no team can afford to reproduce all it's features. That might seem obvious but I know plenty of teams re-inventing the wheel in other areas from 3d editors to asset management system
  6. Thanks for the advice. The C++ Lite Faq covers how to serialize graphs if you are rolling your own but I was hoping to find a solution that didn't require me to write my own. The whole point is to save time and writing my own means spending more time (at least in the short term) then doing it the old fashion way so if I could find an existing solution that would be great but if I have to roll my own I could already tell it was going to take me longer than expected (things like needed special constuctors for filling in constant fields, references, etc....) For example if you have a class class Something { const string _name; SomethingElse& _somethingElse; public: Something(const string& name, SomethingElse& se) : _name(name) , _somethingElse(se) { } void serialize(Archive& ar); }; this is NOT going to work void Something::serialize(Archive& ar) { if (ar.isWriting()) { ar << _name; ar << _somethingElse; } else { ar >> _name; // ERROR! _name is const! ar >> _somethingElse; // ERROR! you can't set a reference } } And there are a bunch of other little things like that which I'm sure there are solutions for but that's why I knew it would take me quite a while to roll my own. Yesterday I was hoping there was an option in VC++ that would let my specify no RTTI for certain classes. Kind of like you can do this extern "C" { void myfunc (int c); } well if I could do this extern "NORTTI" { #include <plugin/api.h> } then the problem would be solved but I didn't find any such solution :-(
  7. Recently I needed to serialize some data in C++ and it drove me nuts. Does anyone know some good solutions? Serialiation is the process of loading and saving data. Generally if you have a good library or a good language it can be very easy to save a giant tree of data with very little work. For example in Perl if you have a hash of hashes of arrays of values etc, (some massively complicated structure) you can save it all to a file with like a couple of lines of code and load it back up with a couple of lines as well. With langauges like C you'd have to write hundreds or thousands of lines of code to first save all the data and then re-load it. Java and C# come with serialization built into their standard libraries so it's relatively easy to load and save. Java in particular supposedly has lots of issues but I'm sure their are workarounds. C++ has no standard serialization and C++ is still an evolving language which means there are newer *features* that are not always compatible with older code. So for example there are the boost libraries which are libraries often created by the very people that work on the C++ spec but which have not made it into the spec yet. One of those is a serialization library. Unfortnately it requires a relatively newer C++ feature called Runtime Type Indentification or RTTI. RTTI code is incompatible with non RTTI code and the stuff I'm writing is a plugin to another program. That program didn't use RTTI so I can't you RTTI in my plugin. So much for using the boost library. Supposedly they have some support for non RTTI but I tried the examples and they would not compile until I turned RTTI on. (Yes, I removed the class that was using RTTI but the compiler still complained that it couldn't include the header files for serialization unless I turned on RTTI). Worse, I tried some simple example with RTTI just to see if it worked and as far as I could tell it didn't actually work. I made a simple structure with a couple of floats, serialized the struct as per the docs and looked at the data, the floats were not in there. Maybe that's an issue with VC++ 2003 although the docs claimed it works with no problems. I found the s11n library. It doesn't say if it requires RTTI or not. Unfortunately it does say they don't support VC++ and they don't support graphs which is something I need. A graph in data terms means you have things that point to each other. For example a house may have a reference to its landlord and the landlord might have a list of references to houses she owns. A system that doesn't support graphs could not save that data, it could only save the connection one way, either houses could save their landlord or landlords could save their houses but the connection between them going the opposite way would be lost. I found the Eternity library. It also requires RTTI Someone suggested trying to pull out the CArchive feature of MFC (Microsoft Foundation Classes). They support serialization without RTTI (as RTTI didn't exist when MFC was created) but they required you to base every object you wanted to serialize on CObject and I really did not want to get into multiple inheritance issues. Another minor requirement is that I'd like the serialization library to save in XML. XML is relatively easy to read for a human so having the option to load and save as XML means it's easy to load up the data in a text editor and check for problems. Java and C# both support this. It's one extra line of code in Perl. The boost library is supposed to support this as well but as I already pointed out it doesn't seem I can use that library. To give you an example of how important a serialization library is, in my current project I have 2 tools. One tool writes a bunch of data, the second tool reads that data and processes it. If I had a working serialization library it would be as little as a single line of code in each tool to load and save the data. As I added new data to tool 1 it would automatically be loadable in tool 2. But, as I don't have a working serialization library, saving in tool 1 and loading in tool 2 took between 8 and 14 hours to implement including finding a non giant XML library and then writing support functions for that, then writing the code to use it to deserialize with all the various error checking etc and that was the first time only. Last week I added a bunch of new data and when it came time to load and save that it took another 6 hours. If I had a serialization library that time would be close to 0 hours. Maybe at most 30 minutes to write the few support functions needed. I learned a lot about serialization writing Tanjunka. In that I spent almost no time getting a fairly complicated data graph serialized. Unfortunately, writing a good serialization library is not a trival task. Maybe to someone that's done it before but my best guess is that it would take me at least a couple of weeks to write a good, easy to use, non obtrusive serialiation library for C++. This is one of those unfun tradeoffs. I actually wasted a week trying out different solutions and fudging trying to write my own until I decided just to do it the old fashion way and manually write saving and loading functions because after a week it was clear to me it was going to take another week or 2 and I didn't have the time. At the same time, everytime I add even a little bit of data I've got to update both programs, something that would basically be handled automatically if I had a serialization library. If you know of a library please point it out. it must serialize/deserialize to XML it must support STL containers it must support boost::shared_ptr (and containers of shared pointers) it must not require RTTI it must handle versioning. it must be easy to use, not massively cumbersome. it would be nice if it wasn't a bazillion lines of code (the boost serialization libraries compile to 7MEG!)