“Bugger!” it’s official!

Posted on by

I have way too many notes to go over, so this will be my last technical/project-oriented post for a while. Instead I’ll be going back to the short rants about current affairs and game design for a bit :P But for now…

This – is – ALPHA!

As I mentioned last time round, “Bugger!” has been close to its first milestone for quite some time, but I have too much on my plate at the moment to work on it. But having botched my test (despite studying very hard for it) I needed a pick-me-up, and nothing is better than having one’s plans come to fruition. As such I decided to push forward and quickly finish implementing all the features I’ve been working towards for months.

And so, at long last, “Bugger!” is official. Welcome to the Alpha 1:

Don’t pay attention to the art. Nothing, and I mean nothing (no, not even Galosh Gimp) is final. What is important is what’s doing on under the hood: the dynamic draw-order I talked about has been implemented, allowing for objects to move in front of and behind each-other and still draw correctly. I’ve also added Tiles and Tilesets, and have pimped the editing tools to allow them to be placed, loaded and saved.

There’s a whole lot of other stuff here too: you may noticed that in editor-mode Instance hitboxes and the Level‘s path-map are draw (now using a Tileset), but in play-mode they are not. I can toggle this visibility option quite easily to help with debugging. Many other similar under-the-hood features have been implemented too, but it would take too long to talk about them all and -anyway- I’ve forgotten what many of them actually were. I cleaned up the code a bit too, so that when I eventually do release the source it won’t course brain haemorrhaging.

The important features now implements are:

  • memory management for object creation and deletion
  • loading/saving to an external file
  • collision detection
  • tiles and tilesets
  • mobile views with redundant draw-culling
  • sprites animations
  • dynamic draw order
  • level editor
  • frame-rate regulation

So now I’m ready to start working on the actual game! I need to think about my next mile-stone before diving in though, which fits quite well with the sudden demand for course-work…

What’s the actual game about?

I’m glad you asked. “Bugger!” is a top-down shooter. I’m not trying to be overly ambitious and genre-defining when it comes to gameplay (as this is my first “real” game engine), so the game will essentially be about shooter stuff (surprise surprise). Exploration, key-hunting and puzzle-solving are not on the to-do list: the objective is simply to “de-bug” (clear) each “source file” (level). So you’ll spend your time dodging projectiles, avoiding melee attackers and returning fire with a variety of over-the-top weapons.

The enemies and weapons themselves will be bug- and debug-themed. So you’ll fight off Syntax Errors, Floating Point Exceptions and the dreaded Segmentation Fault using Back-traces, Log Files and Break Points, not to mention the GDB9000 (oh, yeah)!

The player will move between levels via a world map based on the game’s UML diagram: each class is a level to debug, and you’ll be able to move along dependencies from one file to the next. This allows the player to choose a different level if they get stuck, and even skip certain levels for a time (though to complete the game they’ll have to clear them all). And that’s all really. I’m keeping it as simple as I can, trying not to get overly ambitious.

Let me know what you think in the comments or, if you’re too shy to post in public, head on over to the newly-created TIGsource thread! You can also check out the game on indieDB if you’re so inclined.

The video was captured -as usual- using ffmpeg and x11grab, but for some reason I’m getting these horizontal bars now that it’s full-screen. The ever-helpful Qubodup reccomends GLC for OpenGL, and SFML is essentially an OpenGL wrapper, so maybe I’ll try that next time. Thoughts?

On the plus side I’ve switched from Pitivi to OpenShot for video editing, and am very pleased with the change. The latter has an almost identical interface, but -conveniently- dumbs-down its output options for noobs like me (I can select “Youtube HD” and “High Quality” rather than having to research codecs and fiddle with bit-rates and samples/s).

I was thus able to edit without losing any quality to speak off – it’s just that the original quality wasn’t so good :S

  • http://qubodup.net qubodup

    I have a lot of trouble with editing the files I record. Either OpenShot (or its libraries) is unstable or the videos I record are or ffmpeg is…

    Pitivi has a nicer fade in/out control (although it only works for audio, not for video for me..)

    My problems might be related to me using ffmpeg-git (I think) or having a 64bit computer.

    • http://wilbefast.com/ Wilbefast

      In truth I prefer Pitivi’s interface, but the output options are a bit too “hardcore” for me. I’m using 64bit without too many problems – what do you mean by “unstable” exactly?

      • http://qubodup.net qubodup

        OpenShot will get A/V desynchronosations all of the time. If I move tracks to the left in the timeline and will stop allowing me to move them any more.

        I don’t remember if I had the same problems with PiTiVi, but there were problems as well.

        Didn’t try editing for a month or more though.

  • Anonymous

    What’s the significance of red and blue hitboxes? I noticed the projectiles flying over some of the terrain. Are those the holes from the early version?

    I liked seeing the AI “notice” where you were.

    In an earlier post you mentioned a goal as being an isometric view. How are you planning to implement that?

    Is it one-hit kill? I don’t think I saw you ever collide with an enemy.

    • http://wilbefast.com/ Wilbefast

      You’re right about the holes: they’ve had a graphics update! There is an invisible pathing array with (so far) three possible values: FLOOR, WALL and HOLE. holes are marked in blue in the editor, walls in red.

      At the moment the enemy can’t actually attack you: they just move within range and sit there. In the interest of making the game look good though I’ve avoided them in the video :-P
      I’d originally planned to make the game crash whenever you touched a bug (hehehe) but I think the novelty would wear off pretty fast. Instead you’ll have a certain amount of health and die if you lose it all (standard procedure really). The next thing I want to do is to add the health-bar and enemy attacks so there’s actually some game involved.

      As for the isometric view: I suppose “isometric” is a misnomer in this case. “Faux 3D” would be a better way to put it: the first screenshot show off the technique used (the dynamic draw order) and hopefully shadows will further “ground” the objects in the world.