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

Drakkcon

Members
  • Content count

    1911
  • Joined

  • Last visited

Community Reputation

612 Good

About Drakkcon

  • Rank
    GDNet+
  1. Quote:Original post by Codeka I would say it's because class names are for more than just registering your own class. There's also the "well-known" class names such as "BUTTON", "EDIT", "LISTBOX", etc. They need to be strings so that you can refer to them in external files (like dialog templates). That's my guess anyway. Yeah, I guess you're right, that's a good reason for their existence.
  2. It seems at odds with the rest of the API. Pretty much everything is based on handles like HWND and HMODULE, so I would expect that RegisterClass(Ex) would return an HCLASS. The ATOM behaves like a handle, but I still have to generate a string in my win32 wrapper. When I wasn't using a wrapper and was just using the naked SDK I usually ended up just using global constants anyway. So does anyone know?
  3. Alright cool, and each code unit in UTF-8 is a byte so I can be like: stream.write(str.data(), str.size()); and it'll work right. Thanks everyone, for your help. Edit: and by work right I mean it will copy the entire buffer through the stream without clipping it off if there are multi-byte characters.
  4. Quote: The short of it is: Unicode in C++ is a mess. size() and length() will get you the number of code units in the string, not the number of code points. This is because neither std::string nor std::wstring know which encoding is being used. Oh, so size() and length() are the length of the buffer? Awesome, that's what I was hoping (although I can see how it would suck if you actually wanted to iterate over each character). Quote: I typically go with the old stand by of ofstream << string, but maybe that is just me. Does this work with binary streams? If so I will use it. Thanks a lot both of you!
  5. I'm using std::string in my project, and I have selected "Unicode" as my character set in visual studio, which I assume means UTF-8. Now, I want to just be able to do this: stream.write(string.data(), string.size()); But looking at documentation about string has made me uneasy, since every reference I have found states that size() is the same as length() and gives you the number of characters in the string. However, in the case of most strings containing non-ascii characters, the size of the buffer is different from the number of characters. How do I get the size of the actual buffer? If there is no way, how does one save a unicode string to a file in c++?
  6. Oh, check this out too: Buzz Machines
  7. I was having a similar problem as you, basically I ended up having to synthesize on my own! Yes, MIDI only describes synthesizer instructions, and requires a synth be present to hear anything. Windows has a default (kind of crappy) synth that works okay for what I use it for (listening to video game music), but Linux does not come with one by default and the user will have to map a soundfont and do a bunch of other stuff. The windows synthesizer is just a big .dll that gets loaded if you need it, and it's proprietary. As you mentioned, soundfonts are big. Basically, you need to synthesize your own music. I used the SDL api, which just gives you a big audio buffer for you to write in. Start with the simple geometric waves, the easiest is a square wave, to generate a square wave, you do something like this: //this is one second of sound unsigned char* soundbuf = new char[22050]; //assume 8-bit 22,050 samples per second unsigned frequency = 400; //400 times per second, 400hz unsigned distance = 22050 / (frequency * 2); //Half the width of the wave cycle unsigned minPos = 100; //the difference between min and max is the amplitude unsigned maxPos = 200; //which determines how loud it is, use the full range //at your own risk for (int i =0; i < 22050; i++) { for (int j = i, k = i + distance; j < k; j++, i++) soundbuf[i] = minPos; for (int j = i, k = i + distance; j < k; j++, i++) soundbuf[i] = maxPos; } //now play the square wave playSoundBuf(soundbuf); //not any API that I know of, but you get the idea Sawtooth wave and triangle wave are the other basic geometric waves. You create complicated instruments through various processes, but the easiest is probably subtractive synthesis: ' Wikipedia Article on Subtractive Synthesis Which basically involves starting with a geometric wave and running low-pass filters over it until it sounds right. If you want to play two notes at the same time, add the waves together and divide by two to correct for the increased volume. Basically you average them. This is all a lot of fun, and you can do really cool things that most game programmers don't know how to do, like make your own file format where instruments are stored as basic waves with filters applied and the actual notes are just instructions to play certain instruments at different frequencies. Edit: Oh yeah, you mentioned languages. Anything that gives you a sound buffer! So pretty much any platform that supports DirectX or SDL. [Edited by - Drakkcon on August 30, 2009 2:10:05 PM]
  8. That's heartbreaking! It's like your good friend just gave you up, let you down, and just ran away from it all. I hope no one else ever deserts you like this again boolean.
  9. Do you mean this? It actually looks quite nice from the screen shots (as an editing tool).
  10. Quote: The idea with events is to help with MVC separation. Your button doesn't need to know how to do the task that's associated with it; it only needs know that it controls some object, and to tell that object "hey, I've been clicked!" The object does the rest. In simple systems, you can get away with just having the button call one of the owner's methods. In more complicated systems, this inhibits reuse (in particular, you eventually need a similar looking button to "drive" different kinds of objects in the Model). So for a while you can get away with some kind of signal-and-slot system, or function pointers, or something. But eventually you generally refactor to events. (I'm actually in the middle of refactoring something of that sort to a more event-like system at work. Though it's in Python, so "function pointer" is rather replaced with the moral equivalent.) It avoids having the button need to know about what it's talking to., or even about its conceptual owner. It only needs to know how to construct events and put them in the queue (or perhaps send them to a global Facade object for the model, which handles dispatch). I think I understand what you are saying here, but it's difficult for me to grasp because I have never worked on a large system before. One thing that seems appealing to me is to avoid using a global event manager, instead using an event manager for each subsystem that requires the use of events. I can think of three systems that should use events: input, gui, and game. It makes sense to me for keyboard input to be controlled by events (although I have no idea how you would handle "holding a key down"), gui programming is known for event programming, and many games are scripted with events in mind. But does this defeat the purpose of using an event system? If each subsystem only needs to communicate with itself and some logic (model?) would that defeat the purpose of using events instead of, say, callbacks? Quote: I only wish I were a tenth that organized :( Oh, well. Personally, I have always wondered how people have the motivation to keep project pages and journals going. Quote: First try really hard to put the whole "manager" concept out of your head, TBH. Just create the objects. Do any management that seems to be *necessary*, *when* the need is proven. Okay, this sounds good. I'll just use a manager when it's time instead of designing for it from the beginning.
  11. Quote: (EDIT: Careful of order of initialization! And if you have a cyclic dependency, you'll have to use pointers, because references must be initialized, and there's a chicken-and-egg problem with the initialization.) Ooo, I didn't even think of that. Thanks for warning me, I'll try to avoid that. It seems similar to the circular reference problem with shared_ptrs (except dealing with initialization and not freeing). Quote: But you should consider, for each pair of subsystems, if they really need to talk to each other like that. Consider, for example: instead of talking to a SoundManager, construct a Sound object. The Sound object can register itself with a Manager if needed (or simply play with static data of the class), but the calling code needn't know that Manager (or static data) exists. This is how we get object-oriented ;) This is a flaw in my current project right now. The way I originally envisioned it, I would create the individual parts of my engine like middleware (they don't talk to each other), and then create an event system. The components would not be aware of the event system so I would wrap them with manager classes that would expose methods allowing me to create, destroy, and perform special actions with objects, referenced with a string and using std::map. These managers would raise events whenever you did any of these things. This seems like a pretty clunky system now that I look at it (especially the name-based lookup). I'm not really sure how I would do such a thing now. I guess you'd have to make each class event-aware, but then how would you tie in 3rd-party libraries to your engine? I was reading the book "Game Coding Complete" and Mike McShaffrey recommends strongly that you do event based programming, but I really don't see what the benefits are. Anyway thanks for all your advice on my code, and also advice you've given to me in the past. Do you have a website for all the coding you do? They say "don't read source code" but I get the feeling that reading yours would be pretty educational =)
  12. Quote: Er, how exactly is that? Do you just create a local Game instance in main() or something? Yes, actually: int main(int, char**) { Game game; game.Run(); return 0; }
  13. Quote: that is being handed out to any thing that wishes to use the event dispatcher, or am I confused? No, it's only being handed out to that specific VideoSystem instance.
  14. Also, thanks for your help everyone, specifically SiCrane, ToohrVyk, and mossmoss. Sorry again for the miscommunication that confused everyone into thinking that I have a list of references stored in an STL container.
  15. The class VideoSystem: class VideoSystem { private: const EventDispatcher& dispatcher; public: VideoSystem(const EventDispatcher& dispatcher) : dispatcher(dispatcher) { dispatcher.RaiseEvent(VideoSystemCreatedEvent()); } }; Will not be stored in an STL container.