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

mrjones

Members
  • Content count

    92
  • Joined

  • Last visited

Community Reputation

612 Good

About mrjones

  • Rank
    Member
  1. I have heard of engines containing systems, sometimes a system contains multiple engines and sometimes there are engines composed of subengines and systems and so on. So it seems they are used interchangeably. Although I believe sometimes they are used to differentiate between different levels of scope. Meaning that for example it may be defined within bounds of a specific project that engine may contain multiple systems, but no other engines. I have no idea if there is a general rule or recommendation about it.   Edit: Come to think about it I believe engines tend to refer to real-time systems.
  2. You can sort face centers instead. It's slower, but it gives better results. Not necessarily correct results where faces are nearby and with sharp corners, but it's enough most of the time.
  3. I might be completely off, but these are things that seem dubious to me: 1. Is it necessary to multiply bone matrix with bone offset matrix? I would probably simply multiply with offset matrix assuming that before passing to glsl it is already multiplied with parent offset matrix (that is in turn multiplied with its parent offset matrix and so on). 2. Is that the sum of aVertexWeights 0 to 1 guaranteed to be 1.0? If not, maybe divide finalVertex with sum of aVertexWeights.
  4. Are these actually position vectors, I mean vectors representing positions of shooter and target? Or do you mean that vectorA is the direction of the shooter and vectorB is a vector from the shooter's position to the target? I'm assuming the second case, because direction of the shooter must be known to make the decision of turning either left or right. In that case, I would use cross product. If cross product of vectorA and vectorB is less than 0, it's on one side and if greater than 0, it's on the other side. See http://www.gamedev.net/topic/289972-cross-product-of-2d-vectors/
  5. When client A has requested a match, it should receive first available game with no opponent. When client B has requested a match, it should receive second available game with no opponent. You said that the match-making takes place entirely in the server. In that case you could use (and probably should use) MySQL transactions to make sure that client A match-making is done entirely before client B match-making is handled at all, if I understand the problem correctly.   Ie: 1. Client A requests match-making 2. Start match-making transaction for client A 3. Client B requests match-making 4. Find available game for client A in the database 5. Start match-making transaction for client B. This will "wait" until match-making transaction for client A will be finished. 6. Add client A to first available game in the database 7. Finish match-making transaction for client A. 8. Find available game for client B in the database ...
  6. I don't really live in America, but I believe in general the rules should be similar in most countries. A company has to be registered to a physical address. Usually the rooms must be rented or owned by the company or there must be a written and signed agreement from the owner of rooms about letting you run the business there. About taxes I'd probably try asking from accountant forums (such as http://www.accountantforums.com/). They could probably give you a lot better advice about accounting.
  7. Removed, because misread part of original post.
  8. It seems this is the problem: [code] for (int i = 0; i < (gridW) - 1; i++) { for (int j = 0; j < (gridH) - 1; j++) { [/code] For example if gridW==3 then loop is executed only when i<2, because you are comparing i<gridW-1, not against i<gridW. Same thing happens with looping j.
  9. [quote] So pointers and references can be used differently? I've always thought that a pointer of an variable returns it's memory position. A reference of that pointer returns the normal value. I didn't know i could use references by themselves, just thought i used them to kind of dissemble a pointer. [/quote] I'm going to try to give an explanation that I use for myself when coding and while it's not pure, it's easier to understand and it works. However, you'd do well to look up other sources that probably explain it better and more correctly than I do. First the declaration of a different variables: [code] int value=0; // Integer value (takes up 32 bits on 32 bit system). Should be initialized almost always. int* pointer=&value; // Pointer value (takes also up 32 bits on 32 bit system, but used differently). Should also be initialized almost always. int& reference=value; // Reference must always be initialized! Compiler checks against it and won't let simple int& reference; pass [/code] The first is obvious, it reserves 32bits for the value. The pointer is also 32 bits and points to memory location of value. The reference acts pretty similarly to pointer. The main differences are that reference can not be reassigned. When assigning new value to it, it is assigned to value, not to itself. The only bad things that can happen with a reference is that value goes out of scope or is destroyed before the reference goes out of scope. With a pointer one can accidentally reassign its value and it will point to something that is no longer there. About references to pointers. [code] int value=0; int& referenceToValue=value; // References value int* pointer=&value; // Pointer to value int*& referenceToPointer=pointer; // References pointer, so it technically acts as pointer to pointer // All these operations store 10 in value value=10; referenceToValue=10; *pointer=10; *referenceToPointer=10; [/code] There's a lot of material on the subject and it usually takes a while to wrap ones head around it, so just search for pointer vs reference. [quote] If you don't mind i'd like to hear what you had to say about the rendering code. Since if i do decide to rewrite it all i'd hate to make the same mistakes again [/quote] It's better to separate the base-logic and rendering code except in some borderline scenarios. This is a simple example on how I might set it up for a game similar to yours that has inventory and loot. And it doesn't have any explicit pointers at all: [code] #include <vector> // The logical part /** Item component is the baseclass for WeaponComponent and other possible components. It exists, because enable/disable functionality is shared */ class ItemComponent { private: bool enabled; ///< For enabling/disabling component public: ItemComponent() : enabled(false) {} void enable() { enabled=true; } }; /** A weapon component is item component */ class WeaponComponent : public ItemComponent { private: double damage; ///< Damage that the weapon might cause public: /** Constructor with default being a weapon that does nothing */ WeaponComponent(double _damage=0.0) : damage(_damage) {} }; /** It does not matter whether the item is in the world as a loot or in inventory. We won't put anything here that is world specific (eg position). */ class Item { private: WeaponComponent weapon; ///< Weapon component. Enable the component, if the item is a weapon. // If memory consumption is a problem, Weapon* could be used instead, but then copy // constructor and assignment operator must be overloaded to create copies of all components. // At the moment it is not needed, because ItemComponent holds entire copy of weapon anyway. public: void enableWeaponComponent() { weapon.enable(); }///< For convenience /** Get weapon component reference as constant reference */ const WeaponComponent& getWeaponComponent() const { return weapon; } /** Set weapon component. An assigment is made and contents of passed const reference to some other weapon are copied to weapon component of this item */ void setWeaponComponent(const WeaponComponent& _weapon) { weapon=_weapon; } }; /** Provide separate loot item to give it world position */ class LootItem { private: int x, y; Item item; // Easier to have the item here public: LootItem(int _x=0, int _y=0, Item _item=Item()) : x(_x), y(_y), item(_item) {} const Item& getItem() const { return item; } }; typedef std::vector< Item > Inventory; // Inventory now becomes a simple vector where we can put items and take them back out again. Also note that we are not keeping pointers, but entire items typedef std::vector< LootItem > Loot; // Same with loot // User-interface and rendering. // I'm leaving out a lot from here, because the example has already grown beyond the complexity I intended. /** Rendering and user interface handling. The reason why this is provided separately, is because there can be different views on inventory. For example we might want to render inventory of enemies differently over the head of enemy and so on. */ class InventoryUserInterface { public: /** No need to hide rendering of items */ void renderItem(Item item) { // Render item however you want } /** Render inventory */ void render(Inventory& inventory) { for(Inventory::const_iterator item=inventory.begin(); item!=inventory.end(); ++item) { // Render the item however you want. You might have components provide the information about which // images to use or item itself or just render text about which components are enabled and which are not. renderItem(*item); } } // Omitted handling user events etc completely }; // Setting up int main() { Loot loot; Inventory inventory; // Create inventory { // We can for example place initial items to inventory inside this scope. As soon as // the scope ends weaponToGoToInventory will be automagically gone, but its copies will remain in inventory Item weaponToGoToInventory; weaponToGoToInventory.enableWeaponComponent(); // Make the item into actual weapon inventory.push_back(weaponToGoToInventory); // Push a weapon to inventory inventory.push_back(weaponToGoToInventory); // We can push more than one of the same weapon to inventory and it won't crash! // A full copy will be made each time and since weaponToGoToInventory only exists in this scope, we can just forget about it } { Item genericItem; // Create a generic item LootItem lootItem(10, 25, genericItem); // Create loot item that is now positioned at (10, 25) // and holds weapon as it's item loot.push_back(lootItem); // Push it to loot } // Taking last item from loot and placing to inventory. // A separate class that keeps track of both loot and inventory should normally provide a method for it // that looks something like this: void lastFromLootToInventory(); Item item=loot.back().getItem(); // We take the item from LootItem loot.pop_back(); inventory.push_back(item); // And we place it to inventory InventoryUserInterface inventoryUserInterface; // Create userinterface for displaying inventor(y|ies) inventoryUserInterface.render(inventory); // Render items in inventory return 0; } [/code] Also, don't scrap your code. Even if you decide to rewrite it, it is very useful to have the old code and you can still use large portions of it.
  10. I didn't locate the crash and didn't run the code because I didn't have SDL development libraries installed (only SDL2), but I have some general recommendations that might help. These are really quite general and you have probably of them, but I'll reiterate them anyway. First of all, the class inheritance is a bit of a mess and memory seems to be leaking. The worst is that almost everything seems to derive from LoadFiles and its constructor loads all images, fonts etc. Each time anything derived from LoadFiles is created, and these classes seem to be many in number, all images and fonts probably get loaded again and again. I'm not 100% sure given that I've only taken a glance at the code, but it really seems to be so. Secondly, there seems to be lot of inheritance. It is better to use composition in most cases. Try looking up composition vs inheritance. There was a good post about it on GameDev, but I can't find it at the moment. There also seems to be a bit of duplicate code. For example Item::setDead(). Item could just as easily have boolean dead member and set it instead of it being marked abstract. All the child classes are just doing the same. Just try to find code that duplicates itself and remove it. It's a slow process at first and it's often easier to just copy-paste, but it will hurt a lot later even when trying to make sense of your own code that is months or years old. Also, the less code you have to read the more obvious the errors will become. I don't mean shortening the names of variables, but the logical duplicates where a new function could be used in more than one place or even when it makes logically more sense to keep it separately. Now, the pointer-hell. There are a lot of pointers, so many I lost track. Whenever possible, try to use references, full memory copies and stack allocated variables. In my experience pointers are almost always bad unless you need to optimize something. And even then the pointers should be local. There are also many references to pointers. A reference is technically a pointer anyway, with the restriction that it can not be reassigned to point to another location. For example instead of Cursor* &cursor it makes sense to use either Cursor* cursor or preferably Cursor& cursor since the pointer value is not reassigned and it would be a bad idea to do so anyway. Then there is the problem with rendering code being mixed with the game state. Usually it is best to have the underlying structure separately and provide different views for it, but it's already way out of scope of what I planned to say at first and there's plenty said about it elsewhere. I hope you get something out of my recommendations. Overall it's not bad for a first project at all. I wish I could be more thorough, but architecture and pointers are a huge subject and unfortunately without running the code seeking crash is like searching random uninitialized pointer from heap of bees. Edit: Sorry as I am probably repeating much said above as I started writing when no other posts were made. I'm slow.
  11. I am not entirely certain about how things work on *nix systems, but zlib or libjpg might also be somehow related to the problem.
  12. Ideas that first pop into mind are: 1. Did you somehow manage to install another version of SDL library on your system that gets linking priority? 2. Did you either change project settings or project failed to save properly last time you changed it? 3. Did you update Code::Blocks or gcc? In other words, what might have been something else related, but not immediately obvious that you or something automated on your system might have done? Just to be safe, I'd try to open the JPG files with something else as it is the easiest thing to check and maybe they have become corrupt somehow.
  13. A note about noizex's recommendations: Checking whether pointers are NULL before calling delete on them is unnecessary. Calling delete on a NULL pointer has no effect by definition. Although not initializing pointers to NULL in constructor(s) in current code is a problem.