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

joekarl

Members
  • Content count

    9
  • Joined

  • Last visited

Community Reputation

108 Neutral

About joekarl

  • Rank
    Newbie
  1. @MarekKnows yeah this is what I ended up doing. Works well enough for the enemy movement and makes the code super clean. Using ascii for the tilemap so a little different but same concept.
  2.   So I go through, calculate all of the potential collisions, find the first one, resolve it. Because it can create new collisions after the resolution I should re-calculate all collisions from that point forward, go resolve the first one, and then repeat this process for the rest of the step ya?
  3. Just wanting to get some clarification on some collision detection thoughts. This is all 2D to keep things simple and no rotations.   In a dynamic impulse based resolution system (ie multiple bodies moving around, when they collide we apply forces to them for the next frame) it seems that there's only a couple of ways that I can go about detecting where/when collisions are going to happen. Say I have a list of bodies, I can either attempt to move them one at a time to their next collision point (ie sequential movement) or I can attempt to find the soonest collision point of all of the bodies, move all of the bodies to that point, and then repeat until the timestep is finished (ie simulataneous movement).    In the first case, ordering of the objects matters as collisions may or may not occur based on which bodies is moved first. In the second case, this involves multiple iterations over the bodies to do all of the movement and seems more complex but seems much more accurate.    I've seen it mentioned (or at least it seems) that many games use the first case as it's easier to implement, faster, and the ordering effects aren't noticeable. While this seems like it would be just fine I just can't get over the fact that it's not deterministic if the order of objects changes :/   It could also be that I'm completely misunderstanding this...   Thoughts or resources related to this subject would be greatly appreciated.
  4. I guess the 0 wall thickness thing is more for the tilemap approach as there's no physics object per wall, the wall is more of just for display instead of actually impeding the players motion which is governed by the tilemap. I guess I was being a bit hasty in thinking the wall collision version had to have a 0 thickness wall.    Got some prototype stuff up and running with the tilemap setup. Basic idea is the enemies pick a tile adjacent to their current tile that they want to go to (so long as it won't go through a wall) and then travel to that tile. Once there they decide to go to another tile. Rinse, repeat.   https://youtu.be/-Lh3mQhsS08
  5. The idea here is we have a tight maze (ie, a maze with 0 thickness walls and movement only along the x,y axis). This differs from say Pacman where the walls are a full tile thick. A specific example of this is Wizard of Wor.   So I think there's a couple ways to go about this:   I could create a list of walls for the level and then do collision detection against the walls. This seems to work fairly well collision wise as movement is just a general thing with sliding against the walls. Problem is collision detection is pretty complicated due to the walls not actually having any size physics wise.   The other option is to create a tilemap with each tile knowing which side(s) it has walls on. Movement is more complicated because you're moving from point to point in the grid. This is nice because AI can make decisions about where it wants to go strictly when it hits grid points.      At a glance how do you think this sort of thing was implemented in the past? (I'm guessing it was probably the the tilemap way as it's be less CPU to do this).          
  6. Okay, so I'm doing some clipping to cut down on the surface area that I'm actually drawing. Right now thats being done before I'm rasterizing the polygon which is resulting in non-triangle polygons when I get to rasterization. So how should I go about avoiding those 4+ vertice polygons?
  7. I'm working on a software rasterizer just for grins and I'm to the point where I want to implement smoothing between different colors at vertices across a polygon. From what I've read, it consists of calculating a scan line, calculating the colors at the ends of the scan line, and then linearly interpolating across that scan line to get the color at a single point. My question is how to calculate the color at the end of the scan line for polygons with 4+ points. 3 points is pretty straight forward (though I haven't actually done the calculations yet), but 4 is a bit harder to wrap my head around. Anyone have any good resources (or code) to get me started?
  8. I suppose I should be looking into loose octrees as opposed to straight octrees. So how do you order the polygons that reside in a parent node when you go to render the polygons? It seems there's still going to be ordering issues with the polygons in the parent and its child nodes. Is that where you punt and create a z-buffer for just that node in the octree and use that to order the pixels in those nodes? Seems like that wouldn't work well for really large polygons like a floor, but that could be a know limitation and the floor could be constructed of lots of smaller polygons.
  9. I'm building a 3d software renderer for grins to learn the math and rendering concepts. I've implemented the basic drawing of polygons with some basic optimizations like back face culling and frustrum culling. Its going pretty well for it being java and all (15k polygons at 30fps at 1900x1080) but I want to implement an Octree to reduce the amount of overdraw happening and correctly sort the polygons for drawing without using a z-buffer for the entire screen. I get the basic ideas of how to partition the world and how to traverse the tree from front to back to order the polygons correctly, but I'm a bit confused on how to handle polygons that are in more than one node of the Octree. Some example cases I'm concerned about are:[list] [*]A floor of 2 big polygons that intersect all of the nodes at the bottom of the Octree [*]A polygon that extends across a node boundary [/list] I figure I should split the polygon at the node boundaries, but then do I need to check on each frame for objects that have moved in the world that need recalculation in the Octree.