Posts tagged game design
Had a major breakoutthrough with Brickbat tonight - finally managed to get the ball bouncing off the bricks in a way I’m 95% happy with! This after 4 separate, failed, versions of the bouncing logic.
Going to bed happy! :D
Before I leap into making one of my more ambitious game ideas (of which I now have SEVERAL) I’m going to do another remake, just to firm up my skills and get to grips with my new programming environment (C# / XNA).
Last time it was a Pong clone, so a Breakout/Arkanoid clone seems a natural progression. Announcing… BRICKBAT!
Progress so far has been good. Over the last couple of weeks I’ve got most of the game engine up and running, along with a rough and ready level editor which has let me knock up 10 reasonably varied levels so I can test that the ball bounces how you’d expect it to (at the moment it doesn’t, so I need to refine my code).
Other stuff still to implement before it hits alpha inludes sound, power-ups and possibly enemies (though they might have to wait till beta).
Will post some screenies later, though be warned it isn’t very pretty at the moment - I’m treating all these graphics as placeholders and a more modern look to the game is on the list for later development.
While my Pong clone was always too rough and ready to inflict on the gaming public, the aim with Brickbat is for a release on Windows Phone 7 later this year.
So, yeah, I’ve not posted anything on here for a while.
Firstly: Onward My Zombie Horde is on an indefinite hiatus. Apologies to the one guy who got excited about it - it’s something I’ll come back to at some point, but I realise now that I was trying to take on too much, too soon.
On the plus side, hitting a roadblock with the AI for OMZH spurred me into a pretty major rethink of my options as a beginner indie dev, which has led to a few changed priorities.
So what have I been up to? Well:
1. For a number of reasons I’ve decided to ditch SFML in favour of something more beginner-friendly and with better options for distributing any finished games. After weighing up my options I went with Microsoft’s XNA Framework, which gives me the potential to create games for Windows, XBLIG and Windows Phone using the same code base. While I was impressed wtih SFML in some ways, it seemed a bit of a cul-de-sac where distribution is concerned.
2. Unfortunately, this choice required that I learned C#. Not an easy thing to commit to having just spent a couple of months getting to grips with C++, but with the help of online tutorials from csharp-station.com it was reasonably painless. For me, it makes more sense as a language than C++ and I like how it’s object-oriented from the ground up.
3. Then I needed to learn the basics of XNA. I’m now just at the stage where I’ve done enough with the tutorials to be able to start working on my own ideas, but rather than start a game straight away I’m trying to put together a few methods for things like sprite animation and 2D tiled maps that I can re-use between projects, making my life a bit easier.
So far I feel like I’ve made the right decision. I’m finding C#/XNA *much* easier to work with, and I’ve also had lots more game ideas that I want to try out.
I’m not sure if I will ever get back to updating this blog as often as I did in the early days, but do I plan to keep it going (perhaps with separate dev blogs for major projects as and when they warrant it).
Not a bad bit of progress tonight. After a few false starts with all the bugs (kind of inevitable given that I left it so long between finishing Pongoloid and starting OMZH), once I’d come up with something that would actually compile I managed to crack on a fair bit. I’m now at the stage of generating 20 human characters, turning one of them at random into a zombie, and drawing them on the screen (using placeholder graphics borrowed from Manning Krull, whose excellent pixel art walking animation tutorial I intend to follow later), and that’s where I’m going to leave it for tonight.
The next stage will be to come up with simple AI behaviour for humans (flee from zombies) and for zombies (shamble towards humans and attack). My plan is that I want to get a basic infection/epidemic model in place first (where being touched by a zombie instantly infects the person who gets touched - eventually this will be replaced by an infection with a short incubation period before zombification), then add in scenery and pathfinding.
My current concept for OMZH is reliant on ever-larger numbers of NPC zombies causing chaos in your wake and facing off against armed human resistance, so getting NPCs to behave roughly how I want them to is my top priority.
Only then will I think about adding in a playable character and starting to actually make it into a game.
So since coding has now finally begun on my new project I feel I can reveal some details of it. Can’t really keep too much secret if I’m going to blog it every step of the way, anyway.
1) This game has zombies in it! 2) Better yet, you play as a zombie! 3) Devour humans or infect them to strengthen your zombie horde - the choice is yours! 4) Old-school 2D gameplay blending action-RPG, arcade, RTS and puzzle elements within a narrative-driven story mode 5) Working title: Onward My Zombie Horde!
It’s going to be a while before this one starts properly taking shape but the groundwork has begun, setting up classes and trying to plan most of the variables needed from the outset.
MUCH more ambitious project than Pongoloid, so who knows when it’ll be finished :)
So, since finishing Pongoloid I’ve not really touched Codeblocks - somehow I couldn’t get worked up enough about the idea I was working on to make a start on it, never a good sign.
This morning, however, I’ve woken up with a real bee in my bonnet about a new game that I’m super-excited to make a start on.
Going to start planning it out properly tonight I think, now that my motivation is back.
1. Pixel art is difficult.
2. I need to learn to draw.
3. In the meantime, I need to do another game that doesn’t involve fancy graphics.
Aaaaaargh. This is doing my head in.
Perhaps unwisely, rather than implementing any more basic stuff just yet I decided to do something a bit more interesting: a function that will “drop” a word or phrase onto the screen one letter at a time, using SFML’s scaling function so that the letters appear to zoom in as if they were falling onto the surface of the screen from in front of it. (If that makes any sense.)
The function, which I’m calling zoomstring, will accept a nine-letter string as input so you can just call it as, e.g.
zoomstring (“GET READY”);
and the phrase “GET READY” will drop into the middle of the screen, letter by letter, and maybe wait a second or two before continuing with the main game loop.
So I worked out everything that zoomstring would have to do (transpose the contents of the string into an array of SFML’s sf::String objects, each holding one letter of the text. Calculate where each letter should be on the screen and how scaled up they need to be, and a loop to gradually scale them down and display them on screen at each iteration.)
Much to my surprise, compiling this produced no errors.
However, when I added a call to the function into my code (just before each new point is played for) a weird thing happened: nothing at all.
Again, my program didn’t give me any errors but the function call might as well not have been there. Everything proceeded exactly as before, with no sign of any text being dropped into the screen. Was it even really being called?
I added an extra line to the start of the function to spit a message out on the console every time zoomstring was called. Sure enough, next time I ran the game my console contained several lines of “calling zoomstring”. But that was the only clue that the function was there. No onscreen text, no errors.
Thoroughly bamboozled, I’m calling it a night.
Wow. Turns out that writing games is every bit as addictive as playing them. It’s gone 3am and I really should have been in bed hours ago, but I’ve been on a roll with my Pong clone and I didn’t want to stop while I was getting so much done.
Tonight I finished all the groundwork that I started yesterday. From there I implemented the basic graphics - flooding the screen with a background colour and drawing two bats and a ball on it. Once I’d done that, it seemed churlish to quit for the night before I’d made the bats move up and down when certain keys are pressed.
Then it would have been almost rude to stop without making the ball move, and once it was moving I needed to make it bounce off the top and bottom of the screen - and, of course, off the bats. And once I’d got that far it was a tiny extra step to make the ball position reset if it went out of play.
Also somewhere in the middle of all this I rewrote large chunks of my code so that, in theory, the graphics could adapt themselves to various different possible screen sizes.
And once all that was done, it was gone 3am and I really should be in bed.
But I retire to bed happy, with the main gameplay of my Pong clone implemented and feeling very pleased with my night’s efforts.
