Ammo racks

Hey, there were extra parts...

This week's achievements are small but enormous. I made a mess on the floors, so they wouldn't look freshly painted, which suits a filthy warmachine a bit better. At some point I messed  up a bit with the ammo tubes but despite that fact I had decided that I wouldn't try to dump all 32 tubes into the racks as the instructions suggest. Why so? Because I feel it makes the whole model look a bit less staged when everything's not full and perfectly set up.

Trickiness

From some depths of my memory banks  I recalled reading that pieces of tape make good seatbelts for pilots, for example. I applied the idea to my project a bit. Meaning: I cut pieces of masking tape and then split them lenghtwise to make them fit the scale a bit better (judging by the look, not empiric facts). Then I slapped them over the ammo things somehow and gave them a quick Devlan Mud wash to make them less eye-searingly bright. Now they're supposed to be cargo straps truckers use to tie down their loads and whatnot. Of course I didn't even think of scratchbuilding any kinds of lock pieces or anything.

It doesn't look half bad to me, at least.

Back to the paints

Important things first

The real world has again slowed my differend projects (3+) and their advancement. But what can you do, hobbies aren't always on top of the priority queues. Anyway, I grabbed myself gently by the neck and airbrushed the inside pieces I assembled last year. After that I googled a bit to check if there were any colour photos of the Achilles and its insides for reference. This way I might be able to finish with something that at least resembles something real...

The result of careful research

It looks like the radio and that other box should be greenish. Let's see if I could get to paint them a bit later today, even. Of  course that depends solely on the demands of the universe that (rather surprisingly) doesn't revolve around me.

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.