Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

733 Good

About larsbutler

  • Rank
  1. larsbutler

    Fixed time step clarifications

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

    Unity vs. a more "lean" game engine

      I can really relate to this, actually.
  3. larsbutler

    Unity vs. a more "lean" game engine

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

    Unity vs. a more "lean" game engine

      This was also my first thought. Glad to hear I'm not alone. =)
  5. larsbutler

    Unity vs. a more "lean" game engine

      I think this is the single best piece of advice in this thread.
  6. larsbutler

    Unity vs. a more "lean" game engine

      +1 for the mention of NIH. =)
  7. larsbutler

    Unity vs. a more "lean" game engine

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

    Unity vs. a more "lean" game engine

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

    Unity vs. a more "lean" game engine

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

    Accessing other directories

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

    Noob question on hashmaps

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

    Topdown wall collision, not working

    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!
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!