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

Steadtler

Members
  • Content count

    1819
  • Joined

  • Last visited

Community Reputation

220 Neutral

About Steadtler

  • Rank
    Contributor
  1. Then you're down to good old debugging Make a simple map with only a flat square surface. Then step in the method and see while it fails.
  2. Do you have debug display to show the resulting mesh ? Tools are important.
  3. CoH's solution seems nice. If you dont need the information to be so dense, you can use a quadtree instead of a dense grid. That would reduce the memory, and the cost of pathfinding, line-of-sight checks, etc. Im not sure why your string pulling is so expensive, it should be very cheap to do on a grid, as all you need to do is intersecting a vector with axis-aligned lines. If you are sure your maths are optimal, then there is also the fact that you dont need to smooth the whole path at once. You really only need to smooth up to the next "corner", its useless to smooth a whole path that is likely to change.
  4. You seem to be in 2d. If you just build a simplified representation of your space (navmesh, or since you seem to be grid-based a quadtree) should make your line of sight checks negligible. There is no reason you shouldnt be able to do hundreds of those every frame. Also, looking at your original code up there, it seems you're working in polar coordinates (angle/distance). Believe my experience when I say its evil. Work with vector algrebra.
  5. Always shrink your navmesh for agent size. We have tested this problem at work and we found that generating several navmeshes - as JT suggest - is far more efficient (less memory AND less cpu cost) than generating one navmesh that supports several agent radii.
  6. Of course you realize that a voxel generation is the 3d generalization of the binary image representation in your article The steps are actually quite similar. From talks to other people in the industry, almost everyone has made the shift to voxel-based generation in the last few years, and Mikko sure has a big responsability in that. I can confirm you that it works with massive levels with high-precision, as long as you're being smart about it.
  7. Honestly CIV 5 is more of the same: Its a superp 4x game with an AI that can't play it at all. From CIV 4 the game got better and the AI got worse. So even if you play the game really well there is no challenge because the AI will try to attack your tanks with spearmen even though they could build tanks of their own. I beat the game on every difficulty level and I never had a fair fight past the middle ages. Its like the AI doesnt know it can upgrade its units. Its a shame because I love the design. I must admit I was surprised at how slow the gfx engine is. I play on my work computer, which is a *beast*, and I had to lower the gfx settings. I think the great variety of textures must be whats killing it.
  8. Its not what you want but you need to try farming in Dwarf Fortress hehehe
  9. Quote:Original post by Waaayoff And once i do get the input, it's just a matter of solving some equations right? Its not about solving the equations. Its about finding the right equations to solve...
  10. Quote:Original post by Antar3s Ok, thanks a lot. I'm trying with A* and it seems a very good solution for my case. Actually, I have to debug some code, but it should work well. Now I'm thinking about the test to decide when a bot sees the player. I prepared a boolean function, but I don't know how to define it. What should I test? I could take the distance between player and bot positions, but there could be a wall on the way, even when they are close enough to fight each other. Is there a common way to solve this problem? Thanks again. Yes, the common way is a line-of-sight test, which is usually done by doing a "raycast" in your physic engine. Basically you cast a line from the AI's eyes position to one or several of the player's bodyparts, and check if it intersects anything. Its a costly test cpu-wise, so you dont want to do it every-frame for all of your bots. An cheap, alternate solution in the case of a 2d game is to check if you can trace a straight line from the bot to the player on the navmesh...
  11. I lived close enough to Seattle for a while (Vancouver) and I had a good impression of it. The city has a nice vibe to it (downtown anyway) and I love the west-coast fresh air. Plus its Shadowrun's main setting! I didnt like the techno-suburb (Redmond & co) tho... looks so artificial. And traffic did look like a pain. While I think of it, if you like the north-west, you might want to consider Vancouver.
  12. See kids, this is where GA/DP/ANN leads: semantics arguments over ill-defined methods that gives poor results and takes so much time and hacks and tweaks just to make it work that you could have coded a straightforward solution a hundred times over instead.
  13. crossover just mean you look for values in the neigborhood of two samples - and gradient descent/hill climbing was never limited to only running one at a time. Im not saying hill climbing is good, Im just saying GAs are not any better. It runs pretty much the same and attempt to patch the same flaws with doubtful hacks. noppanit, sorry about the crossfire here. Im suggesting you study the basis - including operational research and numerical algorithms - until you see why its a bad idea. Besides the argument above about whether its anything better than a hill climbing, there are other reasons not to use it in game AI - notably the difficulty (some would say impossibility) of debugging and tuning the behavior of the AI when its all based on a regression.
  14. Quote:Original post by alvaro Quote:Original post by Steadtler Quote:Original post by Alvaro where computing the partial derivatives of the fitness function is impossible and where the only thing you can even try to measure is the relative fitness of a setting of the parameters with respect to another setting of the parameters Doesnt that sound like a finite difference? :) Actually, no. Imagine you are trying to optimize the strength of a poker bot. The only measure of strength you have is matching one bot against another for a number of hands and seeing who makes money off of whom. I don't see what a finite difference have to do with anything. Because of the mutation step in GAs, the other bot will most likely be a neighbor in the search space. I say most likely because GA are very loosely defined and thus can end up being just about anything. In its most basic form, a GA takes a point, find points in the neighborhood ("mutation"), then compare those points and keep the best(s) according to some test ("fitness"/"selection"). Like I said, a sugar-coated gradient descent. The more they deviate from this formula and the more they look (and perform!) like a random search.
  15. Quote:Original post by InnocuousFox Notice he said "genetic programming" rather than "genetic algorithm". One modifies data, the other modifies the code itself. Yes, because doing a gradient descent over the space of all possible code makes much more sense that over the data space :) But yeah, I shouldnt have written GA, but my comment stands. Quote:Original post by Alvaro where computing the partial derivatives of the fitness function is impossible and where the only thing you can even try to measure is the relative fitness of a setting of the parameters with respect to another setting of the parameters Doesnt that sound like a finite difference? :)