Ehm, ok let’s say I’ve already tried something, but only for testing the new awesome TAS mode, as asked by @FManga
So some sort of vertical scrolling game.
Chatted with @Vampirics on how hard is to find some assets with punk theme… No problem he said, just make some assets!
Me: Do you like it?
He: Yes! It’s procedural, great.
Me: ehm, actually not, I plan to use tiled to create maps…
Me: Ok, I’ve understand.
About the story, you’re a steam robot, that drill towards the center of the earth, deeper and deeper.
Why are you drilling? What will you find? Who rules this strange distopia where robots are forced to work all day? Where robot take energy? Do the robots have feelings?
Action game with a deep story that will bring the player to uncover this and other mysteries.
(really I can’t say more)
Still unsure about the resolution, target was 220x176 but I’ve noticed some tearing at high speed, maybe it’s the monocolor tile, so I’ll wait for colored assets to come.
And yes, map is dynamic and destructible!
Only a little too small as the limit in tilemap is 255x255. Need to find out the best way to shift all stuff around.
Have lot of RAM to play is a joy!
It’s the version I grabbed and integrate in my project. Probably the same version that @FManga use for the float to fixed point version when transpelling Java code to c++. It’s quite straightforward and I was surprised how easy was to integrate. Only special attention need was to add the #define that remove the random reference.
Working on importing new assets in gameplay.
Color are not respected from original mockup, as I’m still using the miloslav.h (aka @drummyfish) palette.
I take the gif sent me by @Vampirics and imported in aseprite, then exported as json+png. Move the file to sprite folder in FemtoIde project and run the js script that generate sprite.h where you can find animations as classes.
Maybe the robot will need some more animation to make it more alive.
I’ve implemented a camera class that have its own coordinate and speed for x and y. In that way I can tune how it follow the player. X speed is a bit slower then Y speed so the field of view is reduced when running too fast. Right now it center the player on the center of the screen, but I’d like to move it lower and left the player more on top, to show more of the bottom level, during the descent.
The world is now endless generated (in down direction) but still quite limited is width. The tilemap is generated in RAM and shifted up when the player go down. After the shift a new line of terrain is randomly generated. We have capped to 60 FPS, and everything is smooth and nice.
There’s also an enemy (not yet the spider, but a nice ball) that patrol for invaders.
@Vampirics should release everything as CC1. I’m still unsure for the code as CC0 or CC1.
I’ll go in rewrite some of the classes that allow interaction between entities and level. Right now the enemy doesn’t know where it is respect the level and the player, so I’m controlling its logic from the level class. That’s quite a bad design as I can’t write some of the logic in the class that incapsulate the enemy. I have the feel that I’ll rewrite many parts during the develop of this project.
Still a lot TODO but the jam is running great. Probably the week end will allow me to make some more advancement and take some time to better plan the plot of the story together with a crazy idea that is starting to itching in my mind.
As far as I’m aware there is no “CC1” licence. Do you mean CC BY? CC BY-SA?
It’s actually quite common to have a ‘dumb’ entity that’s just a sack of data and then have ‘intelligent’ EntityController classes that control the entity in different ways.
This follows a similar logic to how/why game objects typically shouldn’t draw themselves (see 1, 2 and 3).
Separating the logic also makes it easier to reuse the ‘entity’ class and just swap out the ‘controller’,
even allowing behaviour changes at runtime, kind of like an inverse strategy pattern.
Feel free to disregard what I said or to tell me to keep my nose out.
I don’t intend to make a habit of offering unsolicited advice in devlogs,
but I felt the need to point that out because I feel it’s still not common knowledge.
(Particularly because a lot of tutorials use the ‘object draws itself’ approach either to make the tutorial simpler or adhere to some misguided/outdated notion of OOP purism rather than what’s practical.)
One of the thinks that I worked is the generation of the level. The world is procedural and virtually infinite.
As long as the robot procede to the bottom new rows are added, but the width was still limited.
To fix that I’m shifting the memory on the right or on the left when the player is near the border. Obviously (well not at the first sight for me) even all the entities must be moved too.
But now the world is circular and endless bottom!
Also better animation for the robot and some items have something to say. They’ll be an important part of the story.
Last but not last the little trick I spoke previously. There’s been a lot of speak about the TAS mode and TASUI mode. Both use a LineFiller to draw on the screen but even of not documented, anyone can draw a filler too. And idea here is something I already try with another entry time ago. Color shifting.
We select a 16 color palette (PICO 8) and we build an extended palette that use the base color and move the color to be darker in 15 steps.
That’s done I can apply a dark map to the pixel draw, simply adding multiplies of 16 to the base color:
It’s still on early stage, but give a nice touch to the final result.
I’ll test on different approach for the function as @Vampirics suggest to move the effect to the bottom of the screen and tune it better.
Next I’ll need to focus more on the map generation and other aspects of the game as it have some defects that I keep delay fixing:
Border of tunnels not correctly reshaped after destroy
Some enemies spawn inside walls, or they go inside in some way
The new spider jump around too much
Create some different rooms and not only the main tunnel
Robot collision (yeah still to fix)
Sound, music, avoid bad surprise at the end
Use TASUI for the messages
ABSOLUTELY not play with the light effect till the above is finished.
Next week I’ll have much less time to work on this project, so I need to carefully plan and not waste time with experiments .
As promised I focused on light effect.
First step was to implement a radial spot light around the player.
A quick test show two things:
The color shade is better
Calculate the lightmap runtime is quite expansive, the FPS dropped
The amount of free ram that TAS mode left allow me to create light map to store the light effect and recalculate it only every 100ms giving a nice flickering effect. The map is 55x44 arrray of std::uint8_t 0 means all light, 240 means very dark. So probably is more of a “dark_map”.
Anyway here the result:
and the artistic touch when the poor robot die killed by a laser shoot:
As nice side effect, the light becomes an indicator of the Robot power, that it’s drained during the descent in the well. Gems you can collect restore some of the power. Latest moments of life are the most excited, as you try to find gems but you can’t see nothing and the risk to find an enemy is high.
The deeper the harder, more enemies more risk, but even more secrets. And secrets need a way to come out. Thanks to @carbonacat TASUI adding an UI for the memories chip was like a breeze
Me and @Vampirics are preparing a story rich of interesting elements, for the ones who like to “dig” the tale. To better plan we created a private repo on github and share code and resource there.
There’s a nice feature I never use, is the some kind of Project Planner that really help me keep track of the stuff going.
As we both can work on it the dashboard allow us to populate it . Can’t share the story dashboard, but here the TODO board. I always respect the order!
Things are taking shapes, but also require more time to finish.
Looking at the commits in the repo I see that most regards tuning some game-play aspects. Falling speed, collisions with enemies avoid killing them at first shoot, falling damage etc.
Having @Vampirics testing the game means a lot of fine adjustments to little aspects of the games, really the difference for the final result.
As an example the little arrow over the mem chips…
Should appear only when the robot is near and can interact…
Oh, did you notice? The robot change aspects! Why you may ask:
seems like @tuxinator2009 found a similarity with another robot from a indie game.
This turn a profound crisis on our art director . Cries, tears and sweat and a few moments later…
I opted for the orange one, but could change in near future.
Back to code I try some optimization on memory usage, by moving some boolean that described mirror, alive, fixed and other aspects of the item class to std::bitset . Strange enough I didn’t notice any improvements in memory usage. Also in my exploration of the C++ language I fix some bad constructor of a derived class where I was not calling super class, but just manually initializing all fields again
Last but not last, the biggest news.
A Brazilian guy join our team! (And not, is not @FManga )
I’m speaking of Rafael that is composing some great sound track for our little game. We have already 2 tracks that sound great on Pokitto and add a great ambiance. Incredible how the right music can change the general feeling of the game.
Very strange, that ought to have reduced RAM usage.
Are you sure you aren’t getting RAM and flash mixed up?
Or perhaps got the readings wrong?
If std::bitset isn’t working properly for some reason you could try creating an enum class with some overloaded bitwise operators and doing the bit manipulation manually.
(Relevant references: 1, 2, 3.)
For future reference, a child class always calls at least one of its parent class’s constructors.
If you don’t manually call one of the parent class’s constructors and the parent class has a default constructor then that’s the constructor that will be called.
(If the parent class doesn’t have a default constructor then the compiler will complain and force you to select a parent constructor that has arguments.)
Sorry to not update before. Time is really scarce, and resource has been focused on code.
So what happens from last update? (scrolling github commits and trying to novelize a story of it)
Well, mostly bug fixes. Some come from my own misunderstanding and ignorance of c++, others again from me but from bad algorithms for the map generation. Some rooms spawn with wrong size or completely broke the continuity of the robot voyager.
We now have a new bad guy, and a boss room… but that’s a surprise so no pictures my friends. You’ll need to play the game.