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

//Lumia

Members
  • Content count

    15
  • Joined

  • Last visited

Community Reputation

650 Good

About //Lumia

  • Rank
    Member
  1. Thank you all for your replies.       I will take a closer look at this option. Based on your link this seems to work quite good for a log system (though a pretty simple one):   Logger.h: class Logger { public: void log(const std::string& message) { // get the time etc. auto completeLogMessage = /* build one */ log_impl(completeLogMessage); } private: virtual void log_impl(const std::string& completeLogMessage) = 0; }; CommandLineLogger: class CommandLineLogger : public Logger { private: virtual void log_impl(const std::string& completeLogMessage) { std::cout << completeLogMessage << std::endl; } } It would also be possible to add a specific implementation that is logging to a database etc. which is pretty cool. This surely does not represent the full potential of this idiom but I will keep this in my mind and try to apply it when dealing with a more complex scenario.   @SeanMiddleditch: This is the way my prototype is working at the moment since I didn't trust the pimpl   @Servant of the Lord: Thanks for pointing out Qt - I will have a look at the source code so some things might get more clear when seen in production code. Based on my limited experience I would tend to not trust anyone especially after reading through some posts of the "Coding Horrors" section   @swiftcoder: Since my project is not going to be a library you might be right. But in my opinion there's nothing wrong with trying to apply some techniques primarily used for APIs to the internal stuff if it makes some things cleaner. I will see how this works out and the good thing is the project is nothing mission-critical so learning new things is what it's all about.
  2. Hi,   so recently I was starting out on a new simple project in C++ and I was thinking about an overall structure on how to organize my code in a proper way. At this point modules came to my mind. The main point here is that I don't know how to properly seperate the implementation from the interface so that no implementation details of module Y are exposed to module X that is using module Y. Unfortunately C++ does not support modules in a native way because header files do serve as a class definition and interface at the same time...   So I already read about the pimpl idiom and I can see its advantages but there are also some drawbacks in using it (e.g. dynamic memory allocation).   All this is leading to the important question(s): How do you handle this topic within your projects? Do you know some techniques beside pimpl to achieve a clean separation between the interface and the implementation? If yes, how do they work and are they field-proven? Do you know of some open source code that handles this topic quite well? (for further investigation)   Thank you in advance.
  3. Hi ArThor,   my opinion might not be the most valuable because there are much more experienced and skilled people on this forum but I was in a very similar situation trying to find a solution. So here are my 2 cents:   As I was starting to find a solution to this problem a pretty long time ago (1 year+), I was constantly browsing the web trying to gather as much information on this topic as I could. Relatively early in this process I noticed that most of the information were based more on experience than on some recipe that could be applied. This is also the reason why I would say the solution is not always in the books, regarding this topic.   Later on I stumbled upon a slideshare of Joshua Bloch stating the following: "Write to your API early and often." This is what helped me a lot.   But this statement can be expanded even more - to something like: "Let others write to your API early and often." In this way you can easily locate issues with your code design because others might not think the way you do and the code was designed for. Furthermore you can get input from someone that might use your code in the near future and you will know how he expects to interact with it. As soon as the API design is on a pretty decent level you can start implementing your code. And because the API acts as kind of a boundary, your code (the actual implementation with all its details) is forced in the right direction. Yeah, it's still possible to create a monolithic class handling all different things but it will feel wrong because you will need to work against the API.   The slideshare mentioned above can be found here: Google API Slideshare
  4. I would say that I'm a "From Scratch" type all the way.   I like to have full control over the things I do. This extends to "I NEED to have full control over the things I do" if there is anything mission-critical involved. The latter is not always possible when using 3rd party code.   Another point that's great about writing stuff from scratch: you will learn a lot. And that's a huge benefit in situations that might force you to decide whether to write the thing from scratch or go with an existing solution. The reason for this is that your knowledge empowers you to take several things into account that you might not really know about if you weren't writing something similar from scratch in the first place. You are even able to compare existing solutions on a more fine grained level which is always a good thing if you're trying to find something that fits your needs.     It would also be great to hear from people that were mainly using 3rd party solutions on projects that failed by doing so. (What are the reasons for this?)
  5. Thank you for this great article.   Your thoughts on technical debt pretty much reflect the lousy situation that i'm experiencing right now. The project itself has deadlines from hell. This is because the executives want to satisfy the customer with no regard for anything. In such situations you are always working on the limit especially if the team isn't that large. So you are making compromises on tasks that will lead to shippable software (hopefully) with a total mess under the hood.   So here is the bad news: You know that the software is badly written at several points but the next features need to get implemented to satisfy the customer "one more time". Hence you can't do anything about the critical state of the software. Instead you're building something on top of an unstable construct - what could go wrong :-/ After several iterations of this process you will come to a point where you can't implement anything without breaking the whole thing at another part you weren't aware of.   The amount of time that is needed to "repair" this huge clusterfuck your project has become could be pretty huge. In some situations you are better off hitting the delete button and throw it all directly into the trash bin.  But if one decides to tackle the task and do a massive refactoring you are loosing time. For sure the customer won't understand why you are not able to put all his requested features into the next version anymore. Consequently there is a chance you are loosing the customer in the worst case.     Conclusion (based on my personal experience): Never let the technical debt exceed a specific limit (depends on the size of the project, team size and several other factors). Otherwise you will pay the price - and it will be expensive!     I would love to read more articles from you :) Until then i wish you all the best with your project and your family.
  6. Yeah that's right. The procedure that you've explained will get important right after the input has been gathered in a raw state. Nevertheless i would separate the window input and the usual game input. A very raw sketch of my thoughts to this is attached to this post. The "IOHandler" will be the entry point to the system. One can't dive deeper into it to keep it as high level as possible. So in order to this, you need to register or deregister listener right there.   I guess you are right. One way would be to implement a high-level api that uses low-level stuff depending on the platform that you're using. So you have to deal with platform specific stuff just at a single point in the low-level part (Please correct me if i'm wrong). For sure it's sad to see everything being high-end and then one is struggling when implementing an input system caused by platform specific "standards".   But libusbx needs a chance. Even if it's just for the sake of learning something new i'll go to try it out. Thanks for the feedback so far.
  7. Hi NightCreature83,   thank you for your reply. Your offered links are pretty interesting and cover a lot of things i was thinking about. Unfortunately it is based on Windows and i want the input system to be running on other platforms as Linux and Mac as well (sry, i didn't mention this in my initial post). So in order to this there is a need for some standard that needs to be supported by all of these platforms and USB seems to get it right (on a low level).   While looking for some HID APIs, i came across the following one: http://libusbx.org/ It looks right for testing some stuff and trying to implement a prototype using it.
  8. Thank you for your reply. The timestamp is a nice hint though - didn't think of this.     That is quite true, but this is exactly the point that i want to avoid. Events related to a window should be handled by a window handler or a similar instance because that isn't input that will affect the behavior of entities within the game (like a player that is moving). Ok, if you're closing the window, then the game is affected but i think this would also be part of the window handler. This instance has to make sure that this kind of event is propagated to a kind of main system that is able to shutdown all parts of an engine, or a game in more general.   So this is why i found it pretty awkward that a window instance is required to handle game related input. But maybe its just me thinking in a wrong direction. But i will definitely have a look on a HID API and try to implement a prototype of my input system using it (Sending information to a USB device, like ForceFeedbackInformation seems to be an advantage over other libraries, like the ones mentioned in my initial post).
  9. Hi,   i'm currently trying to gather as much information on input systems as possible. In order to this i looked up some different libraries like GLFW and SDL. While getting in touch with them, i noticed that it is required to have an instance of a window to actually gain input information from the underlaying OS via that libraries.   So here is my question(s): Would you call it a bad practice if one would try to gain input information directly from the OS even if there is no window instance? (the input system should run fine without a window to do its job) The game itself would then decide whether to handle the input event that is emited by the input system or not because it has some knowledge about the window it is running in. If the window of the game has focus then the event would be handled. If the window has no focus then the event would be consumed or whatever but not handled. If doing so - are there any pitfalls one would have to deal with while the project is growing? What are typical approaches in commercial products to do things like this?   I really appreciate any information on this subject. Thank you in advance.        
  10. Hi,   I'm actually not sure if C# provides namespaces because there should be packages. But they are aiming at the same goal anyway. So if you are working with a base class from another namespace make sure to "mark" this in your code as well. Here is a short example: #include <iostream> namespace cars { class Car { public: void move() { std::cout << "The CAR is moving" << std::endl; } }; }; class Audi:public cars::Car { public: void someFunction() { move(); cars::Car::move(); } void move() { std::cout << "The Audi is moving" << std::endl; } }; int main(int argc, char* argv[]) { Audi audi = Audi(); audi.someFunction(); return 0; } The Code above results in: The Audi is moving. The CAR is moving.   But as long as you're not overwriting the base-class method it should be called anyway because you derived from that class. #include <iostream> namespace cars { class Car { public: void move() { std::cout << "The CAR is moving" << std::endl; } }; }; class Audi:public cars::Car { public: void someFunction() { move(); cars::Car::move(); } }; int main(int argc, char* argv[]) { Audi audi = Audi(); audi.someFunction(); return 0; } This code results in: The CAR is moving, The CAR is moving.   In addition to that i think that this is a bad code practice. Please correct me if i'm wrong but i can't figure out a situation that forces me to do things like that (I'm either overwriting the method or using the derived one)
  11. Hi again,   my suspicion is that you are not compiling the code with the MinGW compiler as mentioned in the Readme of the repository. If so then the built-in VS compiler will try to do the job. Referring to this Thread (sorry for cross-site linking) http://stackoverflow.com/questions/8525470/porting-c-compilation-from-mingw-to-visualstudionmake there can be several situations that are not covered in the standard or differ depending on the standard that is used.   So if you aren't compiling with MinGW as it is recommended please get active and do so. You can ignore my post if you're already using MinGW.  
  12. Hi there,   if I hit the link in your initial post I am redirected to the projects page on github. There is a Readme on the lower part of the site. It says clearly that this project has external dependencies including "libcurl" and "jansson". Furthermore there are Links offered so you can go there and download the libs mentioned above: libcurl http://curl.haxx.se/libcurl/ jansson http://www.digip.org/jansson/ So import the project and download these 2 libs. After that you have to link against them. You are doing this by changing your project properties. If you have finished this steps everything should be fine and you are ready to build the project.   I hope this helps you out.
  13. Hi there,   i'm sorry for not replying until now. So there are 3 Options i can choose from: a catalog system to map the elements used in the xml to its corresponding entities reflection existing xml marshalling frameworks like JAXB   So i tried out the reflection approach during the weekend and at some point i realized that i am not able to generalize all possible entities due to the fact that a button maybe has different attributes than a label.   A catalog system seems to be a much easier way to handle this. But in my opinion there is another problem: For every entry in the catalog system, representing a special widget, there must be another dictionary that contains every possible attribut for that special widget. This can grow a lot since more and more widgets are implemented.   In the end i will try out JAXB. As far as i read through some examples its mostly based on annotations and should be working fine. So thanks to all of you for your advices, it helped me a lot.
  14. Hi there,   i'm currently trying to write a kind of XML-Parser for my gui framework and i'm struggling with the object creation.   So a possible XML-File could look like this: <Window id="Notification" title="Notification" message="An Error occured while..."> <button id="Button_try_again" caption="Try again" /> <button id="Button_cancel" caption="cancel" /> </Window>  For iterate through all tags i'm using StaX. The name of each tag is accessible by calling the getLocalName()-method. Furthermore there is an corresponding class for each valid tag (just like window and button in the example above) and i need to get an object of one of them.   So here is a little snippet of what came to my mind to achieve this: String tagname = Staxparser.getLocalName(); if(tagname.equalsIgnoreCase("Window")) { // instantiate window class } else if(tagname.equalsIgnoreCase("Button")) { // instantiate button class } Well, this looks pretty much nasty and should not be done like this.   So here is the actual question: Is there a way to not use a whole bunch of if-else-statements to figure out what class needs to be instantiated? Is there a design pattern or anything else that is able to simplify the problem?   Thanks in advance.  
  15. Thank you for your replies. So this is what i've already done. The actual problem is more about how to arrange these information and put it all together in the diagram. Sometimes the amount of information is just too high and if you want to set all the dependencies visible in the diagram, you have to work on several classes at the same time. But this can get counter-productive simply because you are working a bit here and a bit there. So i was looking for something more abstract, something that has a strict procedure (kind of guideline).     This is something that sounds great to me because it breaks down the complexity. I'll give it a try and keep you up to date on how it evolves.   Moreover i found some interesting articles about CRC cards: http://c2.com/doc/crc/draw.html http://de.slideshare.net/RapPayne/crc-cards http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html#CardReader http://www.extremeprogramming.org/rules/crccards.html http://www.extremeprogramming.org/example/crcsim.html