pyRPG

lp:pyqtrpg

Created by Alistair Broomhead and last modified
Get this branch:
bzr branch lp:pyqtrpg
Only Alistair Broomhead can upload to this branch. If you are Alistair Broomhead please log in for upload directions.

Branch merges

Related bugs

Related blueprints

Moving around (Essential)
Attacking things (Essential)
Opening doors (Essential)
Dying (Essential)

Branch information

Owner:
Alistair Broomhead
Project:
pyRPG
Status:
Experimental

Recent revisions

8. By Alistair Broomhead

This took a lot more work than I expected... To make head or tale of the whole thing I ended up creating a debug mode where every tile in the game is labled, and there's a whole load of extra debugging information spat out into the text pane...

I've created a new class for a trail of footsteps showing the path a characer is planning on treading. This will look cool when it's finished as well as helping with debug window. It's getting fairly messy to debug some of this stuff, so this could be a bit help. I've created a sprite to use for this but I haven't started rendering it onscreen yet. A list of tile positions is currently spat into the text pane when in debug mode.

I noticed part of the error was to do with translating the position the player is transferred to after passing through a door, and have made sure this is no longer needed, as well as deferring the recalculation of the character's bath until after they have entered the room and the door has closed behind them.

I moved the calculation of the points in a path spanning rooms into the span-finding algorithm, as I suspected this of causing a problem, however it may turn out that this was unnecessary and it would remove some of the algorithmic overhead to remove this once again if I can prove this is fine.

I had introduced a bug somehow which was causing a segfault on maemo 5 devices, which was to do with placing the main graphic view inside a placeholder widget, so I have removed the placeholder widget and placed this view directly into the layout - this is a cleaner implementation, but viewing the .ui file does not show what the game ui will look like any more. Still better than when there was no .ui file, and the inner workings of the main graphics view are too complex for my current grasp of the WYSIWYG editor anyway. I'm not even sure if it's possible to implement what I have in python via the Qt Designer.

I changed the self object in _Display/_DisplayObject.py to fit in with the usual convention - the confusion is not worth the hassel just to make it easier to work with on my phone's display.

In addition to this the DisplayObject is no longer a subclass of QMainWindow, but a normal object which delegates some functions to a standard QMainWindow.

7. By Alistair Broomhead

Forgot to commit these - the interface buttons

6. By Alistair Broomhead

Fixed level-stitching - this is now done recursively by the Door class, hopefully guarenteeing that as long as the doors have been correctly placed the world will be stitched together correctly.

Also moved all image resources into qrc files with the associated .py files generated. This should make it easier when I come to compile binaries.

5. By Alistair Broomhead

Fitted interface into QtDesigner generated form - This should make things more flexible going forward.

4. By Alistair Broomhead

Full pathfinding has been implementyed but level-stitching needs some work - levels will not necessarily be placed in the correct positions unless they are initialised in the correct order.

3. By Alistair Broomhead

[GameObjects/_Box.py]
Created box class - shall also be used for character inventories.

[GameObjects/_Character.py]
Added actions to be performed upon collision with objects. Currently implemented are 'pass through' (for passing through a door/portal) and 'pick up' (for adding items to inventory)
Inventory has been added, but no gui for dealing with it and no rules on what can be held in there...

Also added a pathfinding function. This creates an optimal path at the time when it is calculated, however does not involve recalculation later unless a collision is made with an obstacle that has been moved into the pre-calcualted path. I created a quadTree class, similar to a binary tree but with 4 branched to each of a BTree's two. This class would walk each of the possible squares in the level and return the shortest path in an itterative manner. To avoid sorting the possible solutions I sort the list of neighbour points at each step so that the leftmost in each branch of the tree is the closest to the target. This was still giving O(4^x) performance where x is the lenght of the optimal path; by marking any point already searched by the algorithm as such, and then killing those nodes such that they will be explored no further, I was able to reduce the complexity to O(x^2). I then also killed nodes which were at the same location in the level as a collision tested object for which the collision action is to stop, to add collision avoidance to the pathfinding algorithm.

Changed tick function to use a hash table instead of a switch, for the associated performance improvement.

In addition to this I added a hash table to keep track of event reversals such as closing a door after the player has walked through it.

_getObstacles was changed to to fetch from a periodically generated (on redraw) hash table rather than searching for obstacles on demand - this will drastically reduce the overhead of all functions calling it, while adding a small overhead to the drawing function. This may need changing to once per tick per character, but I'll see how necessary this is later, as it will sacrifice performance for accuracy - the mobile device I intend to run this on has fairly limited resources

TODO: Inventory gui, rules and icon.
TODO: Handling of different levels - currently only tiles within the current level are considered- this keeps the list of collidables small, howevercan result in odd behaviour if the optimal path when recalculated at level exit is to double back on oneself and walk through the obstacles that are no longer collision tested. An approach that may be fruitful for this is to create a bounding rectangle of the start and end points and add all the lists of collidables for the levels theat intersect/are contained within said rect. An alternative approach would be to use the doors between levels as nodes, calculating the optimal path between doorways as the edge cost and use an A* search or similar to find the optimal set of doorways to pass through. The pros and cons shall have to be considered carefully, as the 1st method shall only use the bounded levels, which may not be an optimal or even possible path - however if the world is large compared to the bounding rect then it shall be a lot cheaper computationally. If however I build my search tree itteratively stopping when the cost to not reach the target location exceeds the most optimal search path has been found, I may be able to trim some of the branches that are not relevent, in a method similar to that used to reduce my level-based search from O(4^x) to O(x^2).

[GameObjects/_Door.py]
Added door class. The idea is that two of these objects are created and then linked. A function then handles passing the character from one door's level to the other.

[GameObjects/_GameObject.py]
sortcontents function added which constructs a hash table of every item in the level (but no sub-items) for reasons of collision detection and maybe later AI targetting.

Added 3 properties to all GameObjects:
  Collidable - Will the object be collision tested?
  moveto - What a character should do if it collides with the object in move mode.
  attackto - What a character should do if it collides with the object in attack mode.

[GameObjects/_Level.py]
Added reoffset function - used to allign a levels contents within its new position.

[GameObjects/_fifo.py, GameObjects/commandList.py]
Some hacky workarounds to the fact that properties don't work how I thought they did - I shall have to create a new class to clear all of this up, but it's probably best left until I'm refactoring the rest of this huge mess...

[Levels/Level00.py]
Created unique copies of the base items rather than just using the base items as before. This means I can give them unique names, statistics etc.

[Levels/Level01.py]
Added a second level to test doors - basically a carbon copy of the first, but with an extra door on the left to join the one on the right of the first. Also this level contains no items. The whole design of this level will be changed when I've tested some more of the games features, but for now it is good enough to test what I have.

[Levels/objects.py]
Created a clone class for copying base items to form new unique items. Also changed flags to be just a fancy integer as the binary system was more trouble than it was worth.

[_Display/_DisplayObject.py]
Changed tick rate to 20Hz to allow for more complex animations in the future.

[_Display/_DisplayWindow.py]
Fixed page scrolling on drag.
Created a tile cache so that icons don't have to be loaded from files every time we want to blit them to the screen.
Started showing all levels, not just the current one.

[_Display/_Interface.py]
Added inventory function - currently it just lists your inventory in debugout, but eventually there will be a gui with options for dropping icons and equipping them, and a second gui for transferring items between boxes/characters/players.
Added inventory button to gui, no icon yet.
Added shortcuts for buttions.

[_Display/_clickableIcon.py]
Now refreshes what is the QPainter object every time it draws - previously it would keep using an expired QPainter which would result in nothing being drawn to the screen.

[pyrpg.py]
GameObjects are now initialised from a hash table rather than using a switch statement - this is becaus the has table is well-optimised at a low level, and it would be very impossible to gain the same performance in pure python.
In addition to this I have created a dictionary of doors, in order to link all doors in the game. Doors are linked if they have the same name, and so I have created a naming convention to avoid mixing them up.

2. By Alistair Broomhead

'Engine' Complete

1. By biggal <email address hidden>

Start of version control

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.