[DevLog][WIP] A Ride In a Tank (Tentative Name)

[carbonacat]

Introduction

ARIT is a game where you’re someone who is trying to survive in a dystopian world. It’s quite a bleak world to live in.
But fortunately, you’re not alone!

Along with your partner, you’re driving a quite sturdy tank around in a dense, superficially clean City dominated by a quite egoistical and brutal government. And maybe a bit outside as well!

Status

Sorry, no screenshots yet

• 2020-04-15 - Concept phase ended.
• Upcoming - Tank Gameplay Prototype.
• ???
• Profit

Day <= 0

• A lot of thinking, mostly about what I’m going to.
• A few concept arts (see below) were sketched.

An Ominous sphere firing upon a large city.

• A first illustration of the main settings, an unnamed, heavy city.
• The floating sphere (or “disco ball of death”) is firing upon what probably were a ground thread.
• This is a candidate for a Game Over / Ending screen, depending on how things turn up.

Two people happily firing from a tank in a scrapyard.

• A bit more on the main protagonists.
• Two people battling inside a tank.
• One of them obviously enjoys the situation, even thought they’re also taking fire from their opponents.
• There are part of a scrapyard in the background, where the tank drove through the fence.

West Map of the (still unnamed) City.

• A tentative map screen, with a character pointed in the middle.
• The City is a walled one, with a lot of huge buildings.
• The Walls got defensive turrets. They’re not necessarily for outside threats.
• The City extends more than what is shown here - around 10% of it is shown.
• There is a huge Pile of Scraps. (center)
• Numerous roads/highways are running inside it.
• An important government complex dominates the view, being built on a plateau. (top left)
• Fields and related facilities are part of the city. (down right)
• The Underground Highway, outside the Walls, a well protected road network to other cities. (middle left)
• Various Ghettos and Slums can be found against the various Walls, outside the City. Those are inhabited by people not “lucky” enough to live inside the City. Government eventually cleans them out, especially when they reach too high on the Wall. (bottom right)
• Most of the lands outside are parched, scorched, with a lot of crevices. (bottom right)

Various objects, and a tentative gameplay.

• I was thinking at a tank gameplay at this point, with a top-down view.
• There is also a lot of weird machines. Not sure if that’d qualify for DieselPunk or SteamPunk. Rockets, Bullets and Mortar be raining.
• Two portraits.
• It’s not really evident, but there is a sketch of the “important government complex”, by night. Heavily guarded of course. (Bottom middle)
• Pew pew pew

More precise gameplay concept.

• “No Trouble” is an indicator of what the current situation is.
• The map shows a few buildings, and the player’s tank, with an empty fuel icon above it.
• A and B can be assigned to different item/actions depending.
• The PAUSE screen shows an inventory (16 slots), a tech inventory (4 slots), the protag’s portrait, some stats, and the SAVE/EXIT buttons. There is also a map.
• Pressing C opens the PAUSE screen, which slides up to cover most of the screen. However the main protagonist is still shown (or the tank if they’re inside it).
• HP - HitPoints, EP - EnergyPoints (for some techs).
• When in PAUSE, the game is paused. Nothing happens.
• Buildings don’t necessarily have their walls angled to 0°/90°/180°/270°.
• Some UI can be shown on the gameplay screen.

Tank gameplay, Dialogs. and a four-legged mechanical bug.

• When in the tank, there is another health bar dedicated to it.
• When in the tank, A and B have different rules, to allow firing the main weapon, to switch weapon, to brake and to exit it.
• Still uncertainty about how the tank will be driven, but the prototype will answer it.
• Dialog shows portraits and the name of the talker.
• Interior insides look isometric, but that’s not sure. However the rest of the screen will be a deep black.

[msanatan]

You did a really good job with the sketches, looks promising!

[carbonacat]

Day 1 - 2020-04-23

I finally got myself some time to start this project properly.

• I prepared the project so it fits my needs
  • I used the simple yet powerful StateMachine that @FManga has created to get a good structure for the different modes / screens (Menu, Options, Tank Driving, Character, Dialogs, …). Those I’ve called Activities because I find it less confusing than “State”.
• I compared TASUI’s tilemap with TAS’s tilemap performances.
  • I wanted to see if I could complement the default tilemap with an extra one without incurring heavy CPU costs.
  • Seems like I’ll be able to, which is good news for the way I want to render things (isometric-like).
• I also struggled with an “out of order construction” issue. The StateMachine will construct the very first State right away, so I had to be careful not making outside calls from this first State’s constructor as other objects might not have been ready/constructed yet.
  • I’m going to circumvent that with an initial state that launch another one. Most likely it’ll become later a splashscreen or something.
• I drawn a tank.
  • Initially I wanted to go for a 16 directions one, but it proved very difficult to drawn.
  • I feel like it’s quite small, but I’ll
  • The turret doesn’t rotate, because it’d need a joystick to have both at the same time. It could be interesting to have that with the joyhat!
• I integrated it with very simple controls to test it.

Weeeeeeeee. Makes me want to do an RTS, too. Maybe I will import it to Tiny War Simulator after the jam!

Concept art.

Upcoming things:

• (Rough) Pausing the game.
• Basic (intended) tank controls (Rotate, Move forward).
• (Rough) title screen.

[carbonacat]

Day 2 - 2020-04-24

More code & project structuring and few features.

• It’s now possible to pause the game by pressing C.
  • What it actually does is only freezing the game and showing “Paused.” instead of “No trouble.”.
  • However it allowed me to get another layer of state/activity, so it made for a better code structure.
• The tank is now movable with a rotation + forward/backward control.
• Added a target which currently only indicates where the tank is going.
• I refactored the code a bit.

Going backward in the tank is slower, too.

What I’d like to have for the tank: When you’re not fighting, your character’s head is outside it, not unsimilar to Advance Wars style.

Thoughs:

• I’m currently using a 2:1 isometric ratio (horizontal/X’s axis is 2 time bigger depth/Y’s axis), but I might go for a 4:3 ratio instead since it’s matches more the screen’s size.
  • It’ll make the map less deep vertically, which is probably better for readability.
  • Also it’ll feel less “slow” to move vertically. Of course the distance will still be the same, but it still feels a bit frustrating right now.

Upcoming things:

• (Rough) Title Screen
• Barreeeeeeeeeeels
• A slightly more interesting Pause screen.
• Firing the tank’s Cannon. Totally unrelated to the Barrels that will be present on the Scene by then.

[carbonacat]

Day 3 - 2020-04-25

More graphical contents and reflections.

• There are now Barrels on the Scene.
  • 4 of them, to be exact.
  • A very crude (no pun intended) structure to represent game objects.
  • Since there are no rendering reordering yet, they’re always rendered after the tank.
  • Also, they define a first idea of sizes in the game. The tank is definitely too small now.
• The game now starts with a very premature Title Screen.
  • It’s actually just waiting for A to be pressed in order to launch the game.
  • An animation will be done later to make it less static.
  • Also it’s taking a lot of flash because I’m too lazy right now, but it’ll be optimized or deported to the SD card eventually.
    • One of the best things there is about @FManga’s StateMachine is that you can have a huge amount of RAM for less interactive States/Screens such as the Title Screen.

The Title Screen, with a 1-choice menu, along with the new Barrels. The tank appears really tiny here, and will need to be redone later.

Upcoming Things:

• A more interesting Game UI / Pause screen.
• A rough Option Screen (a pretext to have an actual menu system in the Title Screen).
• Firing the Tank.

[FManga]

About that StateMachine, I added an init method to the states (since some things can’t be done in the constructor) and a report method so that I could keep an eye on each state individually during development. I just call stateMachine.report() right after begin.

I figured you might find it useful as well.

Summary

#pragma once

#include <variant>

extern "C" {
    void _pvHeapStart();
}

template<class... States>
class StateMachine {
    std::variant<States...> state;
    void (*_update)(StateMachine *) = [](StateMachine *sm){
        std::get<0>(sm->state).update();
    };

    template<class First, class... Rem>
    void report_rec(int i){
        printf("State %d: %d bytes\n", i, sizeof(First));
        if constexpr (sizeof...(Rem)) {
                report_rec<Rem...>(i+1);
            }
    }

public:
    void report(){
        constexpr auto bytesUsed = reinterpret_cast<uintptr_t>(_pvHeapStart) - 0x10000000;
        printf("Total RAM: %d bytes used (%d%%) - %d bytes free\n", bytesUsed, bytesUsed * 100 / 0x8000, 0x8000 - bytesUsed);
        report_rec<States...>(0);
    }

    void update(){ _update(this); }

    template<class StateType>
    void setState(){
        _update = [](StateMachine *sm){
            auto& state = sm->state.template emplace<StateType>();
            sm->_update = [](StateMachine *sm){
                std::get<StateType>(sm->state).update();
            };
            state.init();
            sm->_update(sm);
        };
    }

    template<class StateType>
    StateType &getState() {
        return std::get<StateType>(state);
    }
};

template <typename Type>
class State {
public:
    void init(){}
    static Type& get();
};

[carbonacat]

Definitely going to use it at some point!

Day 4 - 2020-04-26

Solely focused on the UI this time, in particular the Pause UI.

• A rough of the Pause UI was done, with a lot of hard-coded values. and empty fields.
  • I admittingly spent too much time there, but I paved the way for new things later.
  • The portrait and the map aren’t going to stay that way, they’ll be replaced with actual images.
  • Missing a lot of tiny details, like colors for the gauges.
• A tiny slide up/slide down animation has been added when pausing/unpausing.
• Also, the Character’s Health, Energy and the Tank’s Health are now shown.
• Admittedly I spent too much time doing this, however it makes the game more “real” for me, very similar to the Title Screen.
• FPS are now limited to 30 (since that’s what I target).

Very “fine” ASCII art indeed.

Quick’n’dirty animation.

Upcoming Things

• Options Screen.
  • It’ll be used at first for debugging purposes (like generating a map for testing collisions without impacting the main story).
  • Eventually its true purpose will be to test sounds, erase the save and that kind of things.
• Firing the cannon.

[carbonacat]

Day 5 - 2020-04-27

Tiny log today, focused on making the tank bigger.

• The tank is now made out of two separate sprites - the body, and the turret with its cannon.
  • Separating parts allows me a lot of things, like reusing both of them for enemies / friends, including static turrets, and to be able to change the current turret for something else -if I ever implement tank customization in this jam.
• I also made a tiny explosion sprite, which will be used for some impacts or firing.
• The tank was also made to follow the 4:3 ratio, and larger so it isn’t tiny anymore.
• The old tank sprite will surely be reused for fun things.
• No code today. I couldn’t implement the new tank yet, or its cannon firing yet.

Bigger, bigger! This barrel won’t dwarf it too much anymore. Note that proportion aren’t made to be realist in this game.

Tiny explosion is tiny. Almost sparky!

Upcoming Things

• Rendering the new tank.
• Firing the cannon.
• Options screen.

[carbonacat]

Day 6 - 2020-04-28

Making the new Tank into the game, and implementing the Cannon Fire.

• The Tank was updated with the new model.
• Pressing A will fire the Tank’s Cannon.
• A small animation is played when firing the Tank.
  • Not so sure about “sliding back” the whole turret, I might go back to a Turret animation instead later, yet this is still fun to watch somehow.
• A cannot be spammed - the Tank will need to cool down a bit.
• No shell yet is fired.
• A few internal reworking and a few modifications in the SpriteConverter to fit my needs.

Can’t wait to explode those barrels!

Upcoming Thins

• Option Screen.
• Firing an actual shell.
  • It’s an important part because it’ll introduce the projectile subsystem.
• Pushing a barrel when trying to roll over it.
  • A rough unoptimized version at first.
  • It’s another important subsystem.
• Collision Map.
  • Yet another important subsystem. It’s formally the introduction of the tilemap.

[carbonacat]

Day 7 - 2020-04-29

A bit more interesting things!

• The Title Screen was given an actual menu system.
  • It allows to launch a new game or to go to the Options Screen.
• An empty Options Screen was added as well.
  • Currently only giving a “Back” option.
• TASUI’s delta/clut are now used to color various texts in a more formal manner.
• The Tank can now fire actual projectiles, which will do a curve until they crash into the ground.
  • Projectiles are actually created right in front of the cannon’s muzzle.
  • Up to 4 projectiles can technically be present at the same time right now.

An actual menu system!

Firing some… huu ball of scraps I guess. The fun factor was increased by 100%

Upcoming things:

• Projectile-Barrel Collisions
• 'SPLOSIONS
• Barrel-Tank Collisions
• Barrel-Barrel Collisions

[carbonacat]

Day 8 - 2020-04-30

Getting more physical!

• Drawn two explosions - one of them is used right now.
  • Thanks to @pixelbath’s suggestions I made them asymmetrical so they can be mirrored to provide cheap variety.
• Projectiles are now colliding with the Barrels.
• When projectiles collide, they explode!
  • The explosion’s game effect isn’t applied yet.
  • Also, the Tank, the Barrels and the Projectiles aren’t unified yet into the same structure, either for rendering or physics. This will be required later for depth ordering, and more immediately for physics collisions / interactions.
• I also set up Code::blocks on my PC to ease with debugging.

Tank’s shell’s explosion. More sudden and violent.

Barrel’s explosion. More of a burning liquid explosion.

Testing Projectile/Barrel collisions. The collisions are resolved in 3D using a simple model of Cylinders.

Upcoming Things

• Damaging Barrels with Explosions.
• Pushing Barrels with the Tank.
• Barrels Exploding due to Damages.
• Collision Tilemap

[filmote]

That barrel explosion is really nicely drawn … it is quite hypnotic when you watch it!

[carbonacat]

Day 9 & 10 - 2020-05-01 / 2020-05-02

A bit of barrel works and a lot of internal works in the engine:

• Drawn more states for the barrel in preparation of its damaging.
• The Tank, the Barrel and the Projectile now share a common base called Entity.
  • That means multiple Tanks at the same time, tho the Player will always control one at most.
• Entities’ rendering is done using a special context class.
  • Currently helps when transforming game coordinates into screen coordinates.
  • Later will support more interesting features like depth sorting (or Y-sorting like @FManga calls it ), quick clipping, etc.
• The camera is always centered on the Tank.
  • Later it’ll be on the main character as well.
• Tried to use a formal fixed point class but it ended up being much more annoying to do than simply use regular ints with the proper divisions.
• Currently working on an interaction system.
  • Another name would be “physics engine”.

Centering on the tank, even when pausing/unpausing.

From intact to destroyed barrel.

Upcoming things:

• Interactions between Entities / Physics Engine.
• Barrel Damaging & Explosions.
• Pushing Barrels with the Tank.

[Pharap]

@carbonacat

Tried to use a formal fixed point class but it ended up being much more annoying to do than simply use regular ints with the proper divisions.

Which one did you try to use?

If it’s my one then I’m happy to answer any questions or listen to any complaints.
(If it’s that C-ish “what’s operator overloading?” one that’s in the PokittoLibs folder then I’m not surprised you found it annoying.)

[carbonacat]

Unfortunately I’m so late into my project I’d rather be sticking to the current code which is based on int. I’ve been working with fixed points since almost two decades, I know the vast majority of the pitfalls, and so far I never was satisfied with any lib I tried. There is always some compromise at some point, or then it’s extremely verbose.

I tried again but it’s just not as smooth as plain integer. I won’t develop more on it, because trying to explain why is going to cost me more painful time as well. I don’t want to spend more energy on this, especially since I can do it the “old way” efficiently enough.

However I thank you for your proposition. I’ll be sure to have a look at your lib after the jam. Some parts of me is still annoyed to have those 8/16/256 prefix after variables name to reminds me they’re the x8/x16/x256 version of the actual value, after all.

[filmote]

@carbonacat

There is always some compromise at some point

I see what you did there.

[FManga]

I have also reverted to plain int for my entry. If you know that multiplying two 32-bit values won’t overflow, you really don’t want to use a 64-bit int, it’s much slower.

[Pharap]

@carbonacat

There is always some compromise at some point, or then it’s extremely verbose.

Unfortunately that’s the nature of programming.
Programs are rife with compromises and heuristics,
and programmers are the ones who have to make the decisions.

In the case of anything mathematical, there’s so many different ways to do things that after a while you have to provide specific named operations.
That’s as true for floating points as it is fixed points.
(IEEE 754 defines at least 5 different rounding modes.)

@carbonacat

Some parts of me is still annoyed to have those 8/16/256 prefix after variables name to reminds me they’re the x8/x16/x256 version of the actual value, after all.

That’s where a strong type system comes in.
Information like that should be part of the type.

I once saw a presentation* that demonstrated how encoding units as actual datatypes instead of using raw floating points could signal logic errors at compile time.
E.g.

// OK, type is kilometres_per_second
auto speed = 100_km / 2_s;

// OK, type is kilometres
auto distance = 100_km / 2;

// Error, this doesn't make sense
auto nonsense = 2_s / 100_km;

(That’s legal C++11.)

(* Bjarne Stroustrup’s Going Native 2012 Keynote presentation, specifically at 18:52.)

This sort of thing inspired my library, hence I allow code like:

// Type inferred as UQ16x16 due to promotion
auto inferred = UQ8x8(0.5) * UQ16x16(0.25);

// Floating point literal converted at compile time
constexpr UQ8x8 half = 0.5;

(You can look at all this stuff after the jam or whenever,
I’m just mentioning it in case you or anyone else finds it interesting.)

@FManga

If you know that multiplying two 32-bit values won’t overflow, you really don’t want to use a 64-bit int, it’s much slower.

This is one of those ‘nature of the beast’ issues.
Some people will inevitably want precision over speed,
whilst others will want speed over precision.

I do actually know of one way to solve this in such a way that operator * could do both,
but it’s a fair bit of effort, so introducing a named function is usually the easier option.
(Spoiler: it involves more template parameters.)

[carbonacat]

I’ve seen the same presentation. It’s attractive, and I like the fact that the chrono part of the STL kind of follows that paradigm.

However, let’s talk about these fixed after the jam, ok? I’ve got more critical stuff to do before and I’ve already decided that I wouldn’t use a fixed class right now

[Pharap]

@carbonacat

I’ve already decided that I wouldn’t use a fixed class right now

As I said, I was just leaving that info around so you can come back to it later,
(and in case anyone else was interested,)
I was not trying to get you to change what you are doing right this minute.