Spacecrash day 3 of 7: gameplay revamped
After we started to get some gameplay yesterday, let me take a bit of time and recap where we are. During the project, you have to focus and often need to work as fast as possible, but it’s important to raise your head every so often and make sure you know where you are and where you’re heading.
We are starting some gameplay out of the prototype in the current stage. It is sometimes genuinely fun to fly the ship manoeuvring between the rocks. The variety is low, but still it’s proven a bit of a challenge requiring me many attempts to reach the end of this level as posted yesterday: the end of the level is defined by the constant #define RACE_END 100000.f at the top, since each screen is 1500 units high, this means you need to fly 66 screenfuls without dying to complete it.
There are a few gameplay elements that are sure to add to the experience, at least in variety: my idea is to allow the ship to self-repair slowly by spending fuel, and I also want to add shooting rocket, extra clumps of fuel you can pick up, and also the possibility to slow down / accelerate at your own will. Apart from these gameplay elements, there are quite a few things I’m planning to add only for it to look, play and sound cool: sound effects, particle effects, nice background graphics, animations…
But let us not lose focus. All the elements above (both gameplay elements & all special effects) will not “fix” the core experience. That is something that is essential to the core gameplay. And there are some “gotchas” with the current model.The main limitation in the current gameplay is that the totally “random” distribution of rocks creates a very uncontrolled experience. You can fly for quite a while without encountering more than random easy-to-avoid rocks, and suddenly, you can stumble into a barrier formed by several rocks which there literally isn’t any way to avoid. This is tremendously frustrating, and it totally kills the player experience. The player wants to think that this is about their skills, and it’s very important for them to know that, when they fail, it was because of a mistake of them, and that they could fix it next time.
Don’t get me wrong, luck can play a role, even an important one. I have been playing plenty of Candy Crush Saga myself lately… and you can bet I think is more about luck than about anything else… but still tremendously addictive. But the point is that in CCS you still have some doubt about whether luck was the cause or not, and you can at least always play, even if you don’t beat the level! In Spacecrash, when you confront the player with a barrier of rocks without a single gap, they just feel insulted.
How can we address this? I can think of three different ways:
- Fully scripting the levels, with every rock hand-placed. This is just classic “level-design”, it would allow us the maximum level of control, and would certainly allow us to make the best game. Unfortunately we only have one week, and thus this solution is beyond our scope.
- Structuring the randomness a bit. It’s ok that it’s random, but we should be able to break the level in arbitrary sections, and manually adjust some parameters to it. We can call this “poor man’s level design”, since we will design things by hand, but only partially, adjusting several parameters. This would allow to control the “pace” of the levels, although it still wouldn’t let us fix the issue of creating “impassable barriers”.
- Adding some clever logic to the random rock generation, such that no “impassable barriers” are generated. This seems quite promising. We have to be careful not to fall in an “algorithmic black hole”: it is very common to get into trying to write some ultra-sophisticated algorithm and spend countless hours in it, without making any advance du to too much faith in algorithms. We will try to find some simple approach that works (and we can always make it more complex afterwards).
It seems to me that combining the second and third solutions makes the most sense for this project. Actually, if the “clever logic” is actually a generative algorithm (generating obstacles that can always be avoided), it will be easy to script its parameters to control the pace of each level.
One other important point I thought about yesterday was playing is that we may make the rocks not so “deadly”: make them just slow you down, and have mines that are actually deadly. This makes sense, since it will allow us to have both types of gameplay, and provide some progression between the levels. My original idea was to have three levels in total, with different graphics and growing levels of difficulty. I’ve changed my mind: completing a level is a big reward for the player, so it’s better to have more progression stages and give them important rewards more often. Thus, my current idea is to make 9 levels, three levels each in each of the main three worlds with different graphics. I will also try to come up with some gameplay elements to add variety to the levels – although even just increasing the minimum/maximum cruise speed of the ship in each level will probably provide enough difficulty increase to make it noticeably different to play.
Just to share my outlook from where I am now, I am thinking we can probably add other types of obstacles beyond rocks and mines, possibly with some simple behavior, which would provide some variety. Browsing the Tyrian graphics sure provides some inspiring ideas quite easily: rotating bladed shurikens, robotic probes, daemon-like creatures, etc… having one or two new elements in each of the three “worlds” seems sufficient for a varied gameplay experience.
I would also love to have an end-of-world boss on each, but I’m unsure I can pull that off in the week. We’ll see!
One other note: yesterday night I took a little time and added three important gameplay elements: fuel blobs that you can pick up, shooting rockets with the spacebar, and accelerating/slowing down with UP/DOWN. I think it’s a grand total of 20 lines of code to implement that. It only goes to show how simple some things are… ah, and by the way, I also increased the manoeuvrability of the ship by increasing SHIP_MAX_TILT from 1.0 to 2.0. Together with the ability to “slow down”, it allowed me to complete the level today! I still have to think how the accelerate/slow-down option affects things. Going slower is clearly easier, so there has to be some reward to going fast. Maybe a time limit for a level, or extra score for completing it faster? We’ll see.
Plan for the day
So before getting started, here is my plan for today:
Part 1: Gameplay control
– Implement controlled obstacle generation to obtain controlled gameplay
– Implement rocks and mines causing low/high damage
– Get to a reasonable level progression with the above: controlled and growing difficulty, but always doable
Part 2: “Special effects”
– Particle effects
– Fonts for text messages
I’m not sure I can do everything today, but let’s try it. Tomorrow I will have to finalize the level structure (the 9 levels with their graphics and gameplay parameters), and after that we will be off to finish production (menus, installer, etc…) and of course we will keep playtesting and tweaking gameplay things and effects until the very last minute.
Starting to control gameplay…
I’ve been playing quite a bit to try and understand the experience. I’ve realized that what controls the difficulty is how easy it is to find a gap in the upcoming rocks and fly to it. So, even if the algorithm has to generate rocks, it has to focus on the gaps. This also provides a great way to adjust the algorithm to generate challenges of different difficulty: more and wider gaps for easy difficulty, fewer and narrower gaps for more challenging situations.
Let me share a first stab at controlling the content generation. This is not ready, but in the name of showing intermediate steps, here you have a new version. It incorporates floating fuel clumps and you can shoot rockets with the spacebar (both are non-functional). You can also accelerate and slow down. You need new graphics too (download here: http://jonbho.net/wp-content/uploads/2013/08/sc-gfx-3.zip).
Here is the “somewhat-controlled” content-generation code from game.cpp:
Things worth mentioning in the code:
- The content-generation smarts are in GenNextElements(), it’s called every time around the loop, but it only generates stuff when we are close enough to wherever we decided the next piece of content should be.
- Debug logging: I have added a #define for LOG that can ‘printf’ some information (helpful when debugging). The way I have done it, if I change the #define to the one commented out (without any body), it will just be as removing the logging statements.
- Also, I’ve made it always generate the same type of rock, until I adjust the collision boundaries, this will be the best way to have it working correctly.
You can see how now the content generation has more “structure”, the level is made up of a succession of challenges. Still, the challenges need work, since they are not always beatable yet, and they are not all that interesting. Anyway, going to post this and will come back later with something better.
(… a few hours later …)
Controlled gameplay generation
I think I’ve found what I was looking for. It was obvious in retrospect, as so many things often are. The trick is the following: since you always want to provide a path for the player to follow, you should just explicitly calculate it, and make sure that no obstacles obscure it! That way, you always allow the player to find a way, and you can also control difficulty with the maximum turn allowed in the path, the width around it you ensure remains clear, etc…
I have added the following functional game elements too: “juice” blobs that provide fuel, mines, drones (still passive), and I made rockets functional too. Now the level is very easy to overcome, but I think I now have all the elements necessary to control the difficulty and construct an interesting difficulty progression over the game levels.
No more gameplay work for today, but before I get working in special effects, here is the code in its current fashion for you to see (you need new resources with the drone & mine graphics: sc-gfx-4.zip):
And here is how it looks now:
Spacecrash: Day 3 of 7 (mid-day) from Jon Beltran de Heredia on Vimeo.
As you see, quite a lot more functionality, with low quality looks. After this, I am off to work in in sound and graphics effects. Will post again later.
Some sound and particle effects
After investing some time, I have to say that I’ve blown the budget here. I expected to have nice sounds and particle effects by the end of today, and couldn’t do it. I have added a minimal sound engine based on OpenAL, and also some particle systems code. But I will need quite a bit more time to tweak these.
It’s still good to have these though, most of the core work for these areas is done now. Here are the remaining points:
- Good sound selection
- Particle effects properly calibrated, possibly working in screen space rather than world space
- Lots of particle systems have to be created & configured for explosions, etc…
We’ll get there in time. I don’t want to miss the whole schedule, so I’ll keep the global schedule and work on these remaining points on the side. Friday and Saturday’s work should allow plenty of time on the side (hopefully!).
To see the current version, first download the new data including sounds (sc-data-5.zip). And then you will need new code. I’ve added stuff to the core module, and corrected a couple of things, so here it is again:
And here are the highlights from core.cpp:
As you can see, I corrected a few typos in core.h, added a new function to get the underlying OpenGL texture for a texture-manager index, and I added an OpenAL-based sound engine in less than 200 lines of code.
And finally, here are the highlights from the new game module, which includes sounds and particle effects:
To summarize the changes above:
- I added a better system to handle texture loading (based on enums and an array describing what textures to load), and converted all game code to use those enums (TexId).
- I added a small sound manager too to load sound files, and added relevant calls in the game logic to trigger sounds (and adjust the pitch of the engine sound for the main ship)
- I included code to simulate simple particle-systems, made the Render() function call the RenderPSystems() function, and allowed entities to have an associated particle system
- I am fully listing RunGame() and ProcessInput() above since, even if they are mostly unchanged, you can see where the changes related to texture handling, sounds and particle-systems fit.
The code above is crying for a few more refactorings: some unified entity-type management, so that you can call a single function and have it create the related sound and particle effects, etc… but it’s ok for now, we’ll add that soon.
Here is the complete source code as of the end of day 3: spacecrash-source-day3.zip
And here is how it looks and sounds now (pardon the poor sound quality, need to set up a better way to capture sound than using the built-in speakers & mike (!)):
Spacecrash: Day 3 of 7 from Jon Beltran de Heredia on Vimeo.
Tomorrow: levels! levels! levels!
And if you want to be notified when new articles to help you become a games developer are ready, just fill in the form below:
You thought about putting a timer in order to give some kind of reward when the player goes faster… How about making the fuel decrease fast enough so that the player cannot reach the next fuel barrel if staying at lowest speed? That way, the player can “stock” fuel so he can decrease speed for more complicated areas at the end of the level.
Yes, I was thinking about something like that when I added fuel as an element… what you propose makes sense. I will keep thinking about it and testing things for a few more days until I find something that provides an interesting system.
What do you think of this : instead of being able to speed up and slow down yourself, she ship automatically speeds up (up to a limit), and the only way to slow down is to shoot a rocket, because of the recoil effect. And then, if you limit the amount of rockets, it becomes a matter of tactics when to use them. And then rockets could be another pickup as well.
As an added bonus : this brings back the controls from LEFT/RIGHT/SPEED_UP/SPEED_DOWN/FIRE to LEFT/RIGHT/FIRE, and this makes it easier to translate to a mobile platform.
That’s definitely a cool idea, will keep it in mind. My current idea for mobile is that accelerate/slow-down will be controlled by tilting the phone forward/backward. Temple Run gets away with having you tilt sideways, so it may work well. Gotta test it.
But I really like the idea of combining shoot & slow-down. Will have to try it. And if you do try it yourself, let me know!
Word of warning about the gyro controls… besides the need to calibrate, one must be careful with the rotation axes. Tilting sideways Temple Run-style usually works because the screen stays perpendicular to your eyes, whereas pitching forwards/backwards will affect the visibility of the screen and the perception of distance along the vertical axis.
Thanks! I was thinking about doing it “callibrated relative” to allow for different resting-state tilts. But indeed it will be tricky, though I definitely want to test how it feels. Maybe Francis’ idea above about needing to shoot to slow down is what can work best!
Well, I did manage to make the changes that I talked about.
I made the start speed lower and the max speed higher. When you shoot, your speed goes down a bit. I’ve also increased the fire rate. And of course you’re constantly speeding up. There are now rocket pickups and a graphic indicator on the left that shows how many rockets are left.
I added some extra graphics (just the rocket once rotated and once cropped) but I managed to make the bmp’s not work, even though I wrote them with paintbrush. Anyway, here’s my variation : https://www.dropbox.com/sh/4rktp3w29rnha70/ND1sKoyacW
I was thinking more along these lines:
Flying slow uses more fuel to cover the same distance than flying fast would. You start with not enough fuel to make it to the end (at least not when flying slow), so a player flying slow would have to pick up more fuel to be able to finish the level.
On a completely different note: I think the mine and the rockets, especially the rockets, are to large (in relation to the players ship). And the content generating code should take into account that the player should be able to pick up the fuel blobs, so they can’t be too close to the rocks (in the first video it happens several times the fuel blobs are actually on top of the rocks).
But I have to say I’m impressed with how far you’ve already taken this game in just a few days! I love reading this blog. Keep up the good work!
Yeah, some strategy is needed to make fuel/speed thing work. I am not convinced about the current “fuel is automatically spent to repair the ship” thing.
You are right about the sizes, I just threw them in. I will adjust those today and tomorrow. I like a large rocket though, it’s kind of cartoony (and with the proper sound & particle effects it should be really cool). Mines are really large though.
Fuel is just generated “randomly” now, and there is too much of it. Since I’ll be focusing on level generation today, hopefully I’ll be able to do something about it.
Thanks for your kind words.
Hey Jon, keep up the good work!
After the week is over, I’d love it if you could go into more detail about the core methods, both the GL and AL stuff. That’s the only part I don’t fully “get.”
Thanks again, you rock.
[…] Spacecrash day 3 of 7: gameplay revamped […]