• 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

733 Good

About larsbutler

  • Rank
  1.   Others have mentioned it and I'm sure you've read it already, but this article is what helped me to fully understand this concept: http://gafferongames.com/game-physics/fix-your-timestep/.    To quote from the article, this sentence specifically describes conceptually what needs to happen: "The renderer produces time and the simulation consumes it in discrete dt sized chunks." What does this mean? It means that in your game loop, the first thing you do is check the time (t0), render a frame, and check the time again (t1). Assume for example that time elapsed between t0 and t1 (t1 - t0) is 34 milliseconds. Assume also that your "fixed timestep" for your physics/updates is 10 milliseconds (dt). The "render" stage produces 34ms, and the the "update" stage consumes the time in "discrete dt sized chunks"--that is, 10 ms chunks. That means that for this frame, you will run your update procedure 3 times, stepping forward by 10ms each time. Then you're going to have some time leftover: 4 ms. It is with this remaining value that you interpolate on your next render call.     Yes. When drawing, you interpolate position based on how far you are "between frames". In this case, you're about halfway between. I imagine this would not only to sprite position, but also to animation states, assuming those movements are also time-based.   To summarize, you basically end up with an update system which lags 1 frame behind the rendering. This may seem "wrong" somehow, but it works.   I can't help much with the networking portion of things (I've never programmed networked games), but I think using a queue somehow is the right approach.   If it helps, here's a real working example of such a loop that I wrote in Java: https://github.com/larsbutler/gamedemo/blob/master/src/com/larsbutler/gamedemo/core/Kernel.java#L68-L104   It's been a few years since I wrote that and some of the code is there is pretty odd, but that particular game loop is pretty solid, IMO.   Hope that helps.
  2.   I can really relate to this, actually.
  3.   This is good advice. When we first discussed using Unity, by my reaction he was pretty sure I was going to say no. We've talked about since then and have decided to give it a try, but in a few months after my game development course is over. [I don't really have the mental bandwidth to learn two game engines at once, go to school, and work 100%. =) ] But we are going to give Unity a try.   In the meantime, we're going to work on something together using Blender and jMonkeyEngine. He's already done not only modeling but entire level design (relatively simple stuff) purely in blender, so we'll see how it goes. I'm going to be alert to the pains of the modeling/level design/art pipeline which are likely to come up, and then I'll probably have more of an appreciation for Unity. =)
  4.   This was also my first thought. Glad to hear I'm not alone. =)
  5.   I think this is the single best piece of advice in this thread.
  6.   +1 for the mention of NIH. =)
  7.   In what way? Can you share an example?     Good point. Having never really completed a game, apart from some small tests and prototypes, I think whole development pipeline (code, level design, animation, modeling, etc.) is something I have greatly underestimated, or even just didn't think about very much.
  8. This is exactly the kind of advice and voice of experience I was hoping for. Thanks!   I also hadn't considered creating a single behavior and just dropping down into code and do everything that way. Interesting idea.
  9. Good point. I do like having not only control but also _understanding_ of what's going on. But you have to draw the line somewhere, else we would all still be writing in assembly. =)
  10. Hi there, it's been a while since I've posted.   I'm looking to start a new game project. I've been developing software for a long time, and I recently started learning some 3d game programming (through a university class) with jMonkeyEngine. It's going great! I'm getting more and more comfortable with 3d programming. I still have a ton to learn, but after spending just a few days playing around with jMonkeyEngine, I'm getting the feel for it.   The person I'm collaborating with is an artist (2d, 3d, textures, models, level design, etc.). We're trying to find the right tools for our first project, which will be a 3d game with some simple mechanics. He's played around with Unity in the past, and suggested that I check it out. I'm on the fence, to be honest. I'm a software developer at my day job. I like things to be lean, clean, and minimal. I code in vim mostly. I avoid IDEs like the plague, except in the case of Java, which makes my fingers hurt if I don't have some good code completion. ;) jMonkeyEngine appeals to me because I can just start writing code. Every time I've tried to dig into Unity in the past, I never could grok what is going on; it just seems like a lot of magic. It seems bloated and verbose, and the everything seems very tightly coupled together: level design, game objects, and game "scripts" all just thrown into one massive GUI. I found it noisy and unreadable. Despite all of the good things people say about Unity, I honestly just don't have a good first impression of it.   On the other hand, because everything is integrated, there's no need to figure out how to handle asset pipelines, level design/building, etc. (With JME, for example, I would have to figure all of that stuff out for myself, and maybe even build custom tools just to put everything together.) So already I can see some tradeoffs. In Unity, I/we could build our levels by basically just dragging things around in the graphical editor. With JME, I'd have to either a) find a secondary tool to help me model the levels, b) write my own editor (not ideal), or c) just do everything in code (also not ideal).   So finally to my questions: To those who have experience with Unity, is my initial impression at all accurate? To the veteran programmers out there, what's your opinion of Unity, especially in terms of its programming approach? If I go the "leaner" route (even with a "batteries include" engine like JME), am I going to have to end up writing all of the stuff that's "missing" (which Unity already has)?   I understand that the use of tools and the approach different people take is highly subjective. I'm really interested to hear peoples' experiences and opinions on this.   Sorry for the long-winded post. I appreciate any feedback! =)   Cheers, -Lars
  11. I'm assuming you mean `sys.path`, not `os.path`. If you want to be able to find and import Python code, there are better ways to do it.   First thing, though. If the problem is that you have multiple subfolders of code, and you cannot seem to import it, you're missing a crucial component in your "package" structure. Do you have an `__init__.py` file in all of your source code directories? If not, you should have them--they can just be empty files. (See https://docs.python.org/2/tutorial/modules.html#packages.) With these, your plain folders become Python "packages". (A "module" is just a file containing Python code which has a .py extension. A "package" is a folder which contains an __init__.py "module".)   An example: foo/ __init__.py some_module.py some_other_module.py bar/ __init__.py baz.py blarg/ __init__.py utils.py If you want to add the `foo` package to your path, so that you can import code from it, you can do this: import sys # you only need to add the root folder to your path # if your folders have an __init__.py in them, # python will traverse the folder structure and find all of the code sys.path.insert(0, '/path/to/foo/') # now you can make all sorts of imports statements: import foo import foo.some_module from foo import some_other_module import foo.bar from foo.bar import baz import foo.bar.blarg from foo.bar.blarg import utils # etc. Instead of just putting code somewhere and patching the `sys.path` at runtime, there is a better way. It is better to install your code in a well-known way to a well-known location. See https://docs.python.org/2/distutils/setupscript.html. Another thing you can do add the path to the code to your PYTHONPATH environment variable. For distributing code, creating a proper `setup.py` file is better.
  12. Another alternative would be to allow FTL (faster-than-light) travel in particularly open areas of space where there really is nothing, or at least nothing significant (so you don't have to suffer the boredom of waiting, like the boats in classic EverQuest). When you approach objects with a significant mass/gravity well (asteroids, planets, suns, etc.), FTL is travel not possible--and if you get close enough, you'll get pulled out of hyperspace.   This could really make boring space travel a lot more interesting. For example: Let's say you have a map with known and charted planets/objects. You want to cross a large stretch between two systems which appears on your map to just be empty space. You make the FTL jump, but halfway through you get pulled out of hyperspace by the gravity well of a massive planetoid/star/etc. which wasn't on the charts. So then you can explore it, etc....
  13. If you want to have the player object in the hashmap as well, and the hashmap is typed, the player needs to have the same interface as the other objects. That means, for example, that all of the objects could inherit from the same superclass, provided that there are enough similarities for this to make sense, of course. Otherwise, they could just explicitly implement the same interface. Then you should type the hashmap with the superclass or interface.   Make sense?
  14. Hi,   What are `interfaceWidth`  and `interfaceHeight`? Are they the width/height of each slot, or of the entire user interface? (If I'm reading right, they're being used as slot width/height. If that's correct, you should consider renaming these variables.) The logic in `watchForHotkeyAssignments` could be simplified a lot. For example, `key.get_pressed()[K_LCTRL]` and `slot[2] == (self.cursor.x,self.cursor.y)` only need to be checked once in side the loop. How could you simplify the logic? I think it's best to separate the _functionality_ as much as possible from the _presentation/UI_. For example, your data structure (the 2d list) `slots` contains information about the screen coordinates/pixels. Can you separate these somehow? Ideally, `slots` would just contain inventory data, and the Inventory class would have methods for performing certain actions (selectItem, moveItem, assignHotkey, etc.). Then you could have a method which will translate mouse cursor coordinates into slot coordinates. Hope that helps.
  15. Hey BurdenJohn,   If I may suggest, it might be helpful to rethink your approach a little bit. Here is an approach that worked well for me:   - do location updates and collision checks one axis at a time for each update (it doesn't really matter which one you do first)   - i.e., update the x location given current velocity, check for collisions, respond; repeat for y axis - instead thinking about how to keep the player rectangle from intersecting with objects (which seems to be the approach you're taking, if I understand it correctly), just let the objects intersect and then correct appropriately   - for example, if the player "runs into a wall", what happens is that the player intersects with the wall, and then is pushed out to react to collision; this is not the only way model your collision detection/response, but I find that it's easy to reason about   I have some sample code implemented in Java which does this kind of basic 2d rectangular collision detection/response. The movement simulation, collision checks, and collision responses are modeled here:   https://github.com/larsbutler/gamedemo/blob/opengl/src/com/larsbutler/gamedemo/core/GameState.java#L95   The collision calculations are implemented here:   https://github.com/larsbutler/gamedemo/blob/opengl/src/com/larsbutler/gamedemo/math/Collision.java   I also have implemented some basic collision test cases:   https://github.com/larsbutler/gamedemo/blob/opengl/tests/com/larsbutler/gamedemo/math/CollisionTest.java   These even account for cases where an object is moving so fast that it "passes through" another object.   Hope that helps!