I’m Chalcedony, the programmer of Ascender, also a part-timer in devlog writing. Programming Ascender has been a great challenge for me as none of my previous projects are of this level of difficulty. Having said that, I would like to share how complex to code Ascender is, a task that might look simple, but really it isn’t.
As you might have known by now, Ascender is a 2D explorative metroidvania-like game, with a dash of RPG elements. Well, there is actually so much to code. Besides the usual main menu, pause function, etc., which are found in almost all games, some of them are (in no particular order):
- Character movement (how he moves, including his skills such as double jump, wall jump, etc.)
- Environment (moving platforms, floor switches)
- Dialogues (managing who talks what given current condition, e.g. possess an item, undergone a quest, different talk between night and day)
- Quest and event system (trigger cutscene or unlock quests when certain condition occurred)
- Camera movement
- AI for monsters (mainly bosses)
- Input management (interfacing different input methods: keyboards, joysticks)
- Rune system
FYI, rune system is an element unique to Ascender. Think of it as a crossover between jigsaw and skillset manager… You gain the abilities by placing the jigsaw pieces! This feature is so *IMPORTANT* that it deserves its own page… Keep your eyes peeled for information on future updates!
Ascender is a platformer game, and I’ll be nice to copy-paste Wikipedia about the definition of platformer games (after all, that’s what all programmers are master at – copy-pasting).
Now, there is this guy named Rodrigo who wrote about platformer types. The original article can be found in Higherorderfun.com . Summarised, depending on the implementation, there are four ways to create platformer games.
- Tile-based (e.g. Lode Runner)
- Smooth tile-based (e.g. Megaman, Super Mario, Metroid, Contra)
- Bitmask (e.g. Worms)
- Vector (e.g. Braid, Limbo)
Pop quiz. Which approach did we take?
Answer: Look at those masterpiece created by our artists! Of course they won’t go easy on us programmers – we have to implement their wildest dreams! By far only option 4 satisfy them.
Having chosen option 4, there is one critical question before we proceed any further. Will you use an existing physics engine, or will you write your own physics engine? For those who are feeling bold, option 2 may yield better result, but for time-constrained project like we have right here, we took the first approach and use Unity as the game engine.
Now I shall introduce you the very first element we have to implement: How the character moves. Moving left and right on a flat surface is as simple as it gets, you just have to apply acceleration until you hit some maximum velocity so your character won’t run too fast.
The problem begins with slope. Let me give you pointers by showing some cases that you *MIGHT* want to consider if you’re going with physics.
Running on those slopes launches your character into the air? Hey, snap out of it, physics! Now how do we cope with this problem? Use raycast! That way you can prevent jumping off the slope problem.
In fact, raycast might be a good solution for many problems you might encounter in developing a platformer game. Detecting switch? Shooting a projectile? Pushing blocks? If none other works you should look into raycasting. Take a look at this example showing how you *must not* push a block.
Hey, I’d like to tell much more, but look at the time! I’ve written too much for today, so let’s talk about the other game elements later! Now it’s your turn to write your thoughts on the comment box below, and hit subscribe! That’s all, folks, thanks for reading!