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


  • Content count

  • Joined

  • Last visited

Community Reputation

369 Neutral

About stevenmarky

  • Rank
    Advanced Member
  1.   Yes, it will. A few I could think of:   Normal mapped lighting doesn't work well in VR, because with stereo vision you can see the surface is flat. Tricks like always drawing users weapons/hands over all geometry (e.g. Half Life 2) are horrible in VR. Maintaining a consistently high FPS (90+) is of very high priority. Anyway, In general I'm a big fan of VR. It really opens up a lot of possibilities. Feeling like you're there (to an extent) really changes the feeling of a game. Enemies I wouldn't have thought intimidating suddenly are, eye contact evokes a reaction, exploring is suddenly interesting and so on. I'm expecting to see some really interesting games/demos over the next two years (although I have no doubts it will remain niche in that time).
  2. This could be because the arrow is traveling so fast it's going entirely through the rock in a single frame. It depends how fast the arrow is traveling and the size of the colliders. I'd advise making the arrow slow to eliminate that possibility first.   Two other things I noticed: You have a 2D collider on the rock - does the arrow also have a 2d collider? I'm not sure if 2D/3D colliders are compatible. There's a warning on the game object you've selected (in the first screenshot) about the collider, that might also be the reason.
  3. This is interesting, I actually wrote an editor script a while ago which generates a C# file containing an enum list from a certain type of file resource, so if those resource files are ever removed we'd get compilation errors instead of waiting for a runtime error. What advantage would using T4 code generation have over manually writing a C# file?
  4. You're asking difficult questions...you might get more answers if you are able to break it up into separate problems and focus on one at a time.   I haven't fully analyzed what you are saying above, and I haven't fully analyzed your code but I have the feeling that you're making an incorrect assumption somewhere. I don't have a specific answer but I have some guesses and some more general advice.   This sounds strange to me...if you are using Daikon forge and if it is similar to NGUI then when you use a 'fixed size' it's actually just means that it's using a constant 'virtual' pixel height, but the width of the screen is free to change. If so and your problem boils down to converting screen pixels to those 'virtual' pixels all you need to is something like:      float pixelPositionToVirtualPosition(float f)     {         return f * (virtualScreenHeight/Screen.Height);     } This will convert a screen pixel position into a NGUI position, and you can also write a function to do the reverse.   When you say something like this:     or this:     It makes me think that you're developing using trial and error. If you've thought logically about how the object should be positioned (could help to test the equations on paper first), and it doesn't end up where you think it should then you need to find out why before trying another solution. Use Debug.Log or print statements, or the debugger. Use divide and conquer to find the point at which your code is breaking down, then fix it.
  5. With shaders you might be able to change the depth testing offset factor (see http://docs.unity3d.com/Documentation/Components/SL-CullAndDepth.html ) of the scenery to 0 - if I'm understanding the documentation properly this would make the scenery all screen facing in terms of depth, but I'm not sure if it would introduce any other problems.
  6. That's an interesting problem.   My first thought would be to not use full camera facing billboards, instead use normal quads that are orthogonal to the ground and put the texture on there. You'd still want them to billboard on the y axis however. The side effect of this would be that the sprites would look shortened vertically when viewing from above, so to compensate for that you'd have to stretch the quads vertically dependent on the camera angle. I can't think of any reasons immediately why this wouldn't work, and it seems preferable to messing with shaders.   I will elaborate if it's not clear what I'm saying.
  7. The problem is "post xor mask" on line 7.   It should be "xor post mask" because the function comes first (unless it's an infix operator).   You can still use it as infix with special syntax: "post `xor` mask"
  8. Good luck Mike.
  9. My main criticism is that stylistic elements (e.g. on the main page) take up a lot of space. In particular the headers of each content block is 74 pixels - which takes up a lot of space. I also feel there's something strange about having a border around the main content area which is white, which is then surrounded by more whiteness. On the main page I'd prefer the recent posts were closer to the top of the page. I'm not sure if you've analysed where most of the clicks lead to on your main page but I imagine a lot come from the recent posts. Anyway, good job. I'll also submit these points to feedback
  10. Welcome to gamedev.net!
  11. Maybe you'll find this pattern interesting Gravy, it is called component and it is frequently used: http://gameprogrammingpatterns.com/component.html
  12. There are design patterns, but I don't think there's any as high level as you are thinking. Quote:I'm making a RPG. Well heres a general and practical approach to doing that RPGs are so varied that there's only a small amount of things that we could describe in general. For example is there a general approach to doing movement in an RPG? Well movement could be tile-based, or pixel based, or our RPG could be 3d. or it could be isometric 2d, and it could require data sending to a server each time we move, and there might be entities we collide with, or there might not, and there could be traps, or triggers that happen when we walk in certain spots, or the movement should be able to be scripted from another language or...and so on. Each requirement a specific game has will result in a different approach.
  13. I'll have a stab at answering your other questions: Quote:Do you try to modularize is as much as you can so you can reuse as much code as possible? In general, splitting things up into well defined components is good design. However when you ask this question I get the idea you're splitting things up into tiny fragments in the hope they will be used again at some distant point in the future. Be pragmatic and consider the benefits and cost of making things reusable. For example - if you're writing a small game is it important to separate the game logic from any engine calls? Not really. Quote:where would you put the variable "Score" in your game? Without any more information, in the game class. Quote:how do you handle saving the game state? If you have a class that contains all variables that encompass the games state all you need to do is make a copy of it. Quote:Do you use a player object to keep track of what the player does? If it's a requirement to keep track of what players do, then this sounds like a good idea. Hard to answer without knowing exactly what you are asking. I might make copy of the player object, and associate it with a timestamp.
  14. Hi Gravy. Quote: I don’t know what else to call it, when you’re trying to figure out how to program your program, other than programming logistics. My question is how you guys figure out where to put you code. In the text editor or IDE! Quote: lol, man you guys completely misunderstood my question. It's because your question is not concise and it's easy to interpret it in different ways, and actually seems to be a few questions: How can I avoid rewriting my code? How can I write things in the least amount of lines possible? How do you generally go about engineering a good solution to a problem? How can I avoid rewriting my code? Short Answer: Planning, and foresight. Longer Answer: If all your requirements are known to you at the start of the project, rewriting should be minimal although some level of refactoring is natural. It's usually changing requirements and additional requirements that cause rewrites. While planning break it down into well-defined components that interact. Experience helps here- this is something you will get better at over time. How can I write things in the least amount of lines possible? I'd like to think that a system that has been properly split into well defined components naturally lends itself to being concise. Apart from that, just being smart. Note that writing things in the least amount of lines isn't always the best thing - it could reduce maintainability. How do you generally go about engineering a good solution to a problem? I think rip-off answered this well (rated). [Edited by - stevenmarky on December 21, 2010 7:32:02 AM]
  15. I suggest trying out Visual Studio Express. It's free and you'll be able to follow along with your book. I'm sure you could manually type your resource file in Code Blocks, or even find a plugin that provides you with a WYSIWYG dialog editor, but what's the point of going through that extra trouble?