Please give me Feedback :)

Trobadour on 2008/04/08 08:35 of CQ Robot

Greetings,
Please use this entry as an opportunity to give me some feedback on my game. Do you like it or not and why is it so. Maybe you see some stuff that could be better.

For example, i thought, that the concept of the two queues is a little bit irritating and instead i could only use one queue, where the collected balls stay on the right side until you collect a finish ball and then they are appended to the end of the robots execution queue.

Or more special balls, that enlarge or shrink the collecting pad, or do some other stuff.

thx!

(log in to comment)

Comments

claxo on 2008/04/08 11:07:

Sorry, but the current game allows to use a second queue?
The readme and the 'levels hints' dont mention it.
The game UI doenst hint (to me) that that is possible.
???

Trobadour on 2008/04/08 11:27:

>> Sorry, but the current game allows to use a second queue?

There are two horizontal queues which you can manipulate the following way:

The smaller queue lies directly above the ball collecting screen (let me call it the preparation queue) and the larger queue lies above the maze (let's call it execution queue).

With the preparation queue you prepare a sequence of 6 direction commands maximum. You can send this sequence to the robot by collecting a finish ball. The robot will than execute the prepared sequence and the direction balls appear in the execution queue.

Every direction ball you collect goes into the preparation queue. If two adjacent balls in the preparation queue have an opposite direction, like left-right and up-down, they both are removed from the preparation queue.

You can also let the robot undo his last movement by collecting the grey eraser ball (has some sort of undo symbol).

I hope this helps!

claxo on 2008/04/08 12:45:

Humm.
I dont see the operative meaning of the long queue, in terms of gameplay.
quote:
With the preparation queue you prepare a sequence of 6 direction commands maximum. You can send this sequence to the robot by collecting a finish ball. The robot will than execute the prepared sequence and the direction balls appear in the execution queue.
quote ends
That was the gameplay to me. Robot operation depends only on the preparation (short) queue, and the board status
Tell me, if the same (short) queue is executed with diferent (long) queue, I would see a diferent behavoir in the robot?
In my view the (long) queue its only a history of executed commands.
If you hide the long queue from the player view, is there a change in gameplay ?

I must say that a second preparation queue, and a key to switch between them, would be welcome. That for levels requesting combos to fulfill goals. Else you bore 'watching for', or angst 'cant avoid to break the combo'.

Trobadour on 2008/04/08 13:13:

You are right, the long queue is a history of the executed commands. But because the player can undo steps with the eraser ball, the player can use the history to see, what is the step he can undo (the eraser ball is introduced in level 3).

But you're also right about the complexity of the game. I'm unsure if the player is enough occupied with the collecting and avoiding balls mechanism.

I tried to compensate that with a tighter point- and timelimit and also a higher falling speed of the balls in the later levels. Maybe some additional special robot abilities like would enlighten the gameplay.

claxo on 2008/04/08 13:56:

Ahhh, yes!!! (long) tied to eraser strategy.
It looks hard to use: you look at the board, then at the long, then mentally bactrack one, consider if it is usefull, repeat; all while controlling the cursor.
Wouldnt be better to plot the path followed by the robot? This way you (the player) dont calculate the backtrack positions, you 'see' where a eraser will move. In levels where is allowed to step two times on a cell, only the last k steps can be show, in order to not clutter the view.

Trobadour on 2008/04/08 14:24:

>> Wouldnt be better to plot the path followed by the robot?

Yeah, that seems to be a good idea. A first approach to this are the flags that shows if a position was passed or not, but if a path becomes complicated it's hard to figure it with the history queue out.

Maybe i could replace the flags with a simple line so that there is really a path on the maze that the player can easily follow. So the player have to focus for this only on the mace and the falling balls.

Another thing that the history shows are the combos the player used. But i don't know if this information is so important that it justifies the existance of the history queue. Maybe the player gets more distracted by the history queue than its worth to have the combo information.

claxo on 2008/04/08 14:47:

>Another thing that the history shows are the combos the player used...
has _any_ relevance for the gameplay?

claxo on 2008/04/08 15:39:

>I'm unsure if the player is enough occupied with the collecting and avoiding balls mechanism.

You can add another strategy element:
.probability of apareance for each type of ball slowly changes with time
.cue the player about the actual and future distribution

This at the same time gives another thing to do 'think the strategy', reduces 'wait for' time, and empowers the player.

The quirky part is to found an effective way to cue the player, because the main attention is at the cursor.
It must be 'at a glance' comprenssion.
Maybe one ball for each direction, resized proportianally to probability. Normall colors for the 'current time', a little shadowed-alphaed for future times.
Show present (t0) plus t1, t2.

Trobadour on 2008/04/09 11:28:

During playing i had several times the impression, that the ball apperance is not that random as i thought it to be. Several times i sat there and waited desperatly for a specific ball.

I used the standard random.randrange(...) to determine the type of the next new ball, but either i had very bad luck that times or this mechanism is to simple to have a balanced distribution.

Maybe i have to log the types so i can detect, if one type of ball appearead too often and can adjust it.

Also your idea of having different probabilities for each ball type in a level seems interesting. And to give the balls more informations with a specific color and size could be great to let the player focus more on the cursor.

claxo on 2008/04/09 17:04:

>During playing...
!! That was my impresion, maybe subjective

>I used the standard random.randrange(...) to determine the type of the next new ball, but either i had very bad luck that times or this mechanism is to simple to have a balanced distribution.
Humm, in all languages the stock random usually is ok for games.
I will collect some stats and report later.

I suggest a change in event handling:
class Game:
..def handle_play_events( self ):
....if event.type == pygame.MOUSEMOTION:
......[code block for the if] #add the next line as the last in block
......pygame.event.clear(pygame.MOUSEMOTION)

Else the event queue is overflowed by MOUSEMOTION events and key events are discarded. Its a quirk of FULLSCREEN mode.
That will allow to ESCAPE from the play to menu mode.

Cosmologicon on 2008/04/11 19:28:

I'm getting a fatal error. I'm running Ubuntu Gutsy. Here it is:

  File "run_game.py", line 16, in 
    main.main()
  File "/home/christopher/pyweek/6/CQ Robot/lib/main.py", line 1156, in main
    game.change_game_mode_to( GAME_MODE_MAIN_MENU )
  File "/home/christopher/pyweek/6/CQ Robot/lib/main.py", line 722, in change_game_mode_to
    level = pickle.load( f )
  File "/usr/lib/python2.5/pickle.py", line 1370, in load
    return Unpickler(file).load()
  File "/usr/lib/python2.5/pickle.py", line 858, in load
    dispatch[key](self)
  File "/usr/lib/python2.5/pickle.py", line 1069, in load_inst
    klass = self.find_class(module, name)
  File "/usr/lib/python2.5/pickle.py", line 1124, in find_class
    __import__(module)
ImportError: No module named main

I guess it has some problem with unpickling the data file. I get the same thing when I try to do it manually:

>>> import pickle
>>> pickle.load(open("level1.dat", "r"))
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.5/pickle.py", line 1370, in load
    return Unpickler(file).load()
  File "/usr/lib/python2.5/pickle.py", line 858, in load
    dispatch[key](self)
  File "/usr/lib/python2.5/pickle.py", line 1069, in load_inst
    klass = self.find_class(module, name)
  File "/usr/lib/python2.5/pickle.py", line 1124, in find_class
    __import__(module)
ImportError: No module named main

Any ideas?

claxo on 2008/04/12 02:18:

Im not developer of the game, but looks like you start the game from other directory (or a launcher).Try starting from the console, and first changing to the game directory (CQRobot).

Cosmologicon on 2008/04/12 02:39:

Yeah, that's a good idea, but I don't think that's it. If I just say 'f = open("level1.dat", "r")', the file is opened fine. If I then say 'pickle.load(f)', that's when I get the error.

I don't really know how pickling works. But I tried manually changing 'imain' at the top of the file to 'main', and that changes the error that I get:

>>> pickle.load(open("level1.dat", "r"))
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.5/pickle.py", line 1370, in load
    return Unpickler(file).load()
  File "/usr/lib/python2.5/pickle.py", line 858, in load
    dispatch[key](self)
KeyError: 'm'

claxo on 2008/04/12 02:46:

Yes, but note you are not in the gamedir, so pickle cant find the apropiate class.
Try this:
cd to gamedir
run run_game.py
I dont know the exact linux command lines; for reference, if you where in windows
cd games\CQ Robot
python24.exe run_robot.py

claxo on 2008/04/12 03:07:

And dont run from a python interpreter console, just a standart OS console.

richard on 2008/04/12 09:03:

Sorry, I get the pickle problem too. Python 2.5 under Ubunty Gutsy.

claxo on 2008/04/12 09:08:

you started from an OS console in the CQ Robot dir?

Trobadour on 2008/04/12 09:53:

Hi there,
I'm only running windows, but i try to fix this... During the week i fixed several bugs and made some improvements (thx to claxo), and hopefully i can finish v2 today.

claxo on 2008/04/12 10:27:

Starting the game from an OS console (not the python interpreter) in the gamedir, ie .....\CQ Robot works fine, at least in winxp,but...

Hey, Trobadour, I have been looking at several manners of launch the game, ( see below).
I think part of the problem(the interpreter starts) is an artifact of the skellington; the OS console starts that fail can be fixed(if you eliminated the skellington) by a wiki cookbook recipe,
http://www.pygame.org/wiki/RunningInCorrectDirectory?parent=CookBook

python console:
>>> os.getcwd()
'C:\\Python24'

>>> execfile( r'D:\pygames\pyweek 6\_vistos\CQ Robot\run_game.py')
Traceback (most recent call last):
  File "", line 1, in ?
  File "D:\pygames\pyweek 6\_vistos\CQ Robot\run_game.py", line 15, in ?
    import main
ImportError: No module named main
>>>

>>> os.chdir( r'D:\pygames\pyweek 6\_vistos\CQ Robot')
>>> os.getcwd()
'D:\\pygames\\pyweek 6\\_vistos\\CQ Robot'

>>> execfile( r'run_game.py')
Traceback (most recent call last):
  File "", line 1, in ?
  File "run_game.py", line 15, in ?
    import main
ImportError: No module named main

>>> os.chdir(r'D:\pygames\pyweek 6\_vistos\CQ Robot\lib')
>>> os.getcwd()
'D:\\pygames\\pyweek 6\\_vistos\\CQ Robot\\lib'
>>> execfile( 'main.py')
>>>
(no screen build for game, command return near immediatelly withuot any message)

From OS command prompt:
(current dir: c:\)

C:\>"D:\pygames\pyweek 6\_vistos\CQ Robot\run_game.py"
Could not load image "data\game_mask.png" Couldn't open data\game_mask.png

(current dir: CQ robot\lib)

D:\pygames\pyweek 6\_vistos\CQ Robot\lib>main.py
(no screen build for game, command return near immediatelly withuot any message)

Interesting, huu?

claxo on 2008/04/12 10:36:

richard: I have seen some of those messages in report bugs for other entries; maybe you can make a post suggesting to start the games from an OS console (not the python console) in the same directory when run_game.py lives?
I dont have an entry, so I can not start a thread.

claxo on 2008/04/12 12:47:

Yes!Yes!, blame on you, skellington!
I refactored to get rid of the indirection run_game.py->main.py, added the pygame cookbook recipe for current dir (an old one, not the current) and:
--now I can run from the python interpeter console, ( if changedir to the entry module, who after refactor was main.py)
--now I can launch from an OS command console in every dir (previusly this would give the spurious could not load image...
so, you know: to be in the safe start any pyweek entry from the a OS command console , and move first to the directory where the run_game.py lives

Cosmologicon on 2008/04/12 15:05:

Yes, of course I was already doing that! I always follow the README file. I just started the interpreter to try to isolate the error once I'd seen it.

Has anyone with Linux gotten it to work, and has anyone with Windows had this same error? It seems to be a Linux-vs-Windows issue. Is it possible there's some difference in how python pickling works in the two cases?

Trobadour: If the pickling was originally done with another python script, maybe you can include that too?

saluk on 2008/04/12 20:15:

Perhaps automatic logging (output redirect) should be put in the skellington? I actually have some other ideas for tools to help make testing games smoother and make common bugs harder to slip through, but most of them require code analysis which I don't have much experience for. I'm thinking of things like, making sure the case matches in all paths, or double checking that fonts are included. Anyone have any other ideas? Perhaps we should make a separate thread for skellington improvements.

richard on 2008/04/12 23:37:

@clazo: the skellington already includes these instructions in the README:

On Windows or Mac OS X, locate the "run_game.pyw" file and double-click it.

Othewise open a terminal / console and "cd" to the game directory and run:

  python run_game.py

I cannot get this game to work when I follow these instructions.

@saluk: I'm always interested in people willing to work on skellington to improve it. The path case checking has been suggested before.

Trobadour on 2008/04/13 16:18:

Hi there,
I created a new version of CQ Robot and hope that it will fix some problems with the level files. I changed the file endings to unix (just a guess, maybe it helps). My level files were created with an ingame editor.

You can enable the editor by uncommenting line 789 in lib/main.py. This will create a button in the game menu to enter the level editor. But be aware that the usability is down the drain. Also you may need to adjust the first coordinates of the button for the main menu.

The level editor loads and saves one file called default.lvl and pickles the class Level. I created the levels by clicking them together, saving them, renamed the file and opened the file with an editor (PSPad) to adjust the time- and point limits and to add hints.

Have fun!

claxo on 2008/04/13 16:20:

pickle error fix?
filter the '\r' in the *.dat files
why?: seems the files has been hand edited in windows, in a tool that saves in native line endings, thus injecting '\r' chars.
pickletools.dis() diagnosed problems even in windws.
after filtering the files, pickletools.dis() does not complain (in windows).
So, maybe something more, but its worth a try. Please report if this fixes the pickle problem or not.

claxo on 2008/04/13 16:22:

:-) we crossed

Trobadour on 2008/04/13 16:45:

Yep :) but after reading your post, i tested pickletools.dis() and i cannot find a clue what maybe wrong. I checked both the final level1.dat and the version 2 level1.dat.

How did you recognize the "\r"? I started python from the console and typed:

f = open("level1.dat")
s = f.read()
print s

Also i used pickletools.dis(s) and there i couldn't also spot errors or warnings.

I'm running windows xp with python 2.5 and used PSPad as editor. Final level data was saved with windows line endings and version 2 files were saved with unix file endings

claxo on 2008/04/13 16:58:

I cheked only on level1.dat
To check:

import os
from pickletools import *

f=file(r'..\level1.dat','rb') #note that is 'rb'

dis(f)
f.close()

to clean:

import os
from pickletools import *

f=file(r'..\level1.dat','rb')
s=f.read()
f.close()
s=s.replace('\r','')
f=file('test0.dat','wb')
f.write(s)
f.close()

The diag shows for the original file:
ValueError: strinq quote "'" not found at both ends of "'time_limit'\r"

claxo on 2008/04/13 17:02:

Err, Trobadour, maybe you are not allowed to post new versions till the jugdes are done ? Ask Richard in doubt.

claxo on 2008/04/13 17:07:

By the way, I think that for portability reasons if you pickle-unpickle then the more portable is storing-loading to-from binary streams; that way no injections - deletions are made.

Trobadour on 2008/04/13 17:28:

Yep, i know that only the version commited as final is to be judged but to be on the safer side i added some notes to my version 2 entry.

The binary stream pickle is definitely one thing i will try. Maybe there is version 3 on the way :)

claxo on 2008/04/13 17:36:

To be clear, by 'binary' I mean to open the files in binary mode ('rb','wb'), not using the pickle protocol for binary nor the deprecated third ,bin parameter.
Well, go foward with CQ robot !
PD: I apreciate the various thx.

Cosmologicon on 2008/04/13 18:07:

Stripping the \r's is a good idea, but I tried it and it still doesn't work on Linux.

Trobadour on 2008/04/13 18:44:

Dooh, i will try if the binary thing works better.

richard on 2008/04/14 01:12:

Just to be clear: the '\r' characters will have been inserted when writing the pickle file if you did something like this on Windows:

pickle.dump(data, file('level1.dat', 'w'))

instead of:

pickle.dump(data, file('level1.dat', 'wb'))

That "b" is critically important on Windows.