Jump to content

  • Log In with Google      Sign In   
  • Create Account

Calling all IT Pros from Canada and Australia.. we need your help! Support our site by taking a quick sponsored surveyand win a chance at a $50 Amazon gift card. Click here to get started!


Member Since 23 Dec 2011
Offline Last Active Oct 22 2014 03:19 AM

Posts I've Made

In Topic: Accessing other directories

02 September 2014 - 07:31 AM

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:


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.

In Topic: Map in spacegame? How to avoid all-open travel and "boring" worlds?

26 June 2014 - 04:36 AM

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

In Topic: Noob question on hashmaps

22 June 2014 - 02:12 AM

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?

In Topic: Selecting a new slot for an item in an inventory.

28 May 2014 - 03:21 PM



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

In Topic: Topdown wall collision, not working

27 May 2014 - 09:27 AM

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:




The collision calculations are implemented here:




I also have implemented some basic collision test cases:




These even account for cases where an object is moving so fast that it "passes through" another object.


Hope that helps!