Few thoughts, part 2
cauch on 2017/02/23 13:05
of cauch
Before the challenge started, I was planning to care particularly about the coding style. But as soon as I'm working, what matters is just making it work. Don't get me wrong: my style is not the worst (too many cryptic variable names such as "ess", "lkn", "lll", ...). I will probably do a lot of cleaning during last day. Same goes for the code quality: as the code evolves, one realises maybe a different strategy should have been used. For example, I have two objects for the units, one for the sprite and one for the core code (independent of pygame). I could have done something nicer (maybe I will if I have time).
5) sea urchin.
Why are sea urchins called "sea urchin" ? Is there "non-sea urchin" ? If yes, I would like to be informed, this is a major safety issue.
6) gameplay: I like it, but I hope the special features will be noticed.
I was worried about the fact that the final game never looks like what you have in mind first. Also, "the lesser of two evils" was not my first choice (maybe I will end up coding my other ideas later). At the end of the day, I am happy with the game I've made and I think it has good quality. There is a "long game" aspect, where you can try to beat the game by getting all the achievements, and a "casual" aspect, where you can play a short game just to beat the latest time score (in hard mode, it should be difficult enough to be a quick game). There is no level, but: 1) adding new achievements is quite easy (without touching any other part of the code, thanks to the power of python), 2) there are several things to explore: trying achievements, trying to get a low or high number of enemy, different ways to keep the balance, ... But again, at first, maybe some of those aspects are not visible. I'm afraid people will just "kill them all" without caring about the balance. Maybe I will do something about that.
(log in to comment)
Comments
cauch on
2017/03/01 12:53:
You can fix this bug really easily by changing the following lines 371, 372 and 373 (in fct medal_paint):
"arr[:,:,0] += l[1][0]-255" becomes "arr[:,:,0] = arr[:,:,0]+l[1][0]-255"
"arr[:,:,1] += l[1][1]-255" becomes "arr[:,:,1] = arr[:,:,1]+l[1][1]-255"
"arr[:,:,2] += l[1][2]-255" becomes "arr[:,:,2] = arr[:,:,2]+l[1][2]-255"
For info, this is due to the fact that numpy is less tolerant in newer version. I've tested my game with the latest python / pygame version, but I was not aware that pygame was using numpy there (and even less that numpy introduced new errors).
game is not working
ObPortum/game/op_display.py", line 371, in medal_paintarr[:,:,0] += l[1][0]-255
TypeError: Cannot cast ufunc add output from dtype('int16') to dtype('uint8') with casting rule 'same_kind'