scyfris

Members
  • Content count

    21
  • Joined

  • Last visited

Community Reputation

183 Neutral

About scyfris

  • Rank
    Member
  1. Thanks for all the useful information, I hadn't thought about some this!   I think much of the responses have been in favor of allowing players to get "stuck" as long as 1) this is a part of the game design and is taken into account with the appropriate level design, and 2) the player is well aware of this mechanic, is given useful information about such mechanics, and is given useful information about when they have reached a point where they can not make any new useful moves and must restart somehow OR this information is conveyed natural through good level design.           I like the idea of being able to "undo" certain moves.  Unfortunately for my game, encapsulating "moves" is a bit difficult because the gameplay is a mixture of "continuous motion" movements (moving around the level), and discrete "level reconfiguration actions".  I think the latter type of mechanics would allow for undos, but trying to convey to the player what exactly constitutes a "move" and how to undo it for continous motion is a bit difficult in my situation.  I know there are some games that have done this before, but for my game I don't think it would nessesarily work well.  Implementation probably wouldn't be too bad, but I'm a bit limited in user interface (it's mobile) and would like to leave the complexity in the user interface this would make out of the game.  It's something I will probably explore in future games though.  Also the game I have in mind should be an entire level on one screen, so checkpoints might not be easily designed.         Cool I like this concept.  I'm not sure it would work in my game, but I think this would work in a lot of cases (I remember dungeons in Zelda applying this design).         Thanks, I'm not sure it would work in my specific case, but I might experiment with this idea.         Ya, I think finding a balance between "too hard" and "hand holding" is key.  I like the idea of the player required to perform a specific set of actions in a certain order, but this needs to be clearly communicated to the player, and the player needs to know when they've gone past the point of no return.  As long as that is communicated clearly, then in the absense of a notification of failure, the player will continue to try under the assumption that they haven't messed up yet.  If that is not communicated and the player keeps trying despite this unconveyed information, I could see the player getting very frustrated in the wrong way.
  2. Hi All,   I am developing a bit of a puzzle game, but I am trying to figure out whether to implement mechanics which would allow the player to get "stuck" and restart the level in order to finish.  I was wondering if anyone had any rules of thumb on this?   To give a bit of context, the game is a puzzle game where the level is manipulated and reconfigured such that the player can get to the exit.  There are certain obstacles, such as moveable blocks, deadly blocks, etc.  The player would perform a combination of moves which would alter the placement of the obstacles such that the player can get to the end.   I am thinking about whether to add an obstacle similar to a "one way door", where the player can go through, but can not go back.  What this game mechianic implies is that at a certain point, the player must have configured the obstacles/level in such a way that she can get to the exit after going through a (or multiple) "one way door".  With this mechanic, a player could be at a point where they would have to "restart" the level in order to retry if they don't do things in the right order before going through the "one way door".  I'm not sure I like this.  Many great games with puzzle elements don't have a "suicide" mechanic, so the level designers had to take great care to not allow a configuration to arrise such that the player could get stuck (I don't consider exiting to menu to restart level or resetting the game to be a mechanic, it is a work around to get around poor level design in most circumstances).  But, I'm wondering if there are cases where this is acceptable?  I have seen some well-designed games with this mechanic (Little Big Planet for instance), but I still don't feel right about it.   So, there are three possibilities:   1) Player is allowed to get "stuck", forcing them to either a) "suicide" themselves if that is a feature of the game (with or without a cost), or b) reset the level using a work around, such as "exit to main menu, restart level" or something similar.   2) Levels are designed such that a player can NOT get stuck, thus allowing them to solve the level from any configuration at any point in time in the level.   3) Hybrid of 1&2: Players can NOT get stuck during completion of main goal of the level, but there is some auxilery goal (such as a bonus item, or something) which the player could lose the ability to achieve at some point in the level if they haven't done things in a proper order.  This could add some replayability to the level (i.e. the player beats the level, then replays the level over and over to try to figure out how to get the auxilery goal).   So I guess my question is, are there any common design patterns about the above possiblities, when or when it is not acceptible to use each?  I personally like posibility 3.   Thanks!
  3. Game a Week

      This video is really nice.  This gives me another idea.  I usually focus on programming, game component design, and visualizing the games during the game a week, but this makes my skills kind of one-dimensional. Instead it would be interesting to focus on a completely different sub-craft of game development, like level design or asset creation (art, music, other?) for a week, and then do a write-up on what's learned as well as the results (no actual game, just whatever content is iterated on or created).  This will help to understand the other sub-crafts of game development deeper for when I work in teams with artists/musicians, etc.  It will also be a good way to become familiar with those pipelines and tools in those fields.
  4. Game a Week

      Hey, no problem, event though I can't read spanish well it's still nice to see your games.  I also added your name in the list :-)  Thanks for your input!!     I think this is really important.  I've been a programmer for a while, and I still find I underestimate the amount of work required for things.  I think that for aspiring game developers (indie or not), it's important to be able to predict the amount of time it will take to work on something, whether it be contract work or reporting to your manager how much time you think a task will take.  This is a skill, and it takes practice to improve that skill in time-estimation.  Writing more and more games means that you can start seeing what is realistic to accomplish in a certain amount of time versus what is unrealistic, and this is always helpful for any project that's taken up.     Wow, this is really interesting.  Can you think of anything that you can attribute to this?
  5. Game a Week

    Yea, there have been some recent blogs and ideas for one game a week floating around.  The goal is for people to start writing games, and start small so that it's not as easy to fall into the big ideas trap (have a great idea, a small team...3 months later realize it can't be done with the resources, and there is still nothing to show for it).  The idea is that if you design for small week projects ,you will get your creativity out, start prototyping your ideas, and hopefully gain experience in writing games/programs.  There are other benefits, but those are just some.  Thanks for the link, I think I have heard of it but I forgot all about the onegameamonth.   Awesome, will take a look.  I looked at it a little bit and he has some great things to read in there.  Thanks!   Thanks for the links, I'll edit them in the original post to keep track.
  6. Game a Week

    Does anyone else has experience doing a one game a week/2week exercise, or know of others doing it?  It would be nice to get your input on your experience.  I've started doing this at my blog http://gawahse.blogspot.com/ and would appreciate any criticism or comments anyone has about the games I post up there.  They are usually 1-1.5 week long development while I do school/work at the same time, so each one just really investigates one design element.   I would be interested in collecting links to everyone doing this.  The few I have found are:   Adriel Wallick's blog: http://adrielwallick.com/ My blog: http://gawahse.blogspot.com/ LessMilk: http://www.lessmilk.com/ Jayenkai's website: http://jayenkai.socoder.net/ Mondongorongo's blog: http://mondongorongo.wordpress.com/ Jonathan Gaiser's blog: http://gameaweekchallenge.tumblr.com/   Some articles about it:   http://indiegames.com/2014/02/what_one_dev_learned_while_doi.html http://www.gamasutra.com/blogs/AdrielWallick/20140226/211761/Make_Many_Games_Learn_Many_Things.php http://www.gamasutra.com/blogs/RamiIsmail/20140226/211807/Game_A_Week_Getting_Experienced_At_Failure.php   Thanks!   Edit: I'll put links from posters on here to keep track of them   One game a month -- http://onegameamonth.com (Thanks BHXSpecter ) ManTis' Gamedev Journal -- http://www.gamedev.net/blog/704-crawling-with-ideas/ (Thanks slicer4ever) 11 day level design process overview -- https://www.youtube.com/watch?v=pj8cbC2YnwU (Thanks Tutorial Doctor)
  7. Voxel Theory & Practice

    [quote name='gboxentertainment' timestamp='1344766652' post='4968667'] Wouldn't it be faster to start from the bottom [/quote] I don't remember how the Laine paper reconstructs it, but I do believe the Crassin paper does construct bottom-up. They treat the fragments produced from the graphics pipeline as leafe nodes of an octree, and then build the tree up from these leaf nodes in parallel (I think on the compute shader). Essentially the idea you mentioned. IMHO, building bottom-up or top-down depends on a few things: 1) you use the right construction that makes sense for your application, 2) the construction method you pick is not overly-complicated for your problem 3) parallelize node construction as much as possible. (important if your on the GPU, perhaps not so much if you're on CPU, and perhaps not important at all if it is done as a preprocessing step and you don't have dynamic objects). Obviously when using the pipeline, it is faster to construct bottom-up since you have the leaf nodes after the fragment shader (all in parallel), but if you're on a CPU or something, you may just want to construct the tree top-down since that way is generally easier.
  8. Voxel Theory & Practice

    [quote name='gboxentertainment' timestamp='1344747212' post='4968617'] I guess I'll need to read into the fundamentals of voxels and octrees first to gain an understanding. [/quote] I really love octrees. They are used everywhere. You can also experiment with a quad-tree in 2-dimensions if you are coding one up. It may be easier to visualize the tree that way. Also, I edited my first post. When I said you don't need 3 numbers for cubical voxels, I was referring to the numbers corresponding to voxel height, width, depth. you will still probably use three numbers to access the voxel or derive the 3-d location for the voxel (index values are fine if it is a grid). Ooo Ooo, sorry for a TON of edits, but I also found this page which might be helpful, especially the links which are referenced: http://gamedev.stackexchange.com/questions/17050/which-data-structure-should-be-used-to-represent-voxel-terrain
  9. [quote name='Kurasu1415' timestamp='1344666039' post='4968347'] 1) What is the best way to apply different shaders to different objects? [/quote] Switching shaders per object drawn could incur extra overhead. Say you have 4 objects, 2 shaders. Object 0 and Object 2 use shader 1, Object 1 and Object 3 use shader 2. If you draw object 0 - 4 in order, then you would have to bind a different shader every draw call which is enefficient (any kind of OpenGL state changes should be minimized). I would batch your object renderings so that you bind shader 0, then draw all objects that use shader 0, bind shader 1, draw all objects that use shader 1. This can be accomplished in multiple ways. Probably the simplest (assuming you are in C++) is to use std::map with a key of shader, and value of std::vector of your objects. Then iterate over the map, and for each shader 1) bind shader, 2) loop through vector value and draw objects. [source lang="cpp"]//Say this is your shader wrapper class class shaderClass { Bind(); //... }; //Some wrapper display class for one thing to display class DisplayObject { void Draw(); //Draw the object //... }; //... typedef std::map < shaderClass *, std::vector < DisplayObject * > > shaderMap_T; shaderMap_T shaderMap; //... void Display () { //Say our shaders have been linked, added to shaderMap with objects, etc. //Loop through shader map for (shaderMap_T::iterator it = shaderMap.begin(); it != shaderMap.end(); ++it) { shaderClass * sc; std::vector < DisplayObject * > * dispList; sc = it->first; dispList = &(it->second); sc->Bind(); for (int i = 0; i < dispList->size(); ++i) { (*dispList)[ i ]->Draw(); } } }[/source] This is a simple way to do it, there are many more complex ways but usually something to this extent is sufficient. I would be interested to get other's opinions on how they do this.
  10. Voxel Theory & Practice

    So I think there may be some confusion over a voxel vs a 3D texture location. A voxel does not nessesarily have to do anything with texels. A voxel is simply a cubical "chunk" of 3D space, usually represented by 3D coordaintes (could be corner, center of voxel, etc) and an edge length. You DON'T need 3 numbers to represent width, height, and depth for CUBICAL voxels, you only need one, the edge length. Remember, all edges in a cube are the same length. You will most likely use 3 numbers for index location though (assuming your voxel is in a grid), or X, Y, Z location of corner or center of the voxel. 3D textures is a 3-dimensional array of color samples stored in memory (most likely on the GPU). If you wanted to make your voxel data correspond to a single 3D texture data, then you would scale you voxel so that your entire voxel data lies within [0, 1] and use the transformed coordinates of each voxel corner as texture coordinates. But this doesn't have to be the case, you could scale your voxel data to span 2, 3, 1000 3D textures. The choice is yours, just don't think voxels are always the same as 3D texels, because some people don't even use voxels with color data. [quote name='gboxentertainment' timestamp='1344700389' post='4968427'] I'm trying to implement the sparse voxel octree structure method described in the Crassin Gigavoxels thesis using the compute shader in dx11. [/quote] A new book came out recently entitled [i]OpenGL Insights[/i] in which Crassin has written a chapter on how to generate the voxels on the GPU, and how to generate an SVO on the GPU. The chapter is actually in PDF form on the website as one of their sample chapters [b]free[/b] to download! ( [url="http://openglinsights.com/"]http://openglinsights.com/[/url] ) look for chapter 22 PDF. It may help you in your implementation as I found it very clear and consise to read. [quote name='gboxentertainment' timestamp='1344700389' post='4968427'] The way I'm currently thinking of doing it is to take the minimum and maximum coordinates of a large bounding box, split it into eight boxes and storing the minimum and maximum coordinates of each of these eight boxes and recursively split and store in this manner. [/quote] You would not store the minimum and maximum coordinates in the nodes. The span of the node is inferred implicitly from the [i]level[/i] of the node and the [i]position[/i] [i]ndx[/i] of the node with relation to its parent node. I would refer you to read an excellent paper entitled [i]Efficient Sparse Voxel Octrees[/i] by Laine and Karras in which they describe exactly how the data structure is to be implemented as well as traversed. Their method is not for the GPU , but the same ideas translate to the GPU and is referenced by Crassin in his paper as being the basis for his data structure.
  11. Command processing

    Ugg, for some reason my code wasn't displayed properly. Poll input should look like this: void PollUserInput() { unsigned int lenKeyArray = sizeof(keyArray)/(2*sizeof(int)); for (int i = 0; i < lenKeyArray; ++i) { if (IsKeyPressed(keyArray[ i ][ 0 ])) { HandleEvent( keyArray[ i ][ 1 ] ); } } }
  12. Command processing

    So I was trying to find a good way to approach this issue recently as well. I'm on a C++ platform, and this is pseudo-code for how I handled it. [source lang="cpp"]//Runs the game loop void GameLoop() { while(!GameFinished()) { PollUserInput(); //Display and perform update code here. } } //A mapping of key to event. //This is an array here, but it can be implemented dynamically as well (to perform user-defined //key bindings use a map or something) //For debugging this is fine. int keyArray[][2] = { {'A', INPUT_EVENT_MOVE_LEFT}, {'D', INPUT_EVENT_MOVE_RIGHT} }; //Polls the keyboard input and creates a pre-defined event. All //other keys are ignored. void PollUserInput() { unsigned int lenKeyArray = sizeof(keyArray)/(2*sizeof(int)); for (unsigned int i = 0; i < lenKeyArray; ++i) { if (IsKeyPressed(keyArray[ i ] [i][ 0 ])) { HandleEvent( keyArray[i][ i ] [ 1 ] ); } } }[/i][/i] //Handle input event. void HandleEvent( int event) { switch(event) { case INPUT_EVENT_MOVE_RIGHT: //Move character right break; case INPUT_EVENT_MOVE_LEFT: //Move character left break; default: //Do nothing, unsupported event break; } } [i][i][/source] The implementation itself will be different on XNA, but the point is: 1. Only button-event pairs that are defined are checked. 2. The only crazy switch statement you need to have is in HandleEvent(). This means you don't mix input [i]logic[/i] from input [i]behavior[/i], and you can modify either without affecting the other. This was important for me at least. 3. Implicitly ignores unimplemented keys. 4. Easy to extend to dynamically bindable keys (from user-defined, or read from file, or whatever). As long as the INPUT_EVENT flag is handled by HandleEvent, it will be used. You could even extend HandleEvent to handle the flags in different ways depending on the state of the game. This is just an example, there are many ways of doing it, but I found that the simplest is to not overcomplicate it, especially for debugging.
  13. OpenGL Updating opengl version

    [quote name='uzipaz' timestamp='1344601433' post='4968060'] glGetString(GL_VERSION) still returns 2.1.8781. [/quote] What type of graphics card do you have? The version of OpenGL supported depends primarly on two things: your driver (which if you have the most up-to-date driver for your video card you don't really need to worry), and more importantly your hardware. OpenGL functionality is all implemented in the driver. When you make a call to query the version, the driver will return the maximum version IT supports, or the maximum version your graphics card hardware supports. Remember, OpenGL is a specification, the actual implementation (video-card HW and driver-specific) is a mixture of software and hardware implementations. If you have an older graphics card that doesn't support newer OpenGL functionality, then the driver will send back the version of OpenGL that your graphics card [i]does[/i] support. This has nothing to do with your header files or your .lib files that come with your system. Even if your hardware doesn't support an OpenGL core version, you may still be able to run newer OpenGL functionality as extensions (look for ARB, EXT prefixes). You can use GLEW to query for these extensions support.
  14. "Must-Learn" Languages

    I deal almost exlusively with C/C++ code, and I have done Java. I will say that learning C or C++ will expose you to core programming fundamentals (such as memory management, allocations on stack vs heap, object-oriented design, etc). I love Java for what it is, but I think if you are really looking to learning programming techniques which extend over all platforms, C or C++ would be a good choice for your projects. EVERYONE needs to know about pointers, and IMHO everyone needs to know about dynamic memory allocation and stack vs heap allocation. With C and C++, it is impossible to do any amount of coding for too long without running into memory leaks, stack/buffer overflows, segfaults, etc. These bugs are the bain of programming existance because they are [b]very difficult [/b]to debug. Sometimes days can be wasted before tracking down a hard-to-find memory leak. That being said, the experience of having and fixing these bugs is something you will need if you want to be a serious programmer. Learning at least one scripting language is good as well. Scripting languages are built to make programmers' and users' lives MUCH easier by allowing you to write scripts to perform menial tasks, or tasks in which programming Java or C++ would be overkill. Tasks that rely on using native system commands are good candidates. I would recommend Perl or Python since these two are highly documented. highly used languages. Also, knowing a scripting language is good if your looking for jobs in industry, or if your looking to make your life easier. From a learning perspective, these will show you how easy high-level interpreted languages can make your life. Learning C/C++ will make you [i]appreciate[/i] these languages even more.
  15. So i'm interested to know why you decide to compute the tangent and bitangent (binormal) vectors first and use those for normal? You have the vertices of the triangle, it's probably easier to compute the normal directly, then compute the tangent, then just take the cross product of the tangent and normal to get the bitangent. Be careful that you are getting the same normal (not a flipped normal) when doing these cross products. Also, could you post the shader code? Remember that once you have the tangent, bitangent, and normal these vectors represent a basis for a space. Your light vector is in object space, but you want the light vector to be in tangent space before performing light calculations, so you must transform the light vector first, then do the specular calculations. Check out this site: http://www.terathon.com/code/tangent.html for more info...