31.7.13

The essentials of aviation

The world of choices

Some promises are to be kept. As a horribly nonsurprising result I took the weaponry under my gaze. The extra tools I advertised earlier in the project couldn't all fit under the wings so I had to do some ruthless cherryr-picking. I guess no one's surprised that the extra fuel tanks were the first ones to be left at the airfield, the normal bombs being the next ones. So, in the end, the plane that took off on a ground assault mission was loaded with two UB-32M-57 rocket pods, two heavy-ish individually packed S-25 OFM rockets and just in case with a pair of R-60 short range AA missiles.

Gear up!

Preparing the aforementioned pieces was a pretty quick subproject, as one could've expected. I cleaned up a bunch of mold lines and crap away and pondered for a moment if I dared to file the missile's canards and wings a bit. No, I didn't dare yet, but maybe later.


Bomb racks

These tools of the trade need to be carried somehow, but the sprue only had two launch racks. As a really bad DIY person I was quite concerned and a bit scared of building my own pieces, but when I was thinking of the whole thing I realized something important. Those pretty small bomb racks would be boringly sandwiched between the wings and the much more interesting (and larger) weapons, not inviting for any real attention on themselves, so maybe I'd survive this one.
Johonkin nuo vehkeet pitäisi saada roikkumaankin, mutta rangassa oli vain kaksi laukaisukiskoa

Simply put: I sliced off a couple of pieces from a sheet of 1mm polystyrene in more-or-less square shapes, using the proper pieces for guidance. Next I took the first piece for prototyping and again with the original as a guide I mengelefied it into some sort of a copy. "Close enough" was my decision and I carried on.



Without a proper carving tool (and skills) I didn't even want to try to copy all the few grooves on the surface. I was content with copying that somehow visible vertical line in front of the piece. Yes, I know, all of those parts are a bit differently shaped and whatnot, but as I said before, close enough for pieces that won't be the main attraction anyway.

Somehow I came up with the thought of including a setting plug only in the last two pieces. I guess I was so carried away with the work in general that I didn't even notice or think of the whole thing. "Do two new pieces with those plugs" you suggest? I think they'll stick well enough as they are.


25.7.13

This and that

Front landing gear

At long last I attached the second support bar into the front landing gear's structure. This time, instead of leaving the piece to cure on its own, I was smart and set the pieces in their final positions before using the glue. Of course the landing gear unit is not glued to the hull, just to make the painting process a bit easier and simpler for me. Perhaps I'll find out that I was totally and utterly mistaken once again. Perhaps my idea was an awesome one instead.




Cones

The engine exhaust nozzles were first painted with Vallejo's Oily Steel and only after that they were assembled. I chose this order to avoid those always enfuriating (and mercilessly revealed by cameras) unpainted spots just on the edge of the area you can actually see. To try my new stuff out I applied a coat of Vallejo's black wash and then wiped the excesses off, as instructed. These buggers will now just sit and wait until I'm done with the painting of the hull before they get to their proper places on the model.




Decoration

To finish up this session I attached the enormous pitot tube. Of course I had tried to clean the part up as well as I could, but still I was left with a feeling that even my own femur would be more elegant, should it find its way on the nose of a jet fighter. I guess one has to pay a price for not being a master of scratchbuilding.
After that I also dropped the odd transparent, lumpy item next to it, the thingie that's on the "neck" of the plane and the seagull-impaling device in front. The last one even seems to be properly straight and all, but despite my cleanup efforts it too looks a bit improper.



Is it the time for violence already?

I believe that my answer is finally going to be: yes. The weapons should be the next ones up, whenever I get to sit down with my model. At least I have to customize a set of racks for them, but I guess it's best that I do that only when I have the carriables ready for good measure.

18.7.13

NOP

0x00

As the title says, No Operation, which translates into "I didn't get anything mentionable done all week" for any of my projects. I'll do my best to fix that somehow and soon.


10.7.13

Working on the rear side

Stabilizers

The next victims of my energetic installation fever ended up being the rear of the plane. Namely those last nameless tailwing pieces. Nicely enough those didn't cause the whole model to be set to any kind of a special position while they cured. And hey, that beast actually started to look like something!




A noticeable defect

While you were ogling at the pics you may have paid some attention to that gaping hole between the (still missing) engine openings. Apparently, as they were dropping the weapons off, they also dropped the breaking parachute that's located between the air brake halves. To fix it I just sliced off a piece of sprue, trimmed it down a bit and then glued it to cover the opening, congratulating myself. It's an ugly fix? Maybe, but in my opinion it's always much better than a missing piece that reveals the insides of the model.


To wrap things up I offer a tiny photo of a partially assembled front landing gear device. One of those thingamagicks is waiting for the first one to be cured and the cable's waiting for something else. Progress is definitely being enjoyed, but slowly.
Hey, I just returned from my vacation early Monday morning, one can't get an insane amount done in this time. Not even I who's sometimes pretty quick, should I feel like it.


3.7.13

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.