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

nox_pp

Members
  • Content count

    58
  • Joined

  • Last visited

Community Reputation

499 Neutral

About nox_pp

  • Rank
    Member
  1.   I feel you, I do the same thing from time to time.     I do, extensively. I sometimes have to change things, for instance to account for new dependencies or changes to the way they need to be linked as new versions are released. And really, in practice, your directory structure is probably not as fixed as you'd like it to be. Also, new platforms are not as straightforward as they should be, and generally require at least a little bit of custom code. I can deploy new clean projects using my game engine to Windows, Linux, iOS (simulator AND hardware), and OSX with my current build scripts, but getting to that point was not at all trivial...although that is the intention of CMake. I gather that adding support for Android will be another big hassle.     Your approach could work, but you might as well just let them parameterize your tool in the first place with their desired settings. I use the same script to generate slightly different builds for the iOS simulator and iOS hardware: cmake -DIOS_PLATFORM=SIMULATOR vs.  cmake -DIOS_PLATFORM=OS Of course, I can put these in different build trees, and I can rerun cmake to update those trees as project settings change, which certainly happens. It's not so hard to add basic command line arguments. I don't know enough about your exact use case to comment further. I've found CMake to be tremendously obtuse, so I have a hard time recommending it, it's just that at some point you might realize that your tool is just reinventing the wheel and have to concede defeat anyway (I'm not saying that that's the case here, yet :p)
  2. Greetings from Purple Pwny Studios, it is with great pride that I announce Between Scylla and Charybdis, a physics-based game of aquatic avoidance and survival.    [media]http://www.youtube.com/watch?v=rLJTJxKtAVA[/media]   If you would please take a moment to like, share, and subscribe for future updates, I would be forever in your debt. I'm finding it otherwise difficult to rise above the noise of other promotional venues.   This is definitely the most serious I've been about any single game yet, serious enough to stop taking on new contracts and pursue this with everything I've got. I'm taking a very refined and artistic approach to the design, as I tend to in all of my work. I'm purposely avoiding common overused game tropes like points, lives, leveling, guns, etc. because I think they're anachronistic crap that can give a bad game enough structure and familiarity to seem like it's actually good. This is a risky move, I know, but I'm not interested in doing it any differently. There are enough crappy games out there, the world doesn't need another.   Of course, BSAC would be nothing without the other half of Purple Pwny Studios, our artist, Lux. As a fan of classic Disney films, her interest lies in juicy traditional animations and carefully hand-painted backdrops and other assets. Here are some of her works in progress:       See more: http://imgur.com/a/iNNbg   I've also been taking screenshots from the first day of the project until now, which represents roughly 2 months of constant work. Of course, I started with quick programmer art, and plenty still remains:       I've compiled these screenshots, and others, into a gallery.    In closing, here's a piece of concept from another of the projects that we've been working on behind the scenes. Check out Lux's Deviant Art for more like this, and please tweet and otherwise share our work so that we can continue making such nice things without fear of going broke. Thanks so much, and feel free to ask me anything!  
  3. Sounds like something that can be easily accomplished with any build system. CMake comes to mind. It sucks, but perhaps less than the alternatives. Anyway, you would just write a CMakeLists.txt that will create your given directory structure as necessary and create properly configured project files with your pre and post-build hooks, compilation arguments, dependencies, library/include paths, a stub codebase, and whatever else you want.    Keep this CMakeLists somewhere handy, copy it to your new project root, and then just run something like:  cmake -DPROJECT_NAME=GameX whenever you want to generate a new project. This all depends on how you write your CMake script...it can be quite powerful if you so choose. Doing it with CMake would also grant you some key features like automatic dependency resolution, minimal rebuilds/reconfiguration, and some degree of reproducability and platform independence. If you write a script on your own, it probably won't be general enough to work anywhere but your exact environment...cross-platform or otherwise.
  4. The bulk of the crowd sounds to me like streaming the sound of the entire crowd while opening/closing a low-pass filter over the sound depending on the "excitement" level. There might also be some random little one-shot cheers for "color," and probably gain modulation running in tandem with the filter.   As far as the dynamic music goes, this wouldn't be too hard to do on your own, but you'd have to make a sequencer that can synchronize clips to some clock at a given tempo. Take a look at Ableton Live's session view. It allows you to arbitrarily cue clips synchronized to a global clock. This keeps everything running in time, all you've got to do is make clips that work together.   This little demo is OK:   http://www.youtube.com/watch?v=heLMchbrQvo   He's swapping out entire songs/sections of differing granularity in real time, but if you try it yourself you'll better understand what's going on. I'm not saying to use Ableton, just copy the way that it works.
  5. If you're using C++, and [i]not[/i] using the STL, you're doing something wrong. Yes yes, there are exceptions to this rule, but if you're in a position to ask a question like this, you are not the exception. Anyway, as zacaj said, use an std::vector. Or, perhaps an std::map if you want more convenient and [i]potentially[/i] faster lookup.
  6. Shit, man, this looks sick. I like the aesthetic way more than most voxel based games these days. Good work! [url="http://youtu.be/7h_hObwKjNw"]Here's a gameplay video[/url] for anyone interested.
  7. [quote name='Shaquil' timestamp='1351608227' post='4995433'] I know one solution is to load the code as a string of characters from some outside file and pass that to the function. Or, if I just have the wrong attitude about this, what might be some wise options for loading up the script from some outside source? [/quote] It's not quite that complicated. What you want is [url="http://pgl.yoyo.org/luai/i/luaL_dofile"]luaL_dofile[/url]. No need to manage the file streams yourself.
  8. [quote name='Narf the Mouse' timestamp='1351491653' post='4994955'] Welcome to your first dose of politics. The rest of your life will be spent dealing with people; best you learn how. [/quote] Sure, if you sorround yourself with dickheads. It doesn't have to be this way.
  9. [quote name='riuthamus' timestamp='1351603450' post='4995393'] I guess our major concern is really scaling of the images when you increase or reduce the resolution size. For the most part, that is. [/quote] Unless you generate the graphics on the fly, you're not going to be able to scale them infinitely. What Xanather mentioned is the standard way of achieving scalability for rasterized rectangles. Other than that, I would render to an OpenGL surface or image file using [url="http://www.cairographics.org/OpenGL/"]Cairo[/url] (or similar): [quote] So why would you want to mix vector-graphics rendering, provided by cairo, with OpenGL in the first place?... - Create pristine texture-maps, which are resolution-independent and combine those with your custom mip-mapping. - Have animated vector-graphics as head-up-displays or overlays in your OpenGL-program. [/quote]
  10. I don't know about PhysicsFS, but I've used [url="http://www.nothings.org/stb_vorbis/"]stb_vorbis[/url] to decode a vorbis file kept in memory. It's written in C and in the public domain. EDIT: I see that now that you want to play Vorbis files, not just decode them. To that end, vorbisfile is not a replacement for SDL_Mixer, nor is stb_vorbis. For output, you can use [url="http://www.portaudio.com/"]PortAudio[/url] or [url="http://kcat.strangesoft.net/openal.html"]OpenAL[/url], among other things. For decoding, you can use anything--vorbisfile, [url="http://icculus.org/SDL_sound/"]SDL_Sound[/url], stb_vorbis, or [url="http://kcat.strangesoft.net/alure.html"]ALURE[/url].
  11. [quote name='futlib' timestamp='1351140696' post='4993679'] The component-based approach seems like a good idea, definitely more flexible. But I'm not sure if it's the right choice in my situation. I'm working on a small-ish 2D game with pretty simple gameplay, mostly myself. You're saying: "It’s not that an inheritance based entity system is inherently wrong per se, but in large systems it tends to become an impossible to manage web of sloppy code". I'm not working on a large system, I think it makes sense to keep things as simple as possible. [/quote] FWIW, the component based approach is only more difficult while you're wrapping your head around how it works. I think it's easier after that, but I feel where you're coming from anyway. [quote name='futlib' timestamp='1351140696' post='4993679'] And it contains other widgets, to which it forwards any relevant input. [/quote] Is it otherwise impossible for Entities to contain other Entities? It's not uncommon to want a parent-child relationship between entities in a game. Say, there's a knife on the ground, and your character goes and picks it up. You could just "attach" the knife to the character, if you had that capability. [quote name='futlib' timestamp='1351140696' post='4993679'] Now how does that distinction fit in with scenes? Should scenes be able to handle both entities and widgets? Should I have a special kind of entity that acts as a container for a widget? I'm stumped. [/quote] Both solutions are reasonable, but if you're starting out by saying that Widgets are fundamentally different than Entities--by putting them in separate trees--then you can't expect to handle them as if they are the same. You could maintain your WidgetSpace separately from your Scene. In WidgetSpace things are oriented and positioned with normalized coordinates relative to the screen, in the Scene things are positioned in absolute coordinates relative to the world. WidgetSpace can forward input for Widgets to handle on their own, while Scenes can handle input for Entities.
  12. [quote name='futlib' timestamp='1351094906' post='4993466'] You're right, I could just rename Sprite to Widget and my object hierarchy would suddenly make sense. In Qt for example, widgets can be nested. But I just thought it felt wrong to call it Widget, since I'm after all working on a game here... There is a lot of UI, but there's more, and I don't want the UI to dominate the terminology in my code base. When I add characters moving around, they would probably end up deriving from Widget... [/quote] What [i]is[/i] a Widget? What inextricable properties does Widget possess? If it's synonymous with Entity, like Sprite was, then the answer is probably "nothing." A Widget on its own carries no inherent properties. You're almost always going to end up having an invisible Widget, or a Widget that doesn't care about input, or that can't move, or has no position, or has a position in 2-space instead of 3-space, etc. etc. To me, this just says that trying to fit your game objects into a hierarchy is a bad idea, they're not concrete enough. That's why the component based approach has caught on so well, it fits the problem space much better than a more vanilla approach to OOP. If you broke your current mental concept of Widget out into a class that could be contained and used by any game "Entity", then you could share the provided functionality between both typical "game entities" and GUI elements with none of the troubles of making this work via inheritance. For instance, an in game character and a button could both be Entities that contain a "Clickable" or "Inputtable" component. Some InputDispatcher class is aware of these components, and dispatches input events to them, possibly after filtering the input into some nice format or sending only events that a particular component has said that its interested in. [quote name='futlib' timestamp='1351094906' post='4993466'] I think I'm mainly struggling with how I can have my UI (screens and widgets) fit into the same object system as my entities and scenes. [/quote] I've faced the same problem. What I did is model Button as an entity that contains Drawable, Inputtable, and Positionable. Some properties set in Inputtable say that it's only interested in hearing about click events, and some properties set in Drawable say that it should be drawn relative to the screen, rather than the world, and some properties in Positionable give it a greater z coordinate than anything else in the scene (so that its always drawn on top.) FWIW, I [url="http://purplepwny.com/blog/component_based_entity_system_design_part_1.html"]wrote a little about component based entity systems[/url] years ago, which might help to point you in the right direction.
  13. Your problem is that you're abusing inheritance. You should [url="http://en.wikipedia.org/wiki/Composition_over_inheritance"]favor composition over inheritance[/url] unless you have reason to do otherwise. You don't have true IS-A relationships in your hierarchy. Button is not a Sprite, it just contains a sprite. Likewise for Label and Scene. These are all things that CONTAIN sprites, and if your hierarchy were flattened to reflect that truth, you wouldn't have a problem with button, or anything else, containing any arbitrary number of sprites. [quote name='futlib' timestamp='1351066037' post='4993355'] In the latter case, how would I be able to reuse the code for drawing and forwarding input to all children of a sprite? [/quote] Sprite shouldn't have children. Sprite is sprite, it's singular. It also does not have means for collecting input--that's far beyond its purview. What you may want instead is some base-class GUIElement. This class [i]could[/i] provide default implementations for listening to and forwarding input, as well as adding and removing children. The classes that you derive from GUIElement can hold as many sprites as is appropriate for whatever particular element they are representing.
  14. [quote name='Endurion' timestamp='1350979567' post='4993023'] In static int spTrWra(lua_State *L) you return 0, indicating that you pushed 0 items on the stack. However the three incoming parameters are still there. You need to pop them off the stack. [/quote] No, you don't need to pop them off the stack. Anything below the results is automatically discarded by Lua. [quote name='Psilobe' timestamp='1351002852' post='4993098'] I found a section about lua in one of my books and it seems I'm going the wrong way with this and combines calling a lua function in c++ while at the same time trying to call a c++ function in lua so I'm currently reading up on the subject. [/quote] Your code in spTrWra looks reasonable. However, in the cMap constructor, you call cMap::init, before any Lua code has been run. Therefore, lua_getglobal(L, "init") just pushes nil to the stack. Furthermore, when you call lua_call, you're saying that there are 3 arguments to some function on the top of the stack, presumably the global "init" (which is actually nil here,) but you only push one argument onto the stack, "this." You probably intend to call luaL_dofile(L, "map.lua") before you call cMap::init, assuming that that is where you define the lua function "init." I find it helpful to annotate my Lua C API usage, like this: [CODE] void cMap::init() { lua_getglobal(L,"init"); // nil lua_pushlightuserdata(L,this); // this nil const int s = -1; if(!lua_isfunction(L,s)) { //another buggy cout } const int a = 3; const int r = 0; lua_call(L,a,r); // } [/CODE] I track the state of the stack in comments next to any functions that modify the stack. Also, I've found [url="http://pgl.yoyo.org/luai/i/lua_call"]this site[/url] to be an invaluable reference.
  15. [url="http://en.wikipedia.org/wiki/Variadic_template"]Variadic templates[/url] are ridiculously powerful, and antiquate a lot of redundant C++03 template metaprogramming. [url="http://en.wikipedia.org/wiki/C%2B%2B11#Initializer_lists"]Initializer lists[/url] are a much needed addition to the language. They add the ability to make classes feel more like POD's, even when they aren't. [CODE] std::vector<int> ivec = {1, 2, 3, 4}; //vs. std::vector<int> ivec; ivec.push_back(1); ivec.push_back(2); ivec.push_back(3); ivec.push_back(4); [/CODE]