Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

499 Neutral

About nox_pp

  • Rank
  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:[/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. nox_pp

    Programming Music

    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:     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. nox_pp

    Voxel Levitation and Rain

    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.
  6. nox_pp

    Lua troubles

    No, you don't need to pop them off the stack. Anything below the results is automatically discarded by Lua. 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: 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); // } I track the state of the stack in comments next to any functions that modify the stack. Also, I've found this site to be an invaluable reference.
  7. Variadic templates are ridiculously powerful, and antiquate a lot of redundant C++03 template metaprogramming. Initializer lists 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. 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);
  8. nox_pp

    How/Who create the GameObjects?

    Segregate your shared data, so that you can better identify the character of it--what it means and where it comes from. Then, you don't need to expose it globally in your Game class, you can just pass it between scenes that need it (as parameters.) Yes, it's more work, but it's also more explicit, and ultimately much safer. Yes, for a variety of reasons. What Servant of the Lord said is true, and will work well if you want to carry on with your design, but the design is flawed. Think to yourself, will a virtual Update method always be enough to fully achieve the purpose of a particular GameObject? The answer is no. Which means that you will unavoidably have to pluck GameObjects out of wherever they polymorphically reside, and cast them to their proper types. This is folly. How can you be sure of the types, except by experimentation with dynamic_cast or divine knowledge? Don't store heterogeneous types homogeneously. You might think that they're homogeneous types, because they derive from the same base class, but they're nearly useless if they're never casted. It can seem messier to deal only with concrete types in this instance, but it's really only being more honest about what is actually happening. Furthermore, there should be a strict separation between GAME code and ENGINE code. This looks like Game code to me, so it doesn't really matter if it's directly oriented toward your game, and concretely references your derived GameObjects. If you've got too many derived GameObjects for this to be feasible, that's merely an indicator that something else is wrong.
  9. You're controlling the speed of the ball, but you aren't controlling the speed of the animation. In the same way that you calculate "amount" in PongBall::move, you need to calculate what frame of the animation you should be on based upon what fps you would like your animation to play at. Only increment mImageIndex when you've accumulated enough time for a frame. Something like this, following the pattern of your code: mAnimationAccum += ANIMATION_SPEED * pElapsedTime.AsSeconds(); if(mAnimationAccum >= 1){ mAnimationAccum = 0; ++mImageIndex; } Say ANIMATION_SPEED is 30, for 30 fps. Then everytime mAnimationAccum == 1, 1/30 of a second has passed, so we increment the frame we're on and reset the accumulator. You'll probably want ANIMATION_SPEED to be 5-10 fps, but I suppose it depends on how fast the ball is moving on screen.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!