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

roguan

Members
  • Content count

    30
  • Joined

  • Last visited

Community Reputation

108 Neutral

About roguan

  • Rank
    Member
  1. Hey Neglected, Thanks for your reply, the component method seems to be working very well for me! Good insight, mate.
  2. Fabulous! This is my current approach. It seems sustainable. Is it common? Much appreciated.
  3. I'm currently refactoring. I want my camera to follow a player, rather than being completely detached in third-person. [b]Goal: [/b]Allow a third-person camera while reserving the right to attach the camera to arbitrary objects. What are some alternatives when constructing the player, camera, and game objects to allow this? I currently have: Input -> InputManager -> Camera => Modified Camera Position/Orientation I've considered attaching the camera to an object (for instance, the player), and allowing the camera to modify the player position (since the camera receives the input). But this seems ludicrous! Should the InputManager be provided with which object it should affect? And, if the camera happens to be attached to the affected object, that object is responsible for updating the position/orientation of the camera? Input -> InputManager -> PlayerControlledObject -> Camera => Modified Camera Position/Orientation Could anyone point me to a good example of how to do this, which allows for a good amount of flexibility in the future? Thanks! Using : JOGL 2.0
  4. Hey! You could pre-calculate the LOS for each tile using the max LOS distance for any unit. This could increase the loading time of your level "dramatically" depending on the size, but may be worth it. Then, just lookup the list of tiles which can be seen for each unit according to the tile it's standing on. As long as you don't build LOS blocking walls during the game, you should be fine; although, even this can be handled efficiently given you have already computed the lookup table. Hope this helps.
  5. [quote name='Bobby Fisher' timestamp='1297249118' post='4771818'] Hi, I've been experimenting with C# and XNA, trying to see if I can make a 2D RTS. After designing a basic class, I've gotten stuck on a design issue. I want the basic [i]user controllable [/i]unit to consist of smaller elements (i.e. player controls platoon, which consists of soldiers). But how does one create a fluid, random motion of soldiers within the unit formation? All I can think of so far: When ordered to move, the relative position (at the destination) of each soldier in the unit is randomly changed by a small amount. The troops have a somewhat randomly varying speed as they move. (terrain speed-modifiers would also affect this) I would need to use a basic unit collision detection, not sure where to begin with that, Any ideas, comments, implementation tips would be greatly appreciated. This more of an excuse for me to expand on my programming experience, but getting something like this to work would be amazing for me! [/quote] Well, you need to decide a few things before proceeding. Do you want the units (of the platoons) to move individually? Or should they move as a block, like a legion of phalanx? In the first case, like Strarcraft did, you could, for the group you have selected, set the same target point for each unit in the group. So each unit would try it's best to get to that point. This caused units to keep moving even after the majority of the group stopped in Starcraft. As far as determining how each unit attempts to come to that location, you need to look up path-finding and find suitable algorithm for your terrain/map representation. In the second case, you can handle the entire group as a single movable unit, but have individual animations for each unit. Each unit's animations could be oriented toward the target point, while the group gradually moved as a coherent block toward that point. This would, for example, result in all of the individual units facing inward if the block of units was centered directly over the target point. As for collision detection, simple 2d detection schemes are bounding box, and bounding circles. Information easily found by googling "2d collision detection". Hope that helps.
  6. Hey, The only thing I could think of was you are somehow messing with your position pointer in your paragraph.. Try this: [code] TextPointer ptStart = prg.ContentStart.GetPositionAtOffset(match.Index, LogicalDirection.Forward); TextPointer ptEnd = prg.ContentStart.GetPositionAtOffset(match.Index + match.Length, LogicalDirection.Backward); [/code] Hope that helps.
  7. [quote name='boehmi' timestamp='1295530607' post='4761823'] Okay.. that worked [/quote] Great! Good to hear! Good luck!
  8. [quote name='Spa8nky' timestamp='1295526198' post='4761800'] In the node class I have the maximum amount of neighbours allocated to a node array: [code] private GraphNode[] neighbours = new GraphNode[26]; public GraphNode[] Neighbours { get { return neighbours; } } [/code] Now if I create two nodes and the second node to the neighbours of the first node: [code] GraphNode node = new GraphNode(this, Vector3.Zero); GraphNode node2 = new GraphNode(this, Vector3.One); node.Neighbours[0] = node2; [/code] then it doesn't appear to reference that node as: [code] node2 = null; [/code] doesn't make the node.Neighbours[0] = null. [/quote] I think I understand. And, no it shouldn't. node.Neighbours[0] is a reference and node2 is a reference, but they both point to the same thing which is a GraphNode containing Vector3.One. Now, node.Neighbours[0] = null just kills the reference, not the actual object. BUT, if you change the information inside the object: [code]node2.vector.x ++;[/code] And then [code]print node.Neighbours[0].vector.x;[/code] Then you will see the change. You may should read this: http://www.albahari.com/valuevsreftypes.aspx
  9. [quote name='Spa8nky' timestamp='1295523282' post='4761787'] I'm programming in C# and I'm pretty certain that it will throw a hissy fit if I try using pointers. Instead If I am storing an array of 26 structs for each graph node on the map then wouldn't that be a waste of memory. How else can I approach it? [/quote] No C# expert here, but I just read really quickly regarding reference and value types in C# and it seems to me you would be much better off by using classes, since they are reference types. So your nodes/tiles would be a class. And, you would basically have some number of references to the surrounding neighbours. In this case, you would use much less memory than using structs if I understand things correctly.. Hope that helps.
  10. [quote name='boehmi' timestamp='1295517631' post='4761754'] ok here are the 2 images with 40 rectsPerSide i also added another image with another height map... there you can see that it works a little bit but the rectangles still have a wrong orientation i think there is a problem with texture mapping to vertices, that are used by more multiple rectangles and thus are contained more than once in the vertice array/buffer..? [/quote] The vertices still look a bit odd, but I've been over the calculations a few times and it looks right. Anyway, your triangles' orientation may have a bit to do with it. You are drawing one triangle CCW and the other CW You can try switching p5 and p6 in both your vertex generation and your texture coord generation and see if it helps. [code]// p5.x triangleNew.vertices[base+12] = j*(rectWidth)-width/2; // p5.y triangleNew.vertices[base+13] = 0; // p5.z triangleNew.vertices[base+14] =-i*(rectWidth)-rectWidth+width/2; // p6.x triangleNew.vertices[base+15] = j*(rectWidth)+rectWidth-width/2; // p6.y triangleNew.vertices[base+16] = 0; // p6.z triangleNew.vertices[base+17] = -i*(rectWidth)-rectWidth+width/2;[/code] to [code]// p5.x triangleNew.vertices[base+12] = j*(rectWidth)+rectWidth-width/2; // p5.y triangleNew.vertices[base+13] = 0; // p5.z triangleNew.vertices[base+14] =-i*(rectWidth)-rectWidth+width/2; // p6.x triangleNew.vertices[base+15] = j*(rectWidth)-width/2; // p6.y triangleNew.vertices[base+16] = 0; // p6.z triangleNew.vertices[base+17] = -i*(rectWidth)-rectWidth+width/2;[/code]
  11. [quote name='Spa8nky' timestamp='1295474717' post='4761489'] The problem is that the neighbours aren't going to as simple as [i+1][j][k] etc. because the nodes are created for traversable tiles only and non traversable tiles are ignored and not added to the final array. This means that indices are not arranged in a true 3D array format. Unless I've misunderstood you. I could create an array that covers every single part of the entire world and leave the non traversable tiles as null, but this would be a huge waste of memory. [/quote] I think I understand what you mean, and I suggest you store the neighbour information in the nodes themselves. When creating your nodeStructure: [code] for ( node : allNodes){ for ( possibleNeighbour : allTilesSurroundingNode){ if ( !possibleNeighbour.isImpassable() ){ node.addNeighbour(possibleNeighbour); } } } [/code] Then you'll end up with a nice structure in each node containing which nodes are passable around that node. This is good if your tiles almost never change from passable to impassable or visa-versa.
  12. [quote name='Spa8nky' timestamp='1295470116' post='4761445'] I've had another thought that concerns me. A lot of 3D/2D A* alogrithms use nodes arranged in a square/cube so they can be packed neatly into an array and neighbouring nodes can be found easily by incrementing/decrementing indices. If I'm using a non square/cube arrangement that doesn't play nice with an array how the heck can I check the neighbouring nodes as quickly? Using find nearest neighbour each frame for each enemy would be silly in comparison to checking neighbouring nodes by incrementing/decrementing indices, so how can it be done with this arrangement? EDIT: I type this at the same time as the message above was posted, but my question still stands. [/quote] You could store pointers to each node's neighbours within each node. These could be initialized during the initialization of the node array. e.g. [code] node[i][j][k].neighbours.add(node[i+1][j][k]); node[i][j][k].neighbours.add(node[i][j+1][k]); node[i][j][k].neighbours.add(node[i][j][k+1]);[/code] etc.. Then you can easily iterate through neighbours without relying on the indices to perform the transition. But in larger searches you may have to use a "visited matrix", and this becomes expensive. Alternatively, you could also step through the neighbours in each direction for a number of steps, then switch directions. Hope that helps.
  13. Well, if the nearest object you are searching for is stored in the node array, then you can perform an outward search, especially when you have dense conditions. It won't be any worse than checking every node. Illustrated: p = player x = empty node n = nearest neighbour - = searched nodes [font="Courier New"] Check if player is on same tile as a neighbour [/font][font="Courier New"]xxxxxxx xnxxxxx [/font][font="Courier New"]xxxxxxx[/font] [font="Courier New"] xxxpxxx xxxxxxx xxxxxxx[/font] [font="Courier New"]xxxxxxx[/font] [font="Courier New"] Check surrounding 1 level out [/font][font="Courier New"]xxxxxxx[/font] [font="Courier New"]xnxxxxx xx---xx xx-p-xx xx---xx xxxxxxx [/font][font="Courier New"]xxxxxxx[/font] [font="Courier New"]Found on level 2 xxxxxxx[/font] [font="Courier New"]xn----x x-----x x--p--x x-----x x-----x [/font][font="Courier New"]xxxxxxx[/font] You can do this with a Queue and recursion or with a few loops. Also, complex but efficient [url="http://en.wikipedia.org/wiki/Kd-tree"]http://en.wikipedia.org/wiki/Kd-tree[/url] [quote name='Spa8nky' timestamp='1295454453' post='4761298'] [quote name='lambrtz' timestamp='1295420469' post='4761114'] Have you considered using [url="http://en.wikipedia.org/wiki/Nearest_neighbor_search"]nearest neighbour search[/url]? I don't know about its computational cost though. [/quote] Nearest neighbour search appears to follow the idea of placing all the nodes in a BVH and then testing the distance from a point inserted, if I'm not mistaken. That's what I'm currently doing so I guess I'm on the right track. [quote] By the way, how is array [i]n[/i] different from array [i]nodes [/i]in your code? [/quote] n returns an array that contains no null nodes, in other words it is an array this is the length of the number of nodes created. I could return 'nodes' and iterate through until I reach null but I don't see what advantage that would have over an exact array size. This method is not run once per update. [/quote]
  14. Can you try isolating the problem by removing the texture values from the height calculation. Try making the y-coordinate the value of x+z instead. If that works as expected, then the texture coordinate calculations could be off. [quote]gl_Position = uPMatrix * uMVMatrix * (vec4(aVertexPosition,1.0) + vec4(0.0, tex[1]*2.0, 0.0 ,0.0)); [/quote] Could you also post a screenshot of numOfTiles > 2 for y = 0. Thanks
  15. Hey! I do appreciate the advice! I'll definitely do something along those lines. Thanks! [quote name='sgt_barnes' timestamp='1295448238' post='4761257'] Here is what I use to test my quaternions: * First, rotate an arbitrary vector around an arbitrary axis using an arbitrary angle (of course with a quaternion). * Then compare the original to the result vector, considering length and angle. If the length is constant and the angle is as desired, everything is fine and you are "green". * Now generate a series of rotation quaternions and concatenate them. Transform an arbitrary vector with it. * Now use each individual transformation of that series to transform the vector again, but this time checking angle and length like in the single transformation case. Only proceed while you stay "green". * Finally, compare both results. If they match, you are "green". That way, an error might still go unnoticed, but if you generate enough different test cases, the probability for that should be very small. [/quote]