My coding project, part IX

Searching for life

Having only asteroids and ships wouldn't be that exciting content for a game. In this phase I decided that maybe a single planer per sector would be enough. Especially as my sectors were only 1024x1024px, you couldn't fit many planets there anyway. Maybe later the scale will be a bit more grand, we'll see.

In the first iteration of my game project the planet was rendered as a pygame.circle, but it looked a bit sad, because all the other gameobjects were antialiased polygons. So, rather expectedly, I decided that my planets would be (at this point at least) 16-edged polygons. Otherwise the planets are just like the asteroids, they just don't move or spin.

According to a fuzzy mental image a guy I know asked in the comments (in the finnish version of this thing) much, much earlier something about the planet types. So I pulled a few (for example: industrial, farming) out of my nonexistent hat. In the future they'll get more attributes as just type, mass and population don't really get us far. Oh, and to somehow simulate the effects of those cobalt-shelled bombs, I guess that (background) radiation should be one of them... Muah muah muah.

What next?

Physics

I guess I'll return to the QuadTree and collision checks next. After the collisions are handled, the deflections need to be worked on so that they'd work sanely. And of course I have to fix the ship's acceleration so that flying would feel a bit more real than the current jerky movement.

Weapons, destruction, death

When I've at least started with the collision checks (so I can test them), I guess I could proceed to work on some sort of a weapons system. Death rays may not be the first ones, anyway, but autocannons or missiles are much more likely. We'll see what tickles my fancy at that point.
Those also need to be tested on something, either asteroids or my dummy spaceships. I believe I'll start with the asteroids, because they'e mostly done already, or that's what I tell myself at night.

Odd ideas

How can a player dock to a space station? Or can the player do absolutely anthing with a planet?
I got an idea from the old, fun Zone 66. In it if you flew slowly enough over a landing pad, you'd land on it and if you went too fast you'd just fly over it. The exact same could work here: flying slowly enough by a space station would put the game in a docking / docked mode. Or flying slowly over a planet (no, you can't crash into a planet, they're on a different z-plane in this game) would put the game in an orbit mode where you could do things.

Up to this moment my only absolute requirement regarding that is known as orbital bombardment. Of course the player has to be able to sow his/her arch-nemesis' home planet full of mutated bubonic plague if they so desire. Naturally this requires the planets to have some sort of methods to defend themselves against all kinds of psychopaths with bioweapons and low moral standards. Methods such as the planet's surface bristling with missile silos, ion cannons standing by, swarms of fighters on their launch pads and orbits packed with armed weapons platforms. This is a good place to start with, right?

Everybody (I do at least) hates those telepathic factions in games. These well-known buggers know instantly if you have, for example, robbed their brother on the other side of the known universe without anyone seeing/hearing and get raving mad at you. If I managed to avoid this, I'd be ultrahappy.

A distant dream?

As a funny example: you attack a cargo freighter and sneakily kill its only escort with a lucky surprise attack. You murder the crew, steal the cargo and escape. No one has seen anything, no emergency broadcasts could be sent because everything happened so fast of your scrambler overpowered their weak radio transmitter's signal. Your pre-existing wonderful reputation is still unstained and why not? In the eyes of the whole galaxy you're still the saint they believe you are.
Or at least until you start selling the potentially recognizeable cargo...


This is what I've been pondering in my sick mind.

My coding project, part VIII

Move it!

Now that I had something random on the screen, I proceeded to my flying methods. After a bit of pondering I decided to stick to my speed vector approach and use a heading information for convenience. Because the displayable area was tied to the ship's position, moving the ship moved the viewport around the sector.

Rotating the ship around its axis was really simple and that's as much as I'm going to blabber about its rotate-methods. Acceleration was a big subproject the last time and it didn't let me go easily this time, either. While I'm writing this the whole accelerate method is still a work in progress, so I have to return to it later. Now I was content with being able to fly around the sector, even if it wasn't that elegantly done.

First it calculates the dx and dy values based on the heading and the acceleration. Then it checks where the nose is pointed and uses that to decide the sign of the values. If the new speed is going to exceed the ships's maximum speed, the full acceleration is not allowed. As I said, there's something fishy in my current implementation.

From one sector to another

At this point I came up with the next question: what happens when you pass the sector's boundaries? You fly to the next sector, of course. Because I hadn't set up the neighbour links to the sectors before, I had to return to the world's init. And because the sectors are initialized in a simple loop, I had to work a bit to get to the neighbour info to begin with.

In the end it took a few hours on a few evenings and caused some refactoring here and there (at least in classes Player, Sector, World and Game). My world init was slowing down considerably: when the sectors are first created, they're iterated again to first find out and set the neighbour links to directions north, south, east and west, based on their "coordinates" on the map.

When the sector's being changed the player needs to have the new sector set, the ship is to be thrown to the nearest end of the new sector (when you go north, you're moved to the southern end of the northern neighbour), it needs to be detached from the current sector and inserted into the new one. And then the sector's gameobjects are to be loaded into the world's quadtree.

I was pretty proud of my work right now, after all the swearing. In addition to everything mentioned above I also refactored the world init to be a bit prettier. Each of the sectors got a randomized amount of asteroids in them, while the vegetative enemy ships were just commented out for the time being. This was all done so that the debugging got a bit simpler.

My coding project, part VII

After a long break

My pygame project has advanced more than you could guess by the amount of posts about it. Mostly I've been fooling around with the background stuff, not much of what I've done will be directly visible to the user. Then again, if you look at the previous post, quite a bit has changed.

The last time we got to a part where the game world and its sectors were created and a map based on that was shown to the user. At this point there's absolutely nothing to play so I refuse to call it a "player". The map could be opened and closed and the game could be (un)paused. Basic stuff but nothing spectacular.

Next steps

In the first iteration of my project the game's view was fixed and the ship flew around freely. The first thing I had to do was to attach the viewport to the ship. So the ship would always be in the center and the viewport would scroll around the sector, following it. Because the sector would always be (much) bigger than the viewport, there was no sense in rendering objects that weren't inside the viewport's area. Therefore the sector would need a data structure for its gameobjects that would give all the necessary information to achieve this.

QuadTree

The idea of a QuadTree is that whenever a single cell's capacity is used up, it subdivides into four subcells where the objects will be redistributed. And so on and so on until the maximum depth of the tree is reached. No explanation I give can be better than the existing ones so you can read more from wikipedia, for example.
The necessary explanation is that I implemented my own version (or a part of it) of a QuadTree. At this point, when its mere existence is enough, all the sector's contents is inserted into the qtree. The aforementioned need of finding all the gameobjects inside the viewport was the first real use case. Because the sectors are squares, all my gameobjects are basically squares and all the quadtree cells are squares, everything can be solved with pygame's colliderect methods.

def get_contained_objects(self, rectangle):
  contained_objects = []
  if self.gameobjects:
    for gameobject in self.gameobjects:
      if rectangle.colliderect(gameobject.get_rect()):
        contained_objects.append(gameobject)
      if self.top_left:
        contained_objects.extend(self.top_left.get_contained_objects(rectangle))
        contained_objects.extend(self.top_right.get_contained_objects(rectangle))
        contained_objects.extend(self.bottom_right.get_contained_objects(rectangle))
        contained_objects.extend(self.bottom_left.get_contained_objects(rectangle))
  return contained_objects

What's most important in the code above is the rectangle parameter, which is the surface area of the viewport. That viewport is calculated around the centerpoint of player's ship. While working on that also the offset of the ship from the sector's 0,0 point is calculated. That offset is needed to render all the other gameobjects related to the ship.

Maybe (most likely, even) I explained it a bit funnily, but what can I do. Solving this small set of problems took a few evenings and sessions. I was pretty proud when I finally got it working properly. My biggest problem had been that I thought of it way too complicatedly - yet again.

Return of the GameObjects

Of course I needed something to be rendered on the screen, so that I could check the basic functionality of my QuadTree. In  the beginning I had those three subspace pirate ships I mentioned a related post or three ago. In addition to those I wanted to return the Asteroids back to the screen as well, but better than the last time. While I was on it, I'd test the insert and division methods of the tree with some randomly generated content.

My old asteroid code was almost directly transferrable. Mostly I added some more randomness to the init. Based on a 2d6 toss, a result between 9-12 spawns an ice asteroid, otherwise a rock asteroid. Anohter 2d6 decides the size with the old familiar small / medium / large / enormous options. The material affects both the color, the randomized mass and the rotation speed. Those asteroids that consist of rock are both heavier and slower than the icy ones.

My coding project, part VI

Another approach vector

Earlier I started coding straight with the game objects and their controls. At some point I tried to insert some stuff I had left out before but somehow fighting with that .py file wasn't too much fun. The existing code was plentiful and that alone made it unpleasant to refactor heavily in IDLE that I still use, thanks to my laziness. So I started another side project for the rest of the game and other additional neatness. Later I could combine my doings into one nice packet and enjoy/suffer the consequences.

From one state to another one

I decided to start by defining a couple of states for my program to be in. Handling the events would be nicely divided depending on the states:

• in main menu
• in map screen
• in game
• is paused

Like so. The main menu idea comes from the Apogee platformers I spent ages playing, I believe. The main point is that you can start a game and quit it - the other options, such as save, load/continue (depending on what kind of savestates I end up implementing) and the settings can be implemented much later, but they'd have stand-ins displayed already.

When the game is started, the game world is initialized by a set of parameters, all of which are hardcoded at this point. My Java-background could be seen as a contributing factor to the increasing amount of classes and inheritance.

Constructor of Worlds

I pondered for a good while, what would be essential in this game. The Game naturally has all that's needed to run the game itself, such as the state, settings and rendering of various views. Game has a World object that contains the game world's data, it's size (at the moment it's a 3x3 universe), things like the Factions and whatever they need. The World consists of Sectors, which translate into "levels" where the player will fly with his/her more or less battered cruiser. What does the Sector contain? Right now just its size (in x,y), its owner (either no one or one of the Factions). Later on it's going to keep track on whatever it contains, such as Fleets, Planets and what have you.

"Politics"

At the moment the Factions have a name, an identifying color, race, policy and zero+ Fleets. As far as the racial crap goes, they're either humanoid / insectoid / robotoid / mixed - I wasn't very innovative when coming up with these. The only effect the race has is through the policies. There are three different political ways of seeing the world: neutral, xenophobe, aggressive. The idea is that the neutrals don't care about your race, the xenophobes get mad if you're of a different race and the aggressives don't give a flying crap about what you are as long as you won't be that way for long.

Maybe it was a silly idea but I also decided that there are some ways for the Factions to work with each other. Allies, friendlies, neutrals, unfriendlies and enemies - there are five ways two different Factions can try to relate to each other, if they are able to.

Extending politics

Nobody's interested in giving flowers to passers by, so war is to be waged. To do that I thought that Factions should have Fleets. A Fleet could consists from one or more Capital Ships, that may or may not carry fighter-scale vessels and such. Just to try out the generator I set the world initializer to build a couple of Factions to share the universe with the player. One of them is hardcodedly named as the Subspace Pirates (race: mixed, policy: randomly chosen) and it has one Fleet called "Hammer of the gods" in the starting Sector and it consists of three Ships ("Thunder", "Wind", "Rain"). Fun. The rest of the names to everything and anything are going to be randomized with a bullshit generator with a very obscure resultset, I hope. I like randomness quite a lot, it makes testing quite a bit more interesting because not everything happens always 1:1 the same way, in the same order and so on.
Fleets can be assigned a target sector, so they wouldn't be tied to a certain Sector but they could move where needed, to harass the player or another Faction. At least on the idea level it should work. Of course it'll be a completely different story when I get to the scary part of trying to write a sort of an AI...

On the map or completely lost?

Whenever the game has been started and the World initalized the player gets to admire the wonderful map screen. The first Sector on the top left has a marker for the player's Ship's relative position in the World/Sector. I thought I'd use the same marker in the minimap, if I ended up implementing one later down the road.

3x3

5x5

At this point, when you leave the map scree, there's nothing else to do. You'll end up with an empty viewport and you can either go back to the map or to the in game menu (continue / settings / exit), which I set up a couple of days ago. Oh, and hitting the k key kills you and you get to see the Game Over screen and then you get to proceed to the main menu. It's all pretty important, in the end.

Perhaps my next step is to use my old classes somehow to get some action on the screen. One huge thing to ponder is the GameObject's speed... do I want to keep the previous implementation (x and y speeds) or do I want to have it divided into speed and angle variables. These things have to be poked at in any case so I can't just rest on my laurels and slack off.

My coding project, part V

Tiny changes

My advancements in this project over the last few weeks have been few, thanks to my almost three-week long vacation and all the other bothersome things. I tried to tinker with the collisions so that if a bigger thing is hit, the bigger one is affected a lot less than the small one. This way the gigantic rock doesn't shoot out after being hit a tiny but fast 'roid. Yeah, a tiny change but it feels better this way. Oh, and if you're lucky, the ultrarock cracks into two large pieces.

Just for the fun of it I checked how this all looks if there's a light blue grid on the background, as if everything was just scribbled on a piece of paper. Maybe it doesn't work as nicely as I thought. Let's give it a try anyway.

Looking for a scribbly effect

It's raining rocks!

While I was fooling around I wrote a tiny Planet class. On the screen all you get is a screen and on the background it has crap like a name, mass, population and some other unimportant things. When the rocks start hitting the ground the population plummets until no one's left. It was surprisingly fun to test it :p

Candyland II

Any things that go boom and death rays are still in the "ideas" state. I did start checking on how to check if two lines cross (and where) but didn't get far with that. Yet.

Other projects

Maybe I'll get to work on the tank model too, when we get to next week, but that depends on everything else. Days have been pretty busy lately. In any case, it interests me quite a lot after all these weeks.

My coding project, part IV

Adding some functionality

I was happy that I had this and that on the screen, doing this and that, but nothing affected anything. This, obviously, wasn't acceptable, so the next attributes added to the GameObject were hitpoints, for example. Of course I added much more junk to it but none of it makes any sense or difference at this point, so we'll just ignore them for now. As I had decided to work on something Asteroids-like (no, I wasn't going to stay there but to add much more weird but interesting junk) project, (not) colliding with things is pretty important, I guess. While writing up this set of posts I've also worked on more than makes sense to explain now.

Collision ponderings

• The rocks can hit the player's ship and vice versa
• The rocks can hit each other
• The speed difference should matter
• Mass differences should matter
• The collision angle is also important

Two-phased collision detection

Because at a given moment there can be quite a good amount of Objects on the lists, there's absolutely no point in checking each and every one by the pixel. It's maybe better to first check if any two objects are about to collide and only then go for a more accurate check, if needed. In the first phase - at the moment - I just iterate through the list of all the 'roids and the player's Ship and compare each other's basic areas for overlapping. To this task pygame's rectangle.colliderect() function is just fine:

def collides_with(self, other):
        collides = False
        if self and other:
            if self.get_rect().colliderect(other.get_rect()):
                collides = self.accurate_collision(other)
        return collides  
def accurate_collision(self, other):
        return True

Naturally the second method is only a stub that I'll implement properly whenever I get to it. Right now it just says "yeah, yeah, they do collide, stop bothering me already" and then both colliding GameObjects get a 2d6 amount of damage until one or both of them are destroyed. Because there are four sizes of Asteroids, the bigger ones break into n smaller Asteroids, if the masters of d6 so decide.
While testing I got rather quickly tired of my ship being destroyed while flying around, so I added a Megatron-like cheat. The game says Afterdeath and the Ship's hitpoints are replenished as if nothing had ever happened.

One chilly morning I was chatting about this project with a yet another coworker of mine (he had noticed some mumblings of mine in g+). Among many others a comment about the lack of antialiasing was brought up, he asked if I had considered using it or if I was going for a more retro look. My answer was that yes, I was going to do that whenever I got some more important and more bothersome stuff done out of the way. While we were chatting we took a look at Pygame's docs and we noticed that if I just switch all my draw.polygon-calls to draw.aalines and add a single True variable, nothing else is needed. So I tried that out the same evening and it does look much nicer, doesn't it?

Antialiased

After the collision

Because it would be rather ridiculous to have the space rocks flying inside and through each other after the initial collision, giving more and more damage, I thought it'd be handy to work on the deflect-method that would count the new speed vectors and angles to the colliding parties. If I could come up with something even remotely like billiards table physics, I'd be a happy *camper*. When that gets combined with critical hits (a small but fast Asteroid could crack an enormous one in two, for example), the result could be pretty fun. Oh, and the planets and who knows what else... I've got absolutely nothing ready so far!

"War. War never changes."

For everyone who's listened or read to my endless mumblings it's clear as day that among many other weird things Star Wars and Battletech are (and have been) big things for me. Especially BT is something I'm going to get some weapons-related influence. The main idea is that the player could choose one or few items of violence in their ships, depending on the ship's slots. Missiles/rockets, death rays (with or without pulses), automatic cannons and particle cannons that spit out cerulean bolts of lightning. Muahahahaha!
And if you can swap the weapon modules, why not the reactor as well? 

I'm just throwing ideas around, I'll find out later what on earth I want to do with this.

My coding project, part III

Wherever my nose points at

Now that I had finally fixed the rotation and found out where the hell it's pointing at, the last of the unimplemented basic functions was the movement. My first attempt was, especially in hindsight, ridiculous: if the angle was pointing to one of the cardinal directions, the full acceleration was applied on one axis - if somewhere in between, the acceleration was applied to the two closest ones. While testing it first looked nice, but in a while I noticed that "Heeeeyyy.. this thing jerks around when it's turning and accelerating. It looks pretty odd now". Even the slightest difference from a 3π/2 angle made the polygon accelerate at full speed towards the closest intermediate direction. Whoops.

A bit more realistic change of speed

After a very short but intense moment of screen-staring a lamp went off in my head: if I went and used the same damn trigonometrical functions that told me where thing was facing but using the known speed and angle to get the Δx and Δy values, I'd be done! So, the same trick but opposite direction. Luckily it didn't take me more than a couple of minutes to come up with this.

tempspeed = Vector(self.speed.x, self.speed.y)
dy = math.fabs((math.sin(self._angle))*self._acceleration)
dx = math.fabs((math.cos(self._angle))*self._acceleration)
# ...


Of course this isn't all, the method still needs to check the heading and decide if the Δx and Δy are positive or negative. With that piece of information the acceleration can be applied properly and to the right direction. The main thing is that it looks good to me right now.

Particle effects!

It gets pretty old pretty soon, moving a simple Shape. So I worked on a Star Control (or Auts or V-Wing or Wings) style acceleration effect. Without spending more than a few seconds on thinking where the engines would be located, I just marked* the bottom edges of the triangle shape as the engine points. Now whenever the acceleration is triggered, a set of tiny box Shapes are dropped at the current coordinates. These Shapes fade away slowly and die away after a few cycles. While I was playing with that I made a silly warping method, where the polygon is relocated in the middle of the game area. At the previous coordinates a set of eight particles are created with speeds set so that it looks like an explosion. It's a funny effect even if I say so myself. That was going to be used to do explosions in the game for real, not teleporting 8)

*) I was farsighted this time. The initial version just takes a set of coordinates for the engine exhaust points, as many as I want, so I can do however I want later. More or less. Perhaps this helps me avoid a couple of rounds of "refactoring because stupid".

Adding some friends on the screen

All in all, what do you do with an almost triangle shaped thingamagick on a 2d space if it's there alone? You'd get bored out of your skull pretty quickly, I tell you. So my possibly retarded idea should be clear to everyone: I'm going to dump in some asteroids! 

I was pretty excited when I got my eight-pointed semirandom shapes on the screen in four different sizes, spinning slowly around either clock- or counterclockwise and after a couple of iterations they even flew through the screen on their merry ways. That was an awesome moment.

Swoosh!

At least I was damn proud of that.

My coding project, part II

I think I said the last time that I've never tried to do anything graphic for real, unless you count those TurboC++ tests that just vomit squares and circles on the screen (no, they do not count). So my first problem  jumped out already. It was simple to get my four-pointed polygon in the middle of my surface, but moving it...

I'm going to mumble about my "aha!" moments and ponderings as I remember them and when they have some kind of point to them. I don't guarantee a good quality, just like I never do ;)

Position, rotate, relocate, draw

So my first version used a set of hardcoded coordinates, yay! I thought that it's a good starting point, but oh, how wrong I was. Maybe the issue was within my own rotation methods and it'd all been awesome if my methods had been fine, but maybe it would've sucked anyway. The initial situation was rendered prettily but a single rotation distorted the form beyond recognition.

Via the zero point

From somewhere I came up with an idea (and after talking to a yet another coworker of mine my guess was proven correct) where all the shapes should always be initialized around the (0,0) point. This way the rotation of any polygon would work the same no matter where on the 2d space they are.
So first you always set up the vertices in the same places, then shift the coordinate points to the actual positions where they'll be rendered on the screen. A really simple and I guess it's a childishly basic thing, but who would've told me?

Rotating the 2d coordinates

My mathematical studies are years old at best and I have to admit that in elementary school (even longer ago) I was one of those fucking annoying brats who declared that I would never need maths or trigonometry after the 9th grade. Oh yeah, once again we see that reality doesn't always agree :)
After a couple of weird and stupid "I'll do this myself"-kind of attempt I encountered something called affine transformation. That was a nice, handy thing and the implementation was just about 1:1 with what my dear friend Wikipedia told me. You just drop it each vertex of the polygon at a time and the desired rotation angle (obviously this is always the same for a single shape), this beast simply returns the new coordinates for the given vertex.

def rotate(self, angle):
        rotated_points = []
        for point in self._points:
            new_point = self.affine_transform(Vector(point.x, point.y), angle)
            rotated_points.append(new_point)       
        return rotated_points

def affine_transform(self, point, angle):
        temp_x = ((point.x * math.cos(angle)) + (point.y * math.sin(angle)))
        temp_y = ((-point.x * math.sin(angle)) + (point.y * math.cos(angle)))
        return Vector(temp_x, temp_y )


Hah! The next issues I encountered were the angle (I was, again, making a mess with degrees and radians, but that was because of my infinite stupidity) and the movement. The movement was a bigger issue and took quite a bit longer to fix. Pretty soon I was able to rotate my more-or-less-triangular shape around it's own z-axis but if I tried to accelerate, it started flying towards the top-right corner and beyond. If I tried to rotate and accelerate, it did the same but while corkscrewing carelessly. I was baffled.

How do I calculate where my polygon is facing? 

As my stupid mistake number 74 I forgot my hardcoded "draw this thing in the middle of the surface" -values and another mistake was that the calculate_angle always returned the exact same value for my Object. Somehow I had ended up trying to calculate the facing of my polygon by its sides (because it's basically a triangle). I guess it was otherwise a good idea but it just didn't work here at all.

After a bit of googling and more light headscratching the solution was much more simple than I had thought. Or at least it felt like it for someone as stupid as I am. Because the center point's coordinates are known, as well as the tip's coordinates, you can just take the distance between the coordinate points on  x and y axises (Δx and Δy) and feed that to arctan to get the angle in radians.

I guess that clarifies a bit... or not :p

def calculate_angle(self, center, nose):
        dx = center.x - nose.x
        dy = center.y - nose.y       
        radian_angle = math.atan2(dy, dx)
        return radian_angle

Geniously simple, I say. At this point it looks like that no one can read one word more of this crap on one go. Therefore I'll continue this topic on the next iteration of the Project Mumblings.

Some background for my coding project

Background

I guess "everyone" who has ever programmed anything at all has entertained the idea of making their own game. A couple of decades ago I fooled around with QuickBasic that came with the 486 machine, but nothing spectacular happened. The biggest problem I encountered was that I didn't know anything and all I had was the (somewhat awful) manual and I didn't know where to look for more information.
For some odd reason, most likely my laziness,  I never started poking at game making even when I was actually studying programming and even learned something. From time to time the thought came to me. Just for the fun of it, if nothing else.

Python - Pygame

Some years ago a coworker of mine hinted of this Ruby-based Shoooes thing that I actually wanted to try out but as usual, I didn't get anything mentionable done. That attempt, like so many others that started with the usual "Hey, let's try this thing!"-enthusiasm, died  away. Maybe a year, one and a half ago I encountered Pygame in my rss feeds, a game developing library for Python. To honor the traditions I did give it a try but just left it. I blame it on the lack of good (= implementable) ideas. Drawing circles and squares doesn't entertain for a horribly long time :p

for idea in ideas:

Because coming up with 100% original ideas isn't that simple, what then? Copy others or climb on the shoulders of those giants and wave your arms.
Another of my coworkers had started working on his Roguelike, so so much for that one, even though I wasn't going to do anything under the usual fantasy theme unlike him. In my childhood I spent countless hours on desperately difficult Xenon 2 and years later I got hooked on awesome Tyrian.

Xenon II: Megablast

In that sense I was pretty interested in working on a classic horizontal/vertical scroller shoot'em up. With these my huge issue (before I even started checking anything or wrote even a single line of code) was the levels and all that, so I left those ideas in my ideas box, with the rest of the filth I've conjured up during my years.

Tyrian

Sandboxes, openness, freedom of choice and general randomness (= everything doesn't always go exactly the same way and in the same order) have been things I've liked in games. A total lack of options and especially (tight) time limits are something that make me furious. With this kind of a mindset I was going to have some problems, but you have to start somewhere, no?

Twist!

After all this I approached the whole issue from the opposite end. From my previous top-down to bottom-up -like approach. Not really conciously but half by accident. I was just happily poking around, doing this, seeing what kind of things I could actually do with Pygame and how to do those things.
With a couple of silly coordinate points and a bit of headscratching the pygame.draw.Polygon(...) brought some fascinating things on my drawing surface. "Hey, I could actually go and move that piece based on the keyboard events! How did that work...."

What weirdness am I working on? I'll tell you more next week.
I know I'm an evil teaser and I enjoy it. Muahahhahahaa!