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

Necator

Members
  • Content count

    77
  • Joined

  • Last visited

Community Reputation

239 Neutral

About Necator

  • Rank
    Member
  1. Instead of putting the data in the actual enum, you can place it in an array and index it via the enum values. struct Foo { int i; int j; Bar b; char c; //other stuff }; enum Biz { Biz_1, Biz_2, Biz_3, Biz_Count }; Foo elements[Biz_Count]; elements[Biz_1].i = 10; I believe it is as close as you can get to what you're asking for in C++.
  2. If you're looking for a lobby system, you probably want to keep some representation of the lobby while people are waiting, not just pair everyone up once you've found enough people to start the game.   Then again, it all depends on what you're looking for. In Left 4 Dead you usually end up in a half-filled lobby when finding a random game, whereas other titles skip the lobby altogether.   But to answer your questions: Q1: Your approach above should suffice, but in the end, it will change depending on how you want the game join flows, lobbies, etc. to work. The easiest approach is to have players choose between join or host up front. On the other hand it will occupy players until the game is filled up enough to start.   Q2: This is also depending a lot on your requirements. It's usually most straightforward to set up all game instances up front in various game mode, map, mutator combinations. However, it's not that adaptive to changing popularity. More complex approaches entails having a system which monitors the server utilization of various setups, spinning up new instances if you have less than X percent capacity left for any one setup. You can even make it take resource costs into consideration, so it can have more smaller games or fewer larger ones on the same hardware. Another approach is to spin up "empty" server instances which can be reset to any player requested configuration on demand. That way you don't have to maintain the various combinations ant leave it up to the players to choose when they reset the server. It's harder to manage CPU utilization though if players happen to create smaller games on one machine or if another gets all the large games.
  3. I usually go with forward declaring as much as possible and including the rest and self-contained headers is a must. Reducing the amount of actual includes helps with several factors: * Reduces build times. * Reduces dependencies and risk of cyclic includes. * Reduces build times when modifying frequently included headers.
  4. My guess is that your V coordinate is truncated to 0. The left side of the division is int, so even if you cast the right side to float, the compiler will cast it back to int implicitly. (Btw. Either you accidentally added something when you posted it, but that shouldn't compile due to 'j)' where you have a closing a parenthesis but no matching opening one.) dat[t++] = j) / ((float) height-1); // V Try this instead: dat[t++] = float(j) / (height-1); // V
  5. Look at it this way. System written with security in mind gets hacked from time to time due to sequrity aspects usually overlooked during the implementation or later changes. Some of these hacks shows up as quite obvious, other gain enough publicity to be found by the developer. Both these gets fixed quite quickly. However, the hacks which is not obvious or well known will probably go undetected. Allowing the client to have a large say in matters will only open up more potential issues. Even if you fix/ban 90% you will still end up with potentially a lot more hacks which is very hard to detect.
  6. A simple approach is to render when possible while performing simulation/physics at a certain frequency. Threads are also quite possible to use, but this also requires all threading issues to be taken into account. Reading & writing the same data from different threads needs to be properly handled. A simple example of a single loop, running simulation/physics at a fixed interval. void update(float deltaTime) { static float deltaTime2 = 0.0f; deltaTime2 += deltaTime; while (deltaTime2 > TICK_TIME) { simulationTick(); deltaTime2 -= TICK_TIME; } render(deltaTime); }
  7. Keeping a set of all instances for each type will probably quickly grow out of control. Unless you really need to optimize it due to performance issues, I'd recommend placing all entities in a container for all entities in the level. If you then need to find entities of a certain type, look though them all and cast them to the type you are looking for. Its not optimal, but unless you got a quite large amount of entities, you're not going to notice a difference. Regarding removal of entities. Add a bool to the base class signaling if the entity should be destroyed before the next update, then loop though all entities and remove marked ones at an appropriate time. For collision, once again, unless you have a large amount of entities, check each entity against every other entity. With a sphere, or bounding box test before any more complex tests it should be acceptably quick. Otherwise you can consider adding a spatial subdivision scheme for finding entities close to one another.
  8. Edit: Too slow =) The reason for it not compiling is that you don't specify a valid constructor for the base class of AdaptMe, SomeClass<int> in this case. Either add a SomeClass constructor taking no arguments, or explicitly run on one of the existing ones in the AdaptMe constructor. I.e. SomeClass() {} or AdaptMe(In obj, TranslateFunc Func) : Out(/*something fitting*/), inObj(obj)
  9. My guess is that it's a little bit more to it than that. All sound effect are probably the same gain originally, but with some added HDR data to modify the gain of the original samples when played ingame. But in the end, yes, it's probably a fancier name for automatic gain control as HDR lighting is a fancier name for automatic tone mapping.
  10. The idea is to dynamically change the volume depending on what is being played at the moment. When only quiet sounds are played, the volume is increased to allow players to hear all the details of the sound. Then when an explosion or some other very loud sound is about to be played, the volume is decreased so the explosion would sound about as loud as the previous sound. While doing this, the quiet sounds will also decrease in volume, and you'll end up hearing only the loud sound. When the loud sound then has finished played, the volume can be smoothly increased to the original level, allowing the quiet sounds to be heard once again.
  11. Quote:Original post by paic I remember having read something about "component design" or something like that, and I think it was applied to scenegraphs, and was apparently a good way to decouple data and processing without the limitation of virtual methods and visitor pattern ... but I can't find the article. Try searching for component based. clicky
  12. I think you'll be hard pressed to find a good solution to the problem as (a bit generalized) - Virtual methods decouple your data from your algorithms. Forcing algorithms to work though a common data interface. - Visitor pattern decouple your algorithms from your data. Forcing data to work though a common algorithm interface. If you fully decouple both sides, neither will know what the other can do. Perhaps a compromise on both parts might be more suiting. Both provide restricted interfaces which the other side can use. Node types providing similar data can be grouped up and hidden behind a common interface as dragongame pointed out. The visitor pattern can still provide a good way of handling how your algorithms handle different groups of data, though the smaller details are hidden by virtual methods in the group's base classes.
  13. It's actually quite simple to extend it to calculate a memory difference not only when exiting. And regarding the total usage, it prints that out quite nicely as well if you look at the lines: ... Largest number used: 8139718 bytes. Total allocations: 16533279 bytes. ... However, it is true it's VC++ specific. Unless you find something compiler/platform specific or find a memory manager package which can do it for you, your best bet is to overload the global new and delete operators as Dave and OrangyTang suggested. clicky.
  14. Take a look at this forum thread: clicky I've found it quite handy for telling if there are any memory leaks. When exiting you'll get a memory report along with a dump of any unallocated memory areas. Example from my terribly leaking project. 0 bytes in 0 Free Blocks. 2057060 bytes in 187 Normal Blocks. 1016 bytes in 18 CRT Blocks. 0 bytes in 0 Ignore Blocks. 4828 bytes in 23 Client Blocks. Largest number used: 8139718 bytes. Total allocations: 16533279 bytes. Dumping objects -> c:\program files\microsoft visual studio 8\vc\include\crtdbg.h(1147) : {15625} normal block at 0x00B4A800, 32 bytes long. Data: <Aseen::Update Dr> 41 73 65 65 6E 3A 3A 55 70 64 61 74 65 20 44 72 c:\program files\microsoft visual studio 8\vc\include\crtdbg.h(1150) : {15567} normal block at 0x024E0660, 30240 bytes long. Data: < \? > 20 CC B7 BE 1C CC B7 BE 87 8E 5C 3F 20 CC B7 BE ... ... Unfortunately it cannot say where the allocations occurred, however, by looking at the allocation sizes you can often guess where the leak occurs. EDIT: Realized that you can in fact see where the allocations occurs, but since there is no complete callstack it doesn't help much.
  15. It depends on if the helper library you seem to be using have any support for custom shaders. Try looking though the library and see if anything pops up. Otherwise you probably have to work directly with DirectX, in which case try searching for "directx effect file" on google and you'll find some ok resources on how to load and use shaders in a farily simple way.