Andrey Listopadov

Game3 W?/4

Sat, 16 Sep 2023 01:59:00 +0300

I’m working on the next game, although I gave myself an extended period of rest. After failing to complete the last one I needed to distract myself a bit from this activity, so I worked a bit on Fennel stuff, played some games, and I think I’m back in business by now. I have an interesting thing going on with my productivity - it comes in waves. What I mean is that I can go onto programming frenzy for several months, and then once I feel burned out, I can just play games for another full month straight. Though I get tired of games too, and if by that time I feel that I’m not ready for programming yet, I can read some technical books, or even just some manga if I still feel too tired to be productive.

So this five month marathon is a bit hard for me, as I basically have to give up on long periods of rest, and juggle my free time to actually have some time to work on these projects. While these games are nothing special, I feel like I’m still learning new stuff, and thus this is beneficial for me still. Though, at some I actually thought of dropping the whole idea, and starting a more complex project that I was thinking about for a lot of time already. But I decided to leave it for the next year, as I still need a lot to learn. But, back on the topic.

This post actually marks the end of only the second week of the current game. How come, you might ask? To put it simply, I miscalculated a bit, and in reality I had another week on the previous game by the time I dropped it. So, technically, I could probably finish that game, but the burnout got me, so that’s that.

As for this game, I have a little to show. As it is a side-scrolling shooter, I designed a basic ship with some shooting modules, and some powerup icons. I considered to not making any graphics for this one, and doing everything with just primitives, like triangles, circles and so on, but after trying to draw a ship like this I dropped the idea and returned to Pixel Studio. Here are the results so far:

The ship turned out to be a bit too big, but I decided that I can make a game with larger assets for a change. So the enemy also uses 4 sprites, instead of just one, as in my previous games.

And here are the enemies animated:

Movement animations

Explosion animations

Obviously, I need to add more enemy variety, with different patterns, but designing enemies is hard. BTW, if you’re curious how I draw things on the phone, here’s a time-lapse:

Your browser does not support the video tag.

Though, I usually don’t do it in the landscape mode, portrait mode works better for me, especially with a stylus. This process was recorded in landscape just for viewing convenience.

On the technical side of things, I already implemented a basic movement with linear interpolation for the flying modules, and implemented some enemy patterns, but there’s no actual interactions yet. I’m kinda torn on the idea of including bump.lua again, as I feel like that this game can be done without any collision library. At the same time, having a collision library may make things much simpler, so I’m still thinking how to approach this game.

For the record, I basically dropped the idea of making any kind of music for these games because I just can’t get myself to work on it. I do plan to take some courses on music composition for future projects, though. Sound effects are challenging enough already by themselves.

That’s all for this week! Hopefully, I’ll manage to finish the game this time, though I already lost one week. Let’s say, this is week 1/3 instead of 2/4 shall we? Feels less demotivating this way.

Comment via email

Game1 - Results

Sun, 30 Jul 2023 15:29:00 +0300

Well, this was fun! A bit exhausting, actually. The first of five months of the challenge has ended and here are the results:

Play Game1 on itch.io

The game isn’t really complete, but I did my best to make it feel as complete as possible in the time constraints I had. Technically, I have 1 day left, but given that I need to start working on the next game immediately I decided to give myself a day off. It only features one level, and cuts out to the “you won” screen, but I still consider it a success.

Here’s the last bit of devlog for this particular game outlining some things I did since the last post in no particular order.

Graphic overhaul

I’ve added parallax scrolling to the background, making the game happen inside a cave. Well, at least, now the background is not that boring to look at, but it’s still plain.

Then, I added a second layer and started experimenting with different colors:

The problem with limited colors is that I can’t find a way of having foreground and background properly separated without using outlines on sprites, which I wanted to avoid for this game at least. Thus, slimes are now blue instead of green. But I like it more this way because it pops from the green ground a bit better. And now that the background is also green it’s a lot more sensible.

I’ve spent some time drawing foliage, like mushrooms, trees, grass, water, and so on. None of this is animated though - time is once again against me.

Also, added the menus, title screen, cover art, and some fade-in/out animations for smoother transitions:

Enemy AI

While I wanted to add more enemy types to the game I simply ran out of time, so the game only features basic slimes. Their AI is extremely simple too - just roam forward until there’s no more ground, a wall, or another entity, then turns around.

Still, I had some trouble implementing this at first, as I tried to use the world:check method to try and move the slime forward and below to check if there’s ground to traverse on. But this didn’t work for some reason, so I opted for advanced bump API world:queryRect and queried the rectangle below the slime instead. It worked nicely, and perhaps I’ll use this to make a more robust AI in future games.

I was toying for a little bit with flying enemies, but it’s hard to make them work right with the environment. I didn’t want something like Medusa heads from Castlevania games, but that’s exactly what I got during testing.

I also finally added the death mechanic, as previously the game lacked it completely. Death doesn’t take away your score, as the game turned out to be hard, and there are not enough coins in the only level to get 100 of them and earn an extra life.

Level design

Probably shouldn’t have left this to the last possible moment, but designing interesting levels turned out to be a lot harder than I thought initially. I think I’ve managed to at least do a somewhat challenging one, but you’re the judge here. Probably most enemies and traps are cheap.

As I mentioned previously, I’ve used the map editor to construct the level:

It’s a shame though that Tiled, a tilemap editor, doesn’t support TIC’s maps. Well, there’s a converter but it didn’t work for me. Map editor in TIC isn’t bad, but it isn’t as good as something like Tiled. For example, Tiled has randomization from a selected set of tiles when you paint with them, which makes things like ground feel less repetitive. In TIC I had to do it by hand, and I may have forgotten to do it somewhere in the game, so excuse me if you’ll see something like that.

I used the bottom of the map to draw menus, backgrounds, transitions, and so on, as can be seen here:

My initial idea was to implement the first few levels like this, one below another, and then switch the memory bank, draw a new set of tiles, and make more levels. But not only I ran out of time, I also ran out of ideas. Maybe next time.

Overall, I’d say making levels isn’t my least favorite thing so far but it’s close. I’ve played in a fair bit of games with level editors and even published some online, but it never grew on me. I guess I’m not a level designer at heart.

Music and SFX

This was probably the hardest part. I can’t compose music and TIC’s tracker is alien to me. Sound design is a bit easier, but I don’t know a lot of tricks, so sounds in this game are far and few between. Still was worth a shot.

Up next

The next game in the challenge is a roguelike. This kind of game poses different problems, like pathfinding, more complex enemy AI in general, randomization of levels, items, etc. I kinda feel exhausted right now but I’ll still try not to repeat the mistake I made and not procrastinate too much in the first weeks. Though the next month is packed with various life-related events, much more than this one, so we’ll see.

As for this game, here’s the cartridge if you want to play it yourself:

Though, because the original code requires a more recent version of Fennel than the one TIC provides, the code in the cart above was AOT compiled to Lua and isn’t very readable. Also note that the last stable release of TIC still contains the #1904 bug, which means that my game will run ~10 times slower than it should. So you either need to play the game on the itch.io page, as it features a more recent version, build a standalone version yourself, or use an older release with the Lua version above. You can read the original source code at the itch.io page linked above, or in the game repository.

Comment via email

Game1 W4/4 progress

Wed, 26 Jul 2023 20:09:00 +0300

This post is midway through the last week I have to work on the game in a platforming genre. And it’s a bit of a shame because currently, I’m having a blast - now that the physics and camera are in place the game already feels like a playable thing. So I decided to boost this feel and make some graphics so the world won’t look too boring to traverse.

I haven’t decided on what the world be like yet, but I’m running out of time, and also, I’m not that experienced in pixel art. A few posts ago I wrote how I tried to do pixel art on the phone by using a stylus, and it worked pretty well for me. So I took out the app again and started thinking about how would I use the colors that are still available to me.

I’ve briefly considered changing the palette too. The default TIC-80 palette is a bit weird for my taste, and it doesn’t include some colors that I’d like to have, e.g. brown. I don’t know how, but every time I see some pixel art that uses this particular palette I swear it has brown, but upon closer inspection it’s an illusion caused by interplay with the other colors. Unable to find a new palette that works, and also that doesn’t make every other sprite I drew up to this point use some weird colors, I gave up for now. Maybe I’ll just look at what colors I don’t use at all or use too infrequently and replace them with the colors I need for my purposes.

For now, I drew some grass on stone type of terrain (again, no brown for dirt!), and some construction site-type red bars:

Note, these are tiles, e.g. what goes on the map, but there are some things that are not part of the map, for example, the coin, or the slime enemy. I’ll explain why they’re here shortly.

And here are the sprites:

As you can see, I’m storing these sprites mostly in rows, and tall sprites, like the player character look naturally in the editor. Except for the ones in the third and fourth rows first half - these are horizontal sprites, but I still store them this way, because of how I do animations. This reminds me that I haven’t explained anything regarding how my game works! I guess I was too busy implementing it and didn’t have any spare time to write a proper post.

So the animations are implemented in terms of sprites, obviously, but the way I set up them is a bit weird. And I know, I definitively could save some space and re-use some sprites, because clearly there are doubles or even triples of the same sprite. But it was easier this way, so I did it anyway. I have this function, called sprites that takes an id of the first sprite, the last sprite, and an optional loop? parameter:

(fn sprites [from to loop?]
  (let [sprites (fcollect [id from (or to from)] id)]
    (doto sprites
      (tset :n (length sprites))
      (tset :loop? loop?))))

The result of this function is a table, that simply holds a range of IDs for all the sprites in the animation. Does the n key hold the total count of sprites, and loop?, well, we’ll get to it in a moment.

The other component of animation is how I choose when to change the frame. I’m sure there’s a different, and probably more robust way of doing this, but what I’ve settled on is this function:

(fn next-frame [obj dt]
  (let [dt (+ dt (or obj.last-draw-time 0))]
    (if (>= dt 60)
        (let [sprites (obj:sprites)
              n (m/floor (/ dt 60))]
          (set obj.last-draw-time 0)
          (if (= obj.frame sprites.n)
              (case sprites.loop?
                n (if (= :number (type n))
                      (set obj.frame n)
                      (set obj.frame 1)))
              (set obj.frame
                (clamp 1 (+ n obj.frame) (length sprites)))))
        (set obj.last-draw-time dt))))

As you can see, this function receives an object obj and a delta time dt. The object stores its own draw time, and when the sum of dt and this time is greater than 60 I change the frame. The loop? field is used in a special way - when the next frame exceeds the total sprite count, we check if the animation should loop. If the field is true the animation loops from the first frame. However, if the field is a number, we restart the animation from that number. This way the animation can have a set of frames that act as preparation or transition, and then loop only the necessary part.

Here’s how I draw coins:

(local coin-sprites (sprites 330 335 :loop))
(local coin-collect-sprites (sprites 346 351))

(fn draw-coin [{: x : y : frame &as self} {:x cam-x :y cam-y}]
  (match (self:sprites)
    coin-sprites
    (let [s (or (. coin-sprites frame) 511)]
      (spr s (+ cam-x -120 x) (+ cam-y -64 y) 0 1)
      (next-frame self (/ dt 2)))
    coin-collect-sprites
    (let [s (or (. coin-collect-sprites frame) 511)]
      (spr s (+ cam-x -120 x) (+ cam-y -64 y) 0 1)
      (next-frame self dt)
      (when (= frame collect-sprites.n)
        (tset coins self nil)))))

There are some wonky numbers in here to adjust to the center of the screen and camera position in the world, but the code should be straightforward. The (self:sprites) call simply returns the object’s current set of sprites, which I change in other functions depending on the situation. E.g. if the coin was collected, the object’s sprite is changed to the coin-collect-sprites which doesn’t loop, and the last sprite of that animation is invisible. The coin itself is deleted from the world once the last frame of the animation was played out.

Your browser does not support the video tag.

This is the basis for all animation in the game. Each object has it’s :draw method, and each such method calls to next-frame to understand what to display next time.

Interaction with entities is done similarly - each entity has an :interact method that decides what to do when a collision is detected. For example, for the slime enemy, the method accepts the y normal of the collision, and if it is not negative 1, which means that the collision happened from the side or from below, the player is damaged. Otherwise, the slime sprite set is replaced with the stomp animation, and the object is deleted from the world:

Your browser does not support the video tag.

By the way, I haven’t talked about how I structure the world yet. You may know, that TIC has an inbuilt map editor:

This is basically a level designer for me because I’ve implemented a small function that upon loading the cart walks through each tile on the map and populates the world based on it. I still use map for drawing the level, but before that, all entity tiles are removed from the map, like in the image above coins and slimes, and the player’s head, which acts as a spawn point. This way I can simply put objects in the map editor, and re-run the game, getting an updated world, complete with collectibles, power-ups, enemies, etc.:

Your browser does not support the video tag.

Here I’m obviously testing things out, but the game feels complete enough to actually start designing some actual levels. I’m running out of time though, so perhaps I’ll just make a single course to complete, and that’s it. But it’s already more than I’ve anticipated at the beginning!

I’ve also started working on the menu, but there’s nothing to show yet.

From now, I’ll probably stop doing any in-game stuff, and concentrate on the level itself and I also need some audio to play when the player collects coins, takes damage, jumps, and so on. Maybe I’ll even include some music if I’ll manage to compose something not too annoying to listen to.

Comment via email

Game1

Fri, 30 Jun 2023 22:46:00 +0300

As I stated a month ago, I’m going to force myself into game development with a personal game dev marathon¹ that will span over the next five months. Technically, nothing prevents me from jumping off at any point, so I do want this to go as smoothly as possible, so I won’t burn out until I get out at least two games. Well, we’ll see, of course - life often has its own plans for me, so… yeah.

The first game on my list is a platformer, which I wanted to be as simple as possible, e.g. basically run and jump. I have no prior experience in making platformers, so this will be an exciting thing to try! I’ve decided to go with TIC-80 for this one, to further reduce friction, as this game engine/fantasy console has everything I need to design a game.

In the previous post, I also mentioned that I was traveling, and while I wasn’t able to get to my laptop at all, I’ve decided that I will allow myself to draw some sprites for the upcoming game in advance. The only problem was that I had to do it on my phone, which is a challenge on its own, and I don’t know what software to use.

I’ve tried a bunch of options, and settled with PixelStudio by hippogamesunity. Sadly, it’s not open source, but it is common for a lot of software for pixel art, and art in general. The only open-source free software pixel art app I know is LibreSprtie, which itself is a fork of Aseprite which changed its license some years ago and is no longer FOSS. Since I was considering paying for either of those, I decided to go with PixelStudio because my phone has a stylus (S-Pen) that is supported by the app, and drawing on the screen seemed nicer. I can always bring LibreSprite on my laptop in case I need more, and TIC also has a sprite editor. TIC is also available on the phone, but unlike TIC, PixelStudio gives me the ability to do animations, which is what I was mainly looking for. If not for animations, I would probably stick with the phone version of TIC until I’ve returned.

So I went on and started working on characters for my Game1 project. Game1 is, of course, a work-in-progress title, but it’s not far from the truth, as this will probably be the first thing that I will consider something like a real game made by me. Anyway, this is how the app in which I drew my character looks:

The interface is a bit cluttered, but I find it useful enough if the screen is big enough, which is my case. But, back on character animations, here’s what I’ve got so far:

This is just a mockup, testing around how animations would look in-game. The blue fireball was added to show the damage animation, I’m not even sure if the projectiles will be in the game. And starting from tomorrow I will actually start putting things together in the TIC. I’m now realizing that by using too much color in the character sprite, I kinda limited myself on the number of colors that I can use for the background, and terrain because the default palette in TIC is quite limited on colors:

So I may need to do a bit of redesign on the character part. Actually, I’ve always liked pixel art for its limiting nature - the ability to express a lot of ideas and small details in such a low amount of pixels and colors always fascinated me. I don’t know much about pixel art, and it probably shows, but hey, this marathon is to learn new stuff, so give me some time! But, right now I’m not even sure how do I program such animations, so I’ll probably start with just drawing a rectangle for the player, enemies, and platforms.

I will be posting updates as soon as I get more progress, so expect this as a kind of dev-log, but honestly, it is mostly for me, as I find this kind of activity encouraging to keep on.

You’re welcome to join, of course, but I’m not going to organize an actual event ↩︎

Comment via email