• Content count

  • Joined

  • Last visited

Community Reputation

102 Neutral

About saracen

  • Rank
  1. C++/DX11 Code Organization

    I can see maybe a few ways you can go about learning what you need to know: 1. game programming books Many of these books introduce beginning programmers to game programming. They provide a good primer on basic game architecture/constructs like the game loop, game networking, sound/audio management, user interface, game concurrency/thread management, etc. If you want a basic intro (looks to me like this is what you want now), this is a good way to quickly learn what you need. 2. read source code The 1st suggestion above gives you only the most rudimentary intro to game architecture that works for simpler games. For "real world" game design/architecture that solves some really challenging problems with distributed players, huge worlds, dead-reckoning, etc, you should go dig into source code. [url=""][/url] [url=""][/url] Alot of these are in C/C++ so looking at the header files will be a good place to start. There are obviously alot more open sourced code lying around. But these are the 2 I actually dug into. Admittedly they are abit archaic by now. 3. read forums There are quite a bit of discussion on specific stuff like game networking, texture management, world creation, on gamedev itself, as well as other blogs/portals. Go Google them.
  2. How to Log and stay Modular

    I am guessing you have an existing logging system implemented as per your snippet that forces you to specify the logfile name every time you want to log something. And you are not comfortable with having to specify this logfile name everywhere in your code. Well the simplest solution is to just create a global variable for the filename that is initialized/set in only one place (if your code is like mine, you would probably have one or more header files somewhere that declares some global enums, variables, references, etc). And of course you could do stuff like having a startup object read from a config file to populate all these global variables when your game starts up. Another way is for you to write a wrapper class around the existing Log class. This wrapper will manage (and hide) all the details of what logfile to open, when to open it, when to write, etc. So wherever you need to log a message, just call the constructor with the message and just let autoscoping take care of destroying the object. [code]LogWrapper EngineLog("this is a log...");[/code] I have a logger class that collects log messages together in memory until a certain size before opening the logfile and dumping everything in. Works for logs that do not deal with debugging crashes!