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

Michael Lojkovic

  • Content count

  • Joined

  • Last visited

Community Reputation

192 Neutral

About Michael Lojkovic

  • Rank
  1. But, why nobody is addressing that this isn't a good approach? Of so many approaches, that one can be a real bummer with large files, because you have to 1) reallocate the memory 2) move all the content on the right X bytes 3) place your new bytes in the middle. This will be slower and slower. Parse the XML with your TinyXML2 library, convert the content into objects/struct, load the parameters into the objects/struct, change the parameters IN the objects, then write back into a new XML file.   I'm not sure if OP intentions are to just learn about allocators (if it is, choose something less complicated than XML files and dealing with large files) or to use the parsed data for something (if it is, then do the parse, convert to object, convert the object back to text when needed).   How would you go about inserting into the middle of a large file? I was using vector<char> previously. Currently, I have my own implementation of vector and an iterator that returns each new line. I allocate 4096 bytes to the stack allocator, and double it if I run out of memory. to make room for inserting in the middle I use memmove. I could use this for a memory mapped file too with some slight changes at creation time. I don't have anything against using TinyXML2. It's fairly fast as far as XML parsing goes compared to other frameworks. I'm just using my own string implementation for building strings to write out to disk that are valid c++ for Unreal. I could see switching to the EASTL at some point. It wouldn't be that difficult to replace my implementation with it, I'd just need to do a few find and replaces with vim. This whole issue will disappear once C++ gets module support on gcc, clang, and msvc through compiler extensions.
  2. If I need my allocator to be compatible with vector::insert, for something like a vector<char> which type of allocator would I want to use? A stack allocator that's able to move bits after the insertion point up by x amount? would memmove be the most efficient means of implementing this?
  3.   Yeah, that actually would work the best, and I could see replacing any uses of fstream with that.     I'm using TinyXML2 for processing the actual XML file. I'm just building cstrings from that data for producing actual valid C++ code from the documentation.   I'm mainly doing this just for practice with allocators, and trying to keep as much of stl out of my code so I don't have long compile times.
  4. I'm working on a documentation parser that parses xml, for code generation. Previously I was just using cstrings, they're extremely fast, but lead to weird memory errors on occasion. To address this I made my own string struct, and overloaded various operators. I took a slight performance hit since instead of allocating the cstrings on the stack I'm now allocating them on the heap, because of malloc. some of the cstrings hold entire files on occasion, so I want to handle those as well. Ideally, I'll eventually have two allocators and 2 different string classes for handling files and processing lines for writing to files. (I need to insert into the middle of files on occasion) My question is which type of allocator should I use for handling this use case? I'm guessing a stack allocator that can grow with the size tuned for starting at 16,384, and bumping the size of the stack up to 32,768 and so on if overflow would occur. I probably also need a marker, so I can roll back after writing to files. Is anyone able to help with resources, on how to approach designing allocators? right, now I feel like I could make something that would work on current inputs, but might cause problems if a larger xml file was introduced
  5. This works for me. Install your distros lua, and add these to the CMakelists.txt FIND_PACKAGE(Lua 5.3 REQUIRED) set(INCLUDE_DIRS ${LUA_INCLUDE_DIR}) add_definitions(-DLUA) include_directories(${INCLUDE_DIRS}) # put this after add_executable target_link_libraries(PROJECT_NAME ${LUA_LIBRARY})
  6. Decided I'm just going to implement an interface, and make whatever classes used inherit from the interface to link up. I.E. if they have a Player global variable set in Articy I'll generate and IPlayer interface, with inline methods for each variable in the set, and they just have their player class inherit it and implement what those variables correspond to.
  7. I'm not using their stuff. Everything is in the export file.  I figure open source this if it's well made, and spin off modules for other documentation software.  I have the whole design done for the map.     So, how I'm doing it is each key in the map has the id of the dialogue, and each value is a struct with two fields, a vector of the next dialogues, and a tagged union of either the current dialogue or a functor. If it's something other than dialogue the functor gets run.  I'm just trying to figure out how to keep the dialogue system generated separate from the actual game implementation.
  8. I'm working on an xml parser, for Articy Draft, that takes the dialogue trees in there, and spits it out in a format for Unreal to use.  I have it working fine with lines of dialogues. The only thing is there are conditional statements, and instructions the game runs listed in there. I'm just not sure how to handle conditional statements and instructions.   Conditional statements are things like: Player.heath < 90 Time.time > 13:00:00 While instructions are: Player.health += 5 Player.dexterity += 1 Conditions decide which branches to go down based on variables outside of the players control, and instructions add stats, or raise counters for unlocking new classes. Were using a bunch of plugins for RPGs in Unreal 4. I get that I could just directly generate code using those plugins representation of health and such, but I'd prefer to keep the code abstracted away from the particular plugin in use and generic enough so if we change the plugins or go to custom C++ in the future we don't have to change how the condition checks are written.  Is the best option generating a wrapper class with a constructor taking the plugin Character class or time class, and assigning that to the data structure in use by our Dialogue code?
  9. I don't use any prefixes. Maybe, just for globals so I can remember to refactor them out. What I do when I don't know what something is, use hotkeys to go to the definition, find out what it is, and then hit a hotkey to return to where I was in the code before.
  10. This is the code that's causing issue: (Shortened for brevity) c = content->FirstChildElement("Connection"); while(dialogues[0] != nullptr) // rewrite to iterate to the next dialogue { if(c->FirstChildElement("Source")->Attribute("IdRef", rightTarget.front().c_str())) connectionNodes.push_back(c); if(c != nullptr) c = c->NextSiblingElement("Connection"); if(c == nullptr) { FindDialogueChildren(dialogues, connectionNodes, orderedNodes, sourceCount, childTypes); c = content->FirstChildElement("Connection"); while(c != nullptr) { while(c != nullptr && !c->FirstChildElement("Source")->Attribute("IdRef", id.c_str())) { c = c->NextSiblingElement("Connection"); } if(c != nullptr) { connectionNodes.push_back(c); c = c->NextSiblingElement("Connection"); } } c = content->FirstChildElement("Connection'); } } Right now, it's supposed to loop forever or until it crashes.  Once I have all the nodes from the dialogue in there I'll worry about moving onto the next dialogue.  What happens right now is it loops through this twice, and on the third loop segfaults when TinyXML2 is looping through the dialogue structure to find the first "Connections" node, from the start of the document.   I'm having a feeling it's from TinyXML's design to be light on memory that's causing a buffer overflow, after looping through the 3000 line document so many times. Just trying to look at what node->_next is in FirstChildElement() causes GDB to freak out causing a segfault, and spamming a bunch of lines in CLion.  Prior to the crash node is pointing to a valid XML tag. This post on TinyXML++ seems to suggest a similar issue. (I get that it's slightly different)   I'm currently working on dropping all of the Connection nodes into a vector and looping through that with an iterator. Caused other issues, which I think I need to copy the Source and Target node of each connection into a pair, and loop through that.
  11. I'm building a binary tree based on the xml document I'm parsing with TinyXML2,(Is 3 the right name now?) so dialogue branches from documentation go into the engine correctly. I had an implementation of the initial tree that was almost working, but Nodes in the XML doc aren't sorted in the order they go in, and the Id for each value isn't in numerical order. A few of the dialogues ended up in the tree correctly, but it didn't work for every dialogue in the XML. Thus, I'm currently experimenting by looping through the document and dropping nodes in the order they should go for each dialogue.  The only problem is after looping through a few times TinyXML causes a segfault.   The doc has two basic sections. Psuedocode for it is below. <Content>    <DialogueFragment Id="10"> //.. <DialogueFragment/>    //... </Content> <Hierarchy>   <Node Type="Dialogue" Id= "1">     <Node Type="DialogueFragment" Id="10"/>     <Node Type="Connection" Id="2"/>   </Node> </Hierarchy> I'm starting with the top Dialogue with Id 1, and figuring out which DialogueFragment comes first, based on the Connection having Dialogue Id as the source and DialogueFragment Id 10 as the target. Then repeating that process for DialogueFragment Id 10 as the connection source, and so on till no more children are left.  I tried just searching through the Hierarchy from top to bottom, for each Dialogue, but the only problem is when the documentation software generates XML the nodes aren't always listed in the correct order, and their numerical value doesn't indicate the order they go in.   My code is pretty messy right now, since I'm trying to figure out the correct algorithm for sorting nodes in the correct order, before adding them to my tree structure.  Anyone know how to prevent the segfault caused by TinyXML2 when using FirstChildElement?
  12.   Based on the direction I understand computer and even console hardware going in the past year or two memory and register limitations are less of an issue, with the amount of instructions required to run bits of code taking precedence in most areas now.  In 2 years we'll have so much memory available to the gpus, once PCI-E 4 comes around, along with the additional lanes provided by the cpu. Would you say that 4 x 4 matrices should be preferred for optimizations with current and future hardware? (Except for the edge cases where memory optimization is an issue)
  13.   I couldn't find the exact stackoverflow post mentioning shaders, but this is close to it. I also thought the gpu has instructions baked into it that can handle 4 x 4 matrices in one to a few instructions.  I'm just trying to understand all of the ins and outs.
  14. I've just started working on my hobby game engine project again, and am trying to figure out the advantages and disadvantages of representing coordinates and rotations in different forms.  I've mostly worked with vectors and quaternions, only occasionally venturing into 4x4 matrices. In the book Real Time Collision detection I noticed 4x4 matrices being focused on more than the blogs do.   Some of the advantages I've picked up are 4x4 matrices scale much better when doing a bunch of transformations at once, and vectors are more ideal when performing less transformations. 4x4 matrices store position, scaling and rotation allowing position and direction transformations to be performed more efficiently. Standardizing the location of position and rotation coordinates, makes it rather efficient to update only the coordinates needed for a given transformation quickly. Also, 4x4 matrices can be dumped into shaders without having to convert from one form to another.   The drawbacks of 4x4 matrices are they don't solve gimbal lock, unlike quaternions. (not sure if this is true) 4x4 matrices are also more prone to collecting errors over time. Vectors and quaternions are also much less complicated to deal with while coding, making major bugs unlikely.   I couldn't find an article that dealt directly with issues for 4x4 matrices.  There were just a bunch of articles spread out over a bunch of blogs and stackexchange posts on matrix math, quaternions, Euler angles, and vectors. Are there any other advantages and disadvantages to 4x4 matrices?
  15. I'm testing 3d aabbs against each other. They're swept aabbs to prevent penetration of each other, and have center and halfwidth properties. During the sweep test I find the collision normal of the moving aabb to determine which face collided. Based off of the normal returned I push the collided aabb in the opposite direction. The only issue I'm having is when two adjacent aabbs have collinear center vectors the player gets repelled on the x and y axis when only one should occur. (these are two separate collision tests between the player and each aabb.) To solve this I took the cross product of adjacent aabbs, and set them to ignore collisions when collinear. (my aabbs are sorted from lowest x value to highest.) This kind of works, but now aabbs like walls no longer collide, if they're collinear. How could I go about ignoring collisions when aabbs are directly adjacent to each other, but still pass when representing walls? Here's a pic of the 3 cases: