|You don't have any items in your cart|
|Subtotal (ex. VAT)|
As game developers, it's very easy for us to take things like the user interface and HUD (heads-up-display) design for granted. I mean, how hard can it be to make a couple of buttons and a healthbar? As it turns out it's not very hard at all... With the GUI layer and a couple of objects you can quickly throw together menu elements and HUD elements in GameMaker: Studio, but the difficulty comes in making them user friendly, unobtrusive and consistent. The UI (user Interface) for Skein went through various iterations before I finally felt that I got this right, and in this weeks article we'll talk about the reasons behind the final designs and the problems with the ones I had initially.
My first UI for Skein consisted of some rather garish gold filigree-style menus and HUD elements. I chose this style for one simple reason - I'd made a logo that used it and the logo integrated the play/start button, meaning that it was also a part of the UI. Naturally this made me feel that I should use the same style for all my UI elements.
At the end of last weeks diary, I said that I was going to talk about how I designed and coded the UI for Skein, but I'm afraid to say I lied... I'll leave that for next week, as this week I think it would be a good idea to take a moment to talk about the tools that I use to make my games, since I constantly see questions from people asking what is the “best” art program, or where can they source sound effects, etc...
The other day someone commented to me that they were a “bit disappointed” that I'd used licensed sprites in my game instead of making them myself. Now, this actually made me feel a little bad as in all honesty the sprites I've licensed only make up about 20% of the final graphic package, and even then they form a base that I have then adapted and animated and built on. Why do I mention this? Well, it's because licensing art or using free resources is a valid direction to take when you are deving a game, especially when you either don't have the skill or the time or the budget to make them yourself or get an artist. In my case, it's a bit of all three! Here are the main complaints in my opinion about using free/licenced art:
Now that I was starting to get some structure and progression into the game, I felt that it was time to elaborate a bit more on the enemy AI and the differences between enemy types. Currently I had about 8 or 9 test sprites in the game for different looking enemies, but they all used the same basic FSM (see here for how I went about that) and all had the same hitpoints and abilities. This lack of any differentiation contributed to the feeling of sameness that I'd been having while play testing, and so it was important to improve upon what I had, especially now that I was beginning to add structure to my game.
Improving things, however, meant planning, and so far I hadn't really given too much thought to the enemies in the game. Sure I knew I wanted them to be dumb and I'd written a basic FSM for them to use, but all games, no matter what style or genre, need the player to feel like they are progressing, that they're getting somewhere, otherwise boredom sets in. This also ties in with another thing I wanted to implement in the game, namely a bestiary. People like to collect things too, which is why games like Pokemon and Diablo are so good! They arouse our hoarding instinct and make us want to play just one more game to see what new creature or loot we can find. In my game I wanted to try to capture that feeling as best I could within the style of gameplay - and one of the ways I came up with was to make a bestiary that starts off empty and slowly fills up with every new enemy encounter. Before that though, I had to make the enemies different enough to warrant a page in that book, which meant looking carefully at what I had and starting to think ahead...
With my mid-game crisis more or less over (see last week!), it was time to get my hands dirty again and start digging into the core code to expand on the gameplay for Skein. All I had at that moment were a bunch of test rooms which ran the same scripts and generated pretty much the same gameplay experience, just with slightly different graphics, so my first real task would be to organise this into something a bit more progressive and distinct...
I knew right from the start that I didn't want my game to be a simple succession of rooms all based on the same maze algorithm, so I had to decide what kind of rooms I wanted and then modify my BSP code to create them. The structure I came up with was something like this:
After adding in lights to the game, I set about expanding and developing a bit more the enemies and magic/inventory for the player. I also set about creating a proper HUD to show the controls on devices as well as the player information - health, gold, the current level and whether they had a key or not (I had also made it so that certain levels are "lockable" and require a key to leave, hence the space for a key in the HUD). I'll talk a bit more about these additions in next weeks blog, but this week I want to talk about a small crisis I had while working on these things...
I had what I felt was a pretty solid start to my game. Lighting worked well, enemies did what I wanted, the basics for the magic system were in place and my dungeon generation was awesome... so why wasn't I happy?
At the time I started to make my action RPG game, the GameMaker: Marketplace had more or less just opened and it was getting some pretty interesting stuff thrown up. In particluar there were a few lighting engines on there that use shaders to create dynamic lights and shadows from instances or tiles, and these interested me greatly as good 2D lighting in GameMaker has long been a "holy grail". So, I dug into my PayPal account and downloaded two of the best looking ones to test with my project...
To tell the truth, I was pretty excited by this, as I remember old GM users like GearGOD or Adventus creating super complex lighting engines in GM6 which looked absolutely gorgeous but were complex as hell:
At the end of last weeks diary, I was just getting to grips with the player movement and some basic controls, and I'd decided to use a grid-based approach to collisions. With that working it was time to move on and start breathing some life into the enemies in the game, which meant that I was going to have to start working on one of may favourite parts of developing a game... the AI.
When I start to code the AI for a new game, I generally don't ever rely on previously made frameworks or scripts from other games. I've found that each game requires a unique solution and that if you want it to work correctly and do what you require, then the only way to go is to build it from scratch. That doesn't mean to say I don't look over the rather large number AI demos and scripts I have lying around as they provide a valuable resource for ideas and techniques as well as fast-prototyping, but I generally start from zero and just take snippets that are appropriate (you can find a load of my old GM7/8 AI stuff - as well as other tech demos - from here if you're interested, but beware! It's all quite old and probably a mess...)
With the basic design of my HUD finished, and the core dungeon generation code working well, it was time to move on and get stuck into the core gameplay mechanics. This would have to start with the player, as the decisions I took about how the player moves and how it reacts to the environment would later shape other gameplay features like the enemy AI, or item placing, etc... So, it was finally time to add a player object to the game world!
Moving from Stable 1.4.1474 to 1.4.1567
We will shortly be updating the version we have set to the Stable channel to be the recent 1.4.1567 release currently live on the Beta channel, and there have been an awful lot of changes and improvements made in the last run of Betas since 1.4.1474, so I thought I’d take you through some of the key things to be aware of as you upgrade to the new release.
In the last blog, I explained how I created the walls and doors of my dungeon, as well as how I added in some initial graphics to see how it all works together. The results were better than I could have hoped for, especially after I added in some optimisation, but having a nice looking dungeon isn't really much fun if the player can't see it properly, so in this weeks tech blog I'll be talking about the decisions I took for setting the view size and aspect ratio as well as the GUI layer.
At this point in the project I had to start to take some hard decisions, namely:
For some time we've had requests to make some of the graphics pipeline more visible, so that developers can get things like the order of texture page usage, the size of vertex batches and even helping to debug shaders. The reason we've never bothered with these, is because theres already a tool that does this for you, and gives you more than we ever could - PIX.
Pix is a little temperamental to start up however, so I'll give a little walkthrough on using it with a GameMaker: Studio project. We'll use the Angry Cats Space demo for this so let's fire up Studio, select the Demos tab, open up the Intermediate folder, and select Angry_Cats_Space.
After creating the base of my new game engine (see last weeks tech blog on procedural generation), it was time to start to bring the game world to life. This meant taking the data I had generated for my dungeon and turning it into instances in a room so that the player actually had something to interact with. So, in this weeks diary, I'll be explaining how I went about this, as well as talking about some of the challenges I faced and the techniques I used for optimising things.
At this point in development I had my dungeon generator creating a DS grid, the cells of which were being flagged with different values that I'd assigned to macros - currently g_wall (0), g_empty (-4), g_door (1) and g_corridor (2) (using macros in this way helps keep "magic numbers" out the code base and makes the code clearer to read, so don't forget to use them!). This setup meant that all I really have to do is a couple of "for" loops to go through the grid a cell at a time checking it's grid value and then creating an instance relative to the grid position that's been flagged.
In last weeks tech blog I went into some detail about the creative process behind making a game, and came to the conclusion that I wanted to make an action rogue-like (ARPG) in the style of the classic Gauntlet. So, I have my design brief with a list of things that I want to achieve and at the top of the list is the procedural creation of dungeons for our player to explore...
When it comes to generating procedural content, there are a few problems to overcome and some hard decisions to make, but the main one is how to produce the content! Since I'd never really done procedural generation of any type in my games, I obviously had to research the subject a bit, and my first port of call was downloading the Spelunky source. Spelunky is the great grand-daddy of procedural GM games, and one of the most well known aspects of it is the way it creates a random room for the player from some pretty simple rules... so I wanted to check it out and decide if this was something I could implement for myself.
This weeks tech blog continues on in the spirit of the previous ones that Mike Dailly has written, only instead of taking a look at the development of an emulator, we're going to be taking a look at creating an actual game from start to finish. The game in question is one that I have been wanting to make for quite some time and is in fact a return to my roots using GameMaker...
The idea for my game comes straight from my youth - Gauntlet and Gauntlet II. I loved those games! I loved them so much, that the first thing I ever made with GameMaker was a Gauntlet clone (hey, we've all cloned our favourite games, right? Best way to learn...). I've progressed quite a bit since I made my Gauntlet fan-game, and now tend to make smaller, mobile-friendly games that are on a less epic scale, but that game still holds a special place for me. To be honest, I've been wanting to revisit the idea for a while now, especially as GameMaker: Studio has better performance than the GM7 that I used to make my own fan-version... meaning more of everything. More effects, more gameplay and more enemies! So, that was decided then... I was going to make a game inspired by Gauntlet!
So if you followed my last emulator series, you'll know that I built up a lot of caches of shapes (characters and sprites) on demand, and then drew them when required. This works great for old consoles, and computers with character map screens, because on the whole, games tend not to change character set images very often, just the actual character map screen, which referenced these images. Because these kinds of machines have pretty good hardware support, they don't have to resort to shifting bitmaps around, there are much easier ways of doing things.
On a ZX Spectrum however, we have a single bitmap screen, with no hardware support at all. This means as soon as a game scrolls, the whole screen changes, and you'd have to refresh the entire cache. Sure, there would be lots of games that worked just great - Manic Miner, Monty on the Run - single screen platformers for the most part, but nothing that scrolled.