Two coloured teams interact, and by attacking one of them, you will change your diplomacy level.
When "enemy", the units will have higher probability to target you then other enemy units, and their damage will be proportional to the enemy level.
When "neutral", the units will target you around as often as they do for other units, depending on the diplomacy level.
When "friend", the units will still target you, but way less often.
Fix for one possible bug:
If you have: "TypeError: Cannot cast ufunc add output from dtype('int16') to dtype('uint8') with casting rule 'same_kind'"
it is due to new behavior of latest numpy version (unfortunately, I was not aware of that and I did not checked with the latest numpy version).
You can fix this bug really easily by changing the following lines 371, 372 and 373 in game/op_display.py (in fct medal_paint):
"arr[:,:,0] += l-255" becomes "arr[:,:,0] = arr[:,:,0]+l-255"
"arr[:,:,1] += l-255" becomes "arr[:,:,1] = arr[:,:,1]+l-255"
"arr[:,:,2] += l-255" becomes "arr[:,:,2] = arr[:,:,2]+l-255"
- The diplomacy level for team A will increase if you kill an unit of team B. But it will change more in case of number of units imbalance (if there is 10 units of team A and 1 unit of team B, or if there is 1 unit of team A and 10 units of team B).
- When an unit of team B is killed, the diplomacy level for team B will decrease, independently of the number balance.
- The diplomacy level is always slightly decreasing with time. It will decrease faster and faster as long as you don't hit an opposite team unit. It decreases also faster for the team with the highest diplomacy level.
- The amount of firing will slowly increase with time. The bonuses will also get more rare. Eventually, the game will be harder and harder.
- The achievements and high scores are separated for each difficulty setting.
- There are 2 difficulty settings with more than 2 teams. It is basically "normal" with extra teams. In this case, the diplomacy level increase is divided into the non-hit teams.
- For color-blind people, you can change the color scheme in the options to "white, blue and red". As far as I know, they are distinguishable for everyone. You can also edit the save.cfg file with the line "col [[255,255,255],[255,0,0],[0,255,0],[0,0,255],[255,255,0],[0,255,255],[255,0,255]]" to choose specific colours.
- One strategy is to maintain a low level of unit all the time.
- One strategy is to target one team, getting a large number imbalance of your ally team. But when the ally becomes too big (increasing the risk you get hit), you can suddenly attack it and reverse the situation (the large imbalance will make you switch side quickly)
The game is developed here: https://gitlab.com/cauch/ObPortum
Presented by typhonic
Ratings (show detail)
revised version after pw23
How it looks like the 22/02
Achievements panel, 22/02
last update after the challenge
I've read the comments, and I've done several tests to see how I can improve the game.
The main concern was about the random aspect of the game. I've tried with more predictable patterns, but I don't really like it.
In fact, I'm not sure I agree with the fact that this game is more oriented "random shooter" than "skill". Of course, if you fire just one bullet, then the fact that you will hit or miss will be random. But the point is that you can fire several bullets correctly placed such that you have 100% chance of destroying the target.
So, the required skill is deeper than just "clicking once a the correct place", it is "clicking several time at the correct places". It introduces aspects that I think are more interesting. For example, you can choose your target or move to a specific position before shooting knowing that some bullets will miss.
I have uploaded the updated version, just for consistency.
Few thoughts, part 2
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.
Few thoughts, part 1
My main fear before the start was to not have enough time to deliver something sufficiently complete. I've heavily brainstormed the different themes when I've got the list to be sure to be able to start coding as soon as possible. And I've started Sunday morning. I had something appropriate on Monday (I was expecting to have it more about mid-week).
2) design: I like it, but I hope it will not be considered as cheap.
My idea was to work on a correct design since the start. I personally observe that I enjoy more a game that looks visually attractive, and I did not wanted to degrade the experience due to unattractive graphics. I am personally pretty pleased with my game's graphics: I like the abstract vibe, and some aspects are more fitting (Squares are better for left-right-up-down motion mechanics and I like it more than a rotating system that I have tried before). I'm just worried that people will judge it cheap, because it's easy to code (the squares are just squares). But I still think the game is prettier and has more character with those squares than with space-ship drawings.
3) guilt feeling about my work productivity.
Yeah, I have to say: I think my work productivity (you know, the "real life work") has slightly suffered from pyweek. I tend to do small pauses to quickly implement a small idea (or to write a diary entry on my lunch pause). Well, it's not so bad, I had worse productivity during some weeks with particularly low motivation. But still. Or maybe I'm too harsh on myself.