BAD ARCHAEOLOGIST - Developer Diary
StuartY
Member Posts: 134
I've been inspired by Photics and Uptimistik to start keeping a developer diary. It seems like a good way to stave off being in a "design bubble", providing a chance to get feedback and device from other GSers. Most importantly, I hope it will give me the motivation to "finish the fight" and keep going through the work ahead.
So, I would like to proudly introduce my new game: BANDWAGON JUMPER!
Just kidding, it's called BAD ARCHAEOLOGIST - at least that's the working title.
So what is it actually about? Well, in Bad Archaeologist, you're working for Baron von Smashenhof, an unscrupulous relic hunter who makes Indy and Lara look like gentle custodians of the ancient world. Using a bunch of "archaeological" tools - all the way from the humble trowel through dynamite up to the Baron's personal Lead Zeppellin - you smash through ruins looking for treasure with gleeful abandon.
In gameplay terms, it's an attempt to fuse the "controlled demolition" physics puzzler - the kind where you have to break stuff down with set resources (see Angry Birds, GS's very own Zombie Drop) - with the sort of item finding and riddle solving seen in the point + click and hidden object genres.
I've decided to begin this a little while after I've started work on the game - I wanted to build a test level to make sure it was feasible and that the basic mechanics were fun before I announced it to the world. Well, the good news is, it is. I've done a lot of groundwork for the basic "engine" of the game - stuff like the Hud automatically spawns, and I've implemented a system for "loading" the dozens of attributes required for each level after the last is finished. Hopefully, with this in place I can begin to do more of the fun stuff - actually coming up with devious levels for players to enjoy.
My job today; polish the tutorial level until it shines.
So, I would like to proudly introduce my new game: BANDWAGON JUMPER!
Just kidding, it's called BAD ARCHAEOLOGIST - at least that's the working title.
So what is it actually about? Well, in Bad Archaeologist, you're working for Baron von Smashenhof, an unscrupulous relic hunter who makes Indy and Lara look like gentle custodians of the ancient world. Using a bunch of "archaeological" tools - all the way from the humble trowel through dynamite up to the Baron's personal Lead Zeppellin - you smash through ruins looking for treasure with gleeful abandon.
In gameplay terms, it's an attempt to fuse the "controlled demolition" physics puzzler - the kind where you have to break stuff down with set resources (see Angry Birds, GS's very own Zombie Drop) - with the sort of item finding and riddle solving seen in the point + click and hidden object genres.
I've decided to begin this a little while after I've started work on the game - I wanted to build a test level to make sure it was feasible and that the basic mechanics were fun before I announced it to the world. Well, the good news is, it is. I've done a lot of groundwork for the basic "engine" of the game - stuff like the Hud automatically spawns, and I've implemented a system for "loading" the dozens of attributes required for each level after the last is finished. Hopefully, with this in place I can begin to do more of the fun stuff - actually coming up with devious levels for players to enjoy.
My job today; polish the tutorial level until it shines.
Comments
So today was all about trying to polish my tutorial level. At the end of the process, It feels like my game has gone from being a proof-of-concept tech demo to actually looking like a game I might want to play. Mainly, it's been about adding background detail to the rather plain game environment.
But what really brought it alive was the animation. I think animation makes a place - even a cartoon, stylised environment like the version of Greece in Bad Archaeologist - feel like a tangible space.
I started with the clouds. To create variety and spontaneity with just a couple of graphics, I created a cloud actor that randomly selects it's image, speed, opacity, size and position. That way every time the game is played, the appearance and movement of the clouds is different.
Next, I revisited my sun. Initially, I went with the sun used on the greek macedonian flag to give the level a mediterranean feel. It had been bugging me for a while, because it somehow always looked too slender and wimpy to be a bright, grecian sun lighting up the environment. So I ripped it out and designed a more wholesome model. Finally, I set it to rotate slowly. I don't know why, but this looks great.
I added a few hills, including a paler, bluer layer to give the impression of depth.
This all looked nice, but it was still missing a spark. It was a bit sterile. I started to think about a couple of recent posts on the forum - what Uptimistik had said about trying to anthropomorphise his game:
http://gamesalad.com/forums/topic.php?id=24331
and what Fire Maple Games had said:
http://gamesalad.com/forums/topic.php?id=24307
about creating an emotional tie to a game. Well, my game does have a pretty good human face in the belligerent form of the Baron. The problem is he doesn't pop up until the end of each level. So the majority of the time there's no faces on screen. So what would fit in with a cod-greek landscape?
The missing part of the puzzle: A humble goat. It's only a dopey-looking cartoon goat that a non-artist threw together in Inkscape, but with some decent animations he did the trick, and finally made the level feel alive.
Of course, none of this is important to the gameplay at all. But I think it's the little details that will turn this game into a quality product.
After all my hard work, I think the game looks ready to post a few screens. Enjoy!
The usual dev complaint applies: I wish I could show you this in motion.
There's one little detail that's still bugging me about my test level. You see the picture of the baron above this post? His head and thumb rock back and forth in a jaunty end-of-level celebration.
I set this up with three behaviours:
1) Change self.angle to 15
2) Rule: when self.angle = 15, interpolate self.angle to -15
3: Rule: when self.angle = -15, interpolate self.angle to 15
Now, normally it works fine, and he rocks back and forth a bit like a nodding dog. But sometimes either the head, or hand, or both, will just stop, and I've no idea why. Anyone know why this is happening, or what I can do to prevent it?
Cheers,
Stuart
Try
1) Change self.angle to 15
2) Rule: when self.angle >= 15, interpolate self.angle to -15
3: Rule: when self.angle <= -15, interpolate self.angle to 15
CHeers kipper
P.S. Love the project idea and look forward to a second destruction of Pompeii
Today I got the dynamite working in my game. This will also give the framework for my other explosive tools, so it was important to get it right. A lot of it involved simply following and tweaking Tshirt Booth's excellent blast tutorial;
The hardest part, however, was something that I expected to be very simple indeed; getting a particle effect to spray sparks from the dynamite's fuse. The problem is that the stick of dynamite spins through the air, but GS's particle emitter does not feature a "rotation dependent" setting - so the x and y offset remains static while the stick spins - which obviously means that the sparks don't come from anywhere near the fuse.
The solution is unfortunately maths. In the x+y offfset, I used these expressions:
x: cos(self.rotation)*16
y: sin(self.rotation)*16
This describes a circle, dependent on the angle of rotation, with a radius of 16.
Because the end of the fuse wasn't exactly at the top of my 10*32 actor, I had to put in a few angle tweaks, so the formula that works looks like:
x: cos(self.rotation+80)*16
y: sin(self.rotation+76)*16
Anyway, I'd recommend anyone who has a similar problem to try variations on these formulas to get particles and rotation working together. Until GS adds an "account for rotation" button that is!
This might also be useful information to you...
http://gamesalad.com/forums/topic.php?id=24445
Basically, don't wait for GameSalad to add features when you can work around the problem with math.
There isn't much exciting to report today; just working on building up some fun levels. In the early stages of the game, you're dealing with just the one tool (trowel) so it's a challenge to keep those opening levels different from one another in terms of feel and challenge. One of the biggest obstacles to worry about is designing structures that are sturdy, but not too sturdy, so the player has a challenge. I've often found "emergent" gameplay - I start off with one level idea, the physics I imagined don't work out but ways to solve the level still turn up naturally.
I'm not sure how many levels to build. My original target was sixty, but I may add more if these end up being quite short. Beta testing will be important in this game, I want to make sure everything a) feels fair and b) the difficulty curve is smooth. I'm aware that something I believe to be a simple challenge might be more difficult the first time it's experienced.
I've not been updating this diary for a few days because - there's nothing to update. I'm on holiday, and although I'm enjoying it, I can't really relax wanting to get back to BA. Still gives me some good thinking time though!
Well, I'm back and working on it again. Today I set myself the target of getting two levels finished and polished, but I got side-tracked, not necessarily in a bad way. Instead, I ended up tweaking and trimming features. For example, I quickly noticed that with smaller targets, gamesalad's detection of touches is not exactly pixel perfect or that responsive to very light taps. So I implemented some cheats. Firstly, the hitbox of the treasure/coin actors is deliberately larger than the graphics, so it's a bit more forgiving than it might be. Further, I've implemented a small cursor that jumps to your last touch. This is normally seen as a redundancy in touch-screen games, but I think it's very useful in this case, because the player can see whether they actually hit the target they wanted or whether their big clumsy thumb managed to miss it completely.
Other than that, I've just been polishing a level. It's interesting to see how testing leads to different solutions. I've found two valid ways to beat this level. One of them was unplanned but I decided to encourage players to discover it by hiding a few bonus coins that can only be found using that route. I wonder if players will find even better ways of beating it?
Sometimes you work really hard and have a good day. Yesterday was one of those days - I managed to get four levels done.
Other times, you work really hard all day and seem to achieve squat. Today I managed to polish a level, implement "red herring" artifacts working (i.e. a time penalty and visual indicator for selecting the wrong item) and started on the pause menu.
That's it. While I'm sure all of these things will turn out to be important, it doesn't really feel like I've improved the game at all. It would certainly be hard for someone sitting down and playing my handful of levels through to tell the difference.
Oh well, back to getting the volume sliders working...
After a day yesterday where I felt like I worked hard but achieved little apparent progress, I was heartened to have a day of greater-than-average productivity.
Firstly, I got the pause menu and all it's animation polished, with buttons to return the player to the main menu, to skip the level, or resume. I also implemented some sliders for volume and sound effects, modified versions of the kind featured in tenrdrmer's pause demo.
After that, I fixed up some minor bugs / glitches. One of the annoying things about making a physics game in gamesalad is that if you have sound effects for collisions, they will all fire at the start of the level as your blocks "settle down". This sounds dreadful, and so far the best solution I could find is to set the sound effects volume to zero and move it to one a second into the level. If anyone's got a better way of doing this, I'd be interested to hear it.
Finally, I created a couple of cool tools (think weapons, but there's no combat) for the game. I want to keep a steady drip-feed of interesting tool types as the player progresses. Already, there's the basic but useful trowel, and dynamite, which is the standard "blast" tool. Today I implemented nitroglycerin and the pneumatic drill. Nitroglycerin is basically a souped up version of dynamite, which destroys the blocks in a small radius as well as knocking them around. The pneumatic drill drops down from above, stays on screen for about three seconds and drills through as many blocks as it hits. Needless to say, realism isn't my priority in this game!
Both are a lot of fun, but could be overpowered if the player is given them too often. Most levels won't see more than one of these powerful tools.
I've finished the final four tools in the game, which is a big landmark for me. In addition to the trowel, dynamite, nitroglycerin, and drill, there's also TNT (similar to dynamite, but can be placed under structures), the time-bomb (does what it says on the tin) and two extra tools which I'm going to keep under my hat. The last is ridiculously overpowered, and will be a "special treat" to break up the more difficult levels. It also looks very cool when it's used. To enhance the spectacle, I also added in a camera shake effect, and was so pleased with the result I also implemented it on a smaller scale for standard explosions.
Completing the tools also allows me to grasp exactly how long loading in the game will take. The first level takes way too long to load - in the final build, I'll pare that one down so it's only loading what it needs, and gradually load in new tools/scenery with each level. Once that first one's in, the rest are more tolerable.
I've also got an in-built solution to relieve the tediousness of levels loading - at the end of each level, the Baron dishes out a little quote. It's normally a mean-sprited insult about the player, or a callous comment about just how dastardly he is. This - I think -normally takes about as long to read as the next level does to load. I'll have to check this when beta testing to find out if people would prefer a little more time to read the quips.
Now, finally, I think I can really concentrate on creating some more levels for this damn thing. Still to do before I can think about a Beta: Menu/Save system. Graphics for the two other "worlds". Replace placeholder sound-effects. Source music. Check for redundant rules. Lots of levels! Think about how to provide tutorial.
There's a lot to wrestle with, but I feel like it's all downhill from here. In a good way.
I just realised that I haven't updated this diary in a while. Well, things are progressing smoothly but not stuff that makes for particularly enthralling updates. Today, I cranked out five levels in about half a day's work, which was pretty decent progress. I'm finding that puzzles and solutions sort of organically come together - I just have to make an interesting looking structure and give the player just enough tools to be able to break it down after a few attempts. The thing that's taking the most time is creating art. Each level is full of glittering new treasures to collect, and although I can recycle some of them in different ways, I still have to draw a lot of pictures to keep it fresh and interesting for the player. Statues, decorated plates, coins, gemstones, urns and painted tiles are just some of the loot - and I've not even finished the Grecian area yet.
As well as the good news, I've been rather worried today by the tendency of GS to crash on previewing a level, which seems to be a "new feature" in 0.95. I save often though, and have only lost a few minutes work this way. Anyone else been encountering this, or is it just my weird game?
Hi again guys! I haven't posted here for a while, because I've really been keeping my head down and working on the game. I recently passed a big milestone - the 20 levels in my first area are now finished. I've also made healthy headway into Area 2, Ancient Egypt.
Anyway, a picture is worth a thousand words, allegedly, so rather than me blabbing about it, here are some new shots.
http://www.flickr.com/photos/63489541@N04/5900383987/
http://www.flickr.com/photos/63489541@N04/5900950182/
On that note, can anyone help me out with a little glitch? Notice the black vertical lines in between the ground textures - anyone have any idea why they are there? The thing is set to tile, so it ought to tesselate perfectly. The bitmap used is 14*24 pixels at 72dpi.
Cheers,
Stu