After adding the basics of the weapons system yesterday, this evening I attempted to add some more polish to the system, including environmental collisions. I started off by adding a new sprite for the player bullets (the one I'd chosen was a little weedy), and then added a routine that allows the player to fire bullets to the left and right (depending on where the mouse pointer is on-screen).
I hit a snag with the bullet generation, and thus a little time was spent reading various articles to work out the source of the issue. Essentially, every time a bullet is fired, an alarm is set; this counts down to zero, during which time another bullet cannot be fired (a simple system to stop bullets being spewed every frame).
The problem with Game Maker's alarms is that unless the alarm is checked by an event, it doesn't function (this seems lame until you consider that it's just the engine being ruthlessly efficient). The solution is pretty simple - just add a code segment that is triggered when the alarm fires, but leave the file blank.
After fixing the alarm issue, I took the next step of adding vertical firing, then rounded off the bullet routines by adding collision states (so that the bullets explode when they hit a wall). The next step was to bring the pieces together and allow the enemies to be taken out by bullets, which was a matter of 30 second's work. I then reaped the rewards of the evening's session as I wandered around the map firing bullets and taking out any enemy that dared get in my way! :)
Interestingly enough, I came up with an idea while roaming the maze and flinging out bullets, and wrapped up the night's session by creating a crate entity; these will litter the levels, and act as either bonus repositories (a la Half Life), or simply allow the player to nudge them around the map to provide useful - if temporary - cover from enemy fire.
Wednesday, February 19, 2014
Tuesday, February 18, 2014
Spawny Twonk...
I had one simple aim for tonight's Game Maker session: make the traps spew out enemies. I started off by importing some temporary sprites for the enemy from the C64 version of Citadel, which also included "appear-from-trap" animations.It's a pretty straightforward process for a trap to generate an instance of an object - the real trick was to organise the enemy code so that the object can have different states (appear, patrol, destroyed, etc.).
Once the little blighter was successfully emerging from the gloom, it was time to add some rudimentary movement code. If you recall, the player in Citadel moves one square at a time, and the same is true of the enemies; thus, I looked for a way to allow the enemies to use the same movement logic as the player (rather than re-invent the wheel - or at least, duplicate wads of code - for every entity in the game). Luckily, Game Maker has a handy script system, which is essentially a function that you can call from anywhere but affects the object which called it.
Simply: say I had a movement script that adjusted the player's X and Y co-ordinates. If I call this from the player object, the player moves. If I call this from the enemy object, the enemy moves. Pretty neat, and a stellar way to modularize code.
In order to test the movement script, I then had to plug in some rudimentary AI - in this case, I made the enemy follow the player left and right (merely to check that the code was working and the enemy didn't try to fly through walls).
Flushed with success, I rounded off the night by starting on a rudimentary weapons system; after all, I'm not teaching the enemies to hunt me down unless I'm armed. :)
Once the little blighter was successfully emerging from the gloom, it was time to add some rudimentary movement code. If you recall, the player in Citadel moves one square at a time, and the same is true of the enemies; thus, I looked for a way to allow the enemies to use the same movement logic as the player (rather than re-invent the wheel - or at least, duplicate wads of code - for every entity in the game). Luckily, Game Maker has a handy script system, which is essentially a function that you can call from anywhere but affects the object which called it.
Simply: say I had a movement script that adjusted the player's X and Y co-ordinates. If I call this from the player object, the player moves. If I call this from the enemy object, the enemy moves. Pretty neat, and a stellar way to modularize code.
In order to test the movement script, I then had to plug in some rudimentary AI - in this case, I made the enemy follow the player left and right (merely to check that the code was working and the enemy didn't try to fly through walls).
Flushed with success, I rounded off the night by starting on a rudimentary weapons system; after all, I'm not teaching the enemies to hunt me down unless I'm armed. :)
Sunday, February 16, 2014
Into the Citadel...
Yesterday I spent an entire morning re-reading my Blog from the last ten years (it's amazing how well I can remember coding sessions from 2006, but can barely remember what I had for lunch yesterday). My motivation was really twofold: firstly, I wanted to try and re-capture some of the drive and enthusiasm I had back then, and secondly, I wanted to re familiarize myself with some of the ideas and concepts I had for Citadel, way back when.
I also took the liberty of going through my Citadel design notepad which I scribbled in religiously during my university years from 2007-2009 (word to budding designers: write every idea down, and make sure you keep them - you never know when you may need to draw from them). It was an interesting read, and of course, it's always rewarding when you manage to impress yourself with an idea you can't even remember having!
Today, faced with a snowstorm outside and not much else in the way of commitments, I decided to sit down and start plugging away on the game. I needed to try a new way of working, and so I just dove in with no real game plan, and no desire to get it right (merely, just get it working). I already had my Mayhem testbed to work from, so I ripped out the collision system and began adding Citadel assets.
One of the first things I like to do is set up a basic shell, so that the game starts with a title screen, which links to the game, and in turn links back to the title screen. It not only makes the project instantly feel more rounded, it also gets you thinking about structure from the outset (there's nothing worse than having to take a pile of demo code that works perfectly, then break it into a million pieces as you try and fit it into a framework later on).
After the basic shell and collision were in and working, I imported sprites for the main player ("Monitor"), a test enemy, and a trap. The player control system was up and running in its most basic form fairly quickly, and within a few minutes I was roaming around the first level of the game looking for things to kill. :)
The next idea was to try and get a simple trap in and working (in Citadel, enemies, pickups, and switches are spawned from traps, which open as they player gets close). A fairly simple idea resulted in me banging my head against a wall for almost an hour trying to get a few simple lines of code to work.
After a shower and a little time to think, I came back to the keyboard and Googled the command in question, and managed to find a really common-sense Wiki which listed common mistakes for each of the Game Maker commands. Needless to say, I was making one of those mistakes, that of my code being called in the wrong event. Twenty seconds later, the code was working and the balance of the universe restored. :)
After lunch, I returned to the game to start refining a few things, including the player control, animation, and collision. In Citadel, the player moves one tile at a time (a quaint idea which gives the gameplay a unique twist), and luckily I had a testbed written in Blitz Max from 2010 that did the job perfectly; thankfully, it was a relatively simple process to translate this code to GMS.
Next came a slight tweak to the collision system. Due to the fact that the player moves on a square-by-square basis, the collision is actually quite simple: in essence, the squares around the player are analyzed before the player moves, so there are no checks to see if the player is colliding when they are moving, just checks before they move to see if the adjacent squares are free.
Once the control and animation were working as intended, I rounded off the day's session by tweaking the trap code so that it opens when the player gets within a certain range. Now the real magic begins: making the traps spew out enemies. :)
I also took the liberty of going through my Citadel design notepad which I scribbled in religiously during my university years from 2007-2009 (word to budding designers: write every idea down, and make sure you keep them - you never know when you may need to draw from them). It was an interesting read, and of course, it's always rewarding when you manage to impress yourself with an idea you can't even remember having!
* * *
Today, faced with a snowstorm outside and not much else in the way of commitments, I decided to sit down and start plugging away on the game. I needed to try a new way of working, and so I just dove in with no real game plan, and no desire to get it right (merely, just get it working). I already had my Mayhem testbed to work from, so I ripped out the collision system and began adding Citadel assets.
One of the first things I like to do is set up a basic shell, so that the game starts with a title screen, which links to the game, and in turn links back to the title screen. It not only makes the project instantly feel more rounded, it also gets you thinking about structure from the outset (there's nothing worse than having to take a pile of demo code that works perfectly, then break it into a million pieces as you try and fit it into a framework later on).
After the basic shell and collision were in and working, I imported sprites for the main player ("Monitor"), a test enemy, and a trap. The player control system was up and running in its most basic form fairly quickly, and within a few minutes I was roaming around the first level of the game looking for things to kill. :)
The next idea was to try and get a simple trap in and working (in Citadel, enemies, pickups, and switches are spawned from traps, which open as they player gets close). A fairly simple idea resulted in me banging my head against a wall for almost an hour trying to get a few simple lines of code to work.
After a shower and a little time to think, I came back to the keyboard and Googled the command in question, and managed to find a really common-sense Wiki which listed common mistakes for each of the Game Maker commands. Needless to say, I was making one of those mistakes, that of my code being called in the wrong event. Twenty seconds later, the code was working and the balance of the universe restored. :)
* * *
After lunch, I returned to the game to start refining a few things, including the player control, animation, and collision. In Citadel, the player moves one tile at a time (a quaint idea which gives the gameplay a unique twist), and luckily I had a testbed written in Blitz Max from 2010 that did the job perfectly; thankfully, it was a relatively simple process to translate this code to GMS.
Next came a slight tweak to the collision system. Due to the fact that the player moves on a square-by-square basis, the collision is actually quite simple: in essence, the squares around the player are analyzed before the player moves, so there are no checks to see if the player is colliding when they are moving, just checks before they move to see if the adjacent squares are free.
Once the control and animation were working as intended, I rounded off the day's session by tweaking the trap code so that it opens when the player gets within a certain range. Now the real magic begins: making the traps spew out enemies. :)
Sunday, February 9, 2014
Back to the Future...
They say that life is what happens when you're making other plans, and that certainly rings true as I sit down to tap in a Blog entry after a hiatus of almost two years; more incredibly, it's almost ten years since I started this Blog back in July 2004, as I searched for a programming language to create a game and satisfy my creative urges.
The programming language was Blitz+, and the project I had in mind was a remake of Martin Walker's seminal Commodore 64 title, Citadel (not to be confused with the BBC microcomputer game of the same name). The search for a decent map/level editor led me to create my own, and thus Citadel took a back seat for two years while I worked on FishEd, a map editing tool of which I am immensely proud.
During that time, of course, new languages came out, including Blitz Max, and thus Citadel was again on hold until I had mastered this new language (during which time, thoughts of re-writing FishEd in Blitz Max once again pulled me away from the process of actually writing the game).
And of course, one needs to throw life into the mix: during those ten years, I got married, moved to Canada, lived and worked on a horse farm, started two new businesses, got divorced, went to university, relocated from the West coast to the East coast of Canada, started a new career in radio/broadcasting, and got married for a second time.
It's no wonder that poor Citadel had to take a back seat for so long.
Fast-forward ten years from 2004, and games development is a generation or two removed from what it was back then; the iPhone was just a germ of an idea; there were no app stores; Steam was a fledgeling platform that nobody thought would grow or survive. Most importantly, if you wanted to make a game, typically you had to learn a language and do things the hard way.
One constant remains, however: I still want to remake Citadel.
* * *
When I recently looked at the array of tools at my disposal, it dawned on me that though the potential was huge, the choice just as overwhelming as it was back in 2004 (this is partly my fault: as soon as I have to choose between two or more things, my brain goes haywire). However, I'd like to think that I've matured and grown since 2004, and thus I arrived at a final decision fairly quickly: Game Maker Studio, which narrowly beat Unity to the finish line.
I won't bore you (too much) with my thought processes, but essentially GMS appealed to me for a number of reasons:
- I can create the game and edit the levels all in one package, giving me more focus.
- I was able to boot it up and get results in minutes; Unity's initial learning curve had me struggling to just load an example project without tearing my hair out.
- It's as simple or as complex as you make it; the in-built actions and events make it easy to rough out game mechanics, which you can later refine by adding code as you learn.
- I can output to a variety of different platforms, including HTML5, Windows, iOS, etc.
Last week, after Game Maker Studio had sat on my hard drive for months, something started nagging me to begin using it, so I stole some hours here and watched some excellent tutorial videos put together by Shaun Spalding (you can find his YouTube page HERE). Today, I spent an hour creating this:
An hour. One hour. Including the time it took to convert the graphics into the correct format. Flushed with this success, I was certain that Game Maker would be the package of choice to put together a remake of Citadel. Finally, after ten years, things seem to be happening.
Subscribe to:
Posts (Atom)
