A good beginning...

Midterm

Is a halfway a battle won.

So, we have not only survived half the period, but also the supposed end of the world. Not letting some Internet downtime keep us down for long, a bit after we initially planned, we can finally make our midway point blogpost.

We are now halfway our project—or we very well should be—, so let’s have a look on how far we’ve really gotten.

What we have

Bluntly put, we have a working game engine. There is a fully-functioning, driving, shooting (with actual bullets that actually come out and do damage; shock and awe) tank, destructible walls, collision detection and background slash game world. We even included some very rudimentary enemies in the form of disembodied turrets that track the player across the screen and start firing whenever he enters a certain range. The level ends when all enemies are destroyed, after which the game promptly resets (so we still need a game over screen). We have a pause menu with retry, back to menu and exit buttons.

So essentially we have a moderately playable product that is still missing some minor polish in the form of some menus.

What we don't have; or what we're working on; or what we're definitely not doing, ever

We feel the current graphics of the game are still a bit… old-school, however. Whereas we keep the grid structure that we use in our level loading, some members of our team are devising a system that will hopefully give the game a cleaner, more natural look, by literally cutting corners of the background sprites and programming the level loading in such a way that the blocks arrange themselves in a logical manner.

As we were unsatisfied with the way the destructible environment works, one of our members quickly proposed a Worms-esque blast-radius based destruction mechanic. As he had some experience with working with pixel related collision detection (as opposed to the bounding box based kind we use now), he believes it will cost relatively little effort to implement this in the current game.

After cursory research on network support we got the distinct feeling we might not have the experience and time required to make multiplayer happen. And after hearing people with experience lament on the difficulty of networks, that feeling evolved to certainty. We’re dropping online multiplayer.

Instead, we’ll be focussing on our backup plan: enemy AI. An AI that is smart enough to give chase, pursue the main objective and lead a target, with different behavioural patterns for different enemies.

So, in place of a basic multiplayer mode, we’ll be making an extensive single player mode, with different types of enemies, powerups, bosses, environment, etc. The idea will be the same: protect your pudding from the enemy, but the more focussed approach will most likely result in a more polished and enjoyable experience.

Since settling on the name “Pudding Protectors: Idatakimasu!”, we have likewise defined a more definite style. Contrary to our original clean, close to realistic idea, we will be following a more stylised, Japanese and over the top feel.

Concept art for the different enemies and player tanks is full in the works, and ideas for powerups, bosses and levels are bubbling amongst our members. In order to homogenise the art style, we are working hard to make everything look clearer and smoother.

So our plan is as follows: First polish the basics, since you can’t build a strong game on weak foundations. So finish the menus, tighten up the backgrounds, overhaul the environment and tweak the hit and collision detection.

Then—and this is easily said, but probably not quite as easily done—create an AI. First we’ll create a rudimentary one that we can tweak to suit our needs, then we’ll define the different enemy types and implement them with each their own behaviour. We’ve had discussions on how to handle this, and several of our members have definite ideas and plans for the implementation, so hopes and faith are high.

After we are done with that—or at least that we are certain that we are almost finished—and we have idle members, we start programming powerups, which we have already largely defined.

Simultaneously, as not all our assets will be spent on creating the powerups, we create the sprites necessary for the different enemies and player models, so all art is comparable across the game.

Lastly, when the style is set and the entire game is in a playable state and our AI works as desired, and we have a number of levels, we add bosses at the end of the levels. Because this is something we feel will add a lot to our game, but it is hardly required, it is one of the last things we plan to do.

I, for one, would love to play our finished product. Let’s see if we can get there.

An update of sorts

In the grand scheme of things, there are still a number of things we need to do. However, more importantly, there are also a number of things we don’t have to do anymore!

One of these two groups is larger than the other, sadly.

What we have

Let’s focus on the positive at first: we have a tank. And it can move. That’s a solid basis if I ever saw one.

 It has the desired 360 degrees of turning freedom and it can move forwards and backwards. And, though we’re still working on the visual aspect of the product, the threads of the vehicle are animated.

Secondly, we have a gun, and it can move. For now, it is a wonky five-minute placeholder which points at the mouse cursor, but a turret is a turret, regardless of graphical fidelity. Shooting is implemented as well, so once we have bullets, we can shoot them. But I’ll get to that later.

Furthermore, our menus are working. Partly. We have functioning Exit and Single Payer buttons, and it is only a matter of time before we ascend to the heights of Options as well.

What we’re working on

Tiles. Though black is obviously a beautiful colour, which is featured extensively in my wardrobe, it does not make for the most riveting of gameplay. Though the placeholder tiles are made and ready for deployment, there is still exactly that problem. Deployment.

Even as I write this, one of our dedicated team members is still furiously coding to make this work, despite what very well may be food poisoning. We don’t do breaks at Pixel Pudding.

Let me get another cup of tea.

Where was I? Oh yes.

As I mentioned before, one of our issues is still the bullets. Not a big deal, obviously, but not something that we’ve tackled yet. It could be the case that Pixel Pudding is comprised of subconscious pacifists, who put off the addition of violence to the last possible moment. Or perhaps we just forgot and we’ll do it tomorrow. I’m sure there is a valid excuse. I mean, I’ve had a pretty eventful week myself, filled with food, family, art and love, among other things, so I can easily imagine the others were preoccupied as well.

This is something that needs to be done, however. Tanks and bullets are kind of a thing.

There is still the small matter of design, enemy and player types and art in general. Though this is part of game design, it is a necessary part of gameplay, and we want to make the game feel right. So, with three creative minds doodling away during daydreams, lectures and train trips, we are slowly designing different types of tanks. For now, the emphasis definitely lies on slowly.

What we don’t have

And then there are the things we haven’t yet touched with a ten-foot pole.

And they’re big ones.

Firstly, multiplayer. Obviously, you need something that actually functions  before you can expand it, so without even a moving tank, we could hardly start working on something as complicated as network support. We have, however, taken time to research this subject, and we’ve come to the conclusion we’ll probably need to do a bit more research. Once we have actual bullets, and levels, we’ll see where we can fit this in our schedule.

Then, AI. There has already been talk on this. Our original plan was to include a multiplayer with AI that could take over players whenever they would, inevitably, drop connectivity.

We may not actually do this.

We’ll try (gods, we’ll try), but it is not as high on our priority lists anymore.

There is still the singleplayer, but again, a functioning multiplayer is more impressive than a functioning singleplayer, so again, there’s some prioritising going on here that may not be good news for AI. The singleplayer AI probably is more basic than the multiplayer, as the multiplayer is objective-based and calls for a certain level of reactive actions, whereas the singleplayer mostly involves shooting at the nearest target.

It’s a difference in nuance.

There also is still a bunch of things we haven’t had the time to do yet, such as a moving camera, the conception of a statue unit, the programming of the different tiles, etc. but those are relatively minor things, that will pop up naturally over the course of our experience and will most likely be largely busy-work, that will take time, but little effort. As opposed to the Herculean task that is comprehending network support.

We may have a candidate for our first ticket.