jonbho

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”
– Sound
– 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:

First core.h:

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: