Devlog #1.8: The Ship has Sailed?

Hey everyone! Stardance says that I have a certain amount of time logged and that if I ship and don’t make a devlog for that time, I’m gonna lose it. So, I’ll make a quick devlog:

README.md:

I created a nice README.md for the GitHub Repo. I also added a wiki, so that it will be very easy for anyone to learn Olympus.

Turned into a Python Package

This is my first time uploading a Python Package to PyPi, the official provider for Python packages, so this was a new experience. However, there are lots of documentation online that made it very easy. So, Olympus is now an official Python library! You can check it out when i ship the project.

Welp, that’s it. I hope to see you next time!

Devlog #1.7: We’ve Reached the Peak!

Hello everyone! Welcome back to another devlog. I’m happy to announce that my game engine, Olympus, is finally finished! Here’s what I added.

Sound

This part took about 1 - 2 hours to implement. Because the game engine is a 16-bit game engine, this means that we can only play sounds that are 16-bit. You can create your own sounds using the game engine, but you can also upload your own sounds. The program works by converting your sounds into a 16-bit audio that the game engine can render.

Sprite Editor

This part took foreverrrrr. Basically, instead of manually typing out sprites for your game, I wanted a editor where you could draw the sprites and then export them. This took forever because I didn’t know how to export your sprites into actual array code that would turn into a sprite. However, I was able to just reuse my code that render sprites from a list into the sprite editor and add functionality that would turn the blank spaces in the canvas into a ‘.’ (blank space) and all the squares that are drawn into an ‘x’ (the actual sprite pixels). I was also able to add saving and onion skinning.

What’s Next?

I’ll be turning Olympus into a Python library so everyone can install it. Then, I will ship the project. See you next time!

Devlog #1.6: Sights on the Peak!

Hey everyone! Welcome back to another devlog. Today, we are one giant step forward in finishing the game engine: tilemaps and animations.

Tilemaps:

The whole level is a grid of letters. I draw my maps as plain text: W is a wall, C is a coin, ’. ‘is empty space (These are just the examples that I’m using for the demos). So a level is literally a block of text I type out, like ASCII art of the room. The engine turns each letter into a tile. It walks the grid square by square, and for each letter it looks up a matching 8×8 picture and stamps it at that spot. A ‘W’ becomes a wall tile, a ’. ‘draw nothing. This is all easy on paper but when actually trying to create it, it was hell. The amount of bugs that would come wouldn’t stop and I actually was very close to giving up for the day. But, I persisted, and after over 20+ Google Tabs, I was able to work it out.

Animations:

Even though I thought this would be the hardest thing to implement, this one was the easiest feature to implement imo. It’s a flipbook of sprites. A walk animation is just a list of frames, the same little pixel sprites I already made. Flip through them fast and the legs look like they’re moving. A timer controls the speed. If I swapped frames every single frame of the game (60 times a second) it’d be a blur, so I count ticks and only switch to the next frame every few ticks. That one number tunes how fast the walk looks. When it reaches the last frame it loops back to the first, so it cycles forever. It only animates when it should. While you hold an arrow, I advance the frames so the hero walks.
When you let go, I reset to the standing pose so he doesn’t moonwalk in place.

What’s Next?

This engine is veryyy close to being finished! I just need to add sounds and this engine should be complete! After I finish the engine, I will ship the engine. See you next time!

Also, if you want to know what the tilemap in the demo looks like in code, here it is:

LEVEL = [  
                    "WWWWWWWWWWWWWWWW",      
                    "W...........................................................W",      
                    "W.................WWW.......................C....W",      
                    "W............................................WWW..W",      
                    "W..C......................................................W",      
                    "W.......................WW...........................W",      
                    "W.....................WW............C...............W",      
                    "W..........................................................W",      
                    "W..................WWWW........................W",      
                    "W.............................C...........................W",      
                    "W.............................C...........................W",      
                    "W.........................WWWW.................W",      
                    "W..........................................................W",      
                    "W........................C...............C..............W",      
                    "W..........................................................W",     
                    "WWWWWWWWWWWWWWWW",  ] ```

The formatting is messed up as the original is in Python, but I hope you get the gist!

Devlog #1.5: The Writing’s on the Wall.

Hey everyone! Welcome back to another devlog for my game engine made in Python: Olympus. Today, I added the hardest things to implement: text and collisions.

Text:

This is the one I struggled with the most. I wanted text while having the 16-bit style that I was going for. I tried displaying text using the SDL2 functions, but it didn’t give me the effect I was looking for. So, I had to make my own. And, it was tough. It didn’t help that I had no idea what I was doing, but it also didn’t help that I had many bugs. However, I was able to figure it out. I was able to do this by making each letter a tiny picture made of pixels and store all of the characters in a lookup table.

Collisions:

Collisions was easy when looking at it. Check of the walls or an object is colliding. if it is, do something. Otherwise, don’t let the player go into it. But boy, was it hard to implement. I spent a good 3 hours just trying to figure out how to do this. But, eventually, I figured it out. It works as the collisions check if two boxes overlap only if they overlap left-to-right AND up-and-down. If there is a gap, then they aren’t touching.

You can see both the text and the collisions in effect in the little demo I made below.

What’s Next?

I have a feeling that we are very close to being finished with this game engine, but I’m probably getting my hopes up. Next up, adding animations and tilemaps so that you can create levels. That’s it for me. see you later!

Devlog #1.4: If Looks could Kill

Hey everyone! Welcome back to another devlog! Today, I’ve finally implemented sprites into the game engine: Olympus. This way, you can make your character look like anything!

How do the sprites actually work?

I made my own sprite format, where each sprite is just rows of text where each character is a color and a dot means transparent. This is the coolest part as the engine will think the dots are transparent and there won’t be a big black box dragging the sprite around. And, if I wanted to flip the sprite around, I could just reverse the rows with numpy. There was a stupid bug where I kept getting a Screen object has no attribute spr error, an I couldn’t find out why. But, I realized that I wrote the method in the wrong file. But, after fixing that error, the program worked!

What’s Next?

Next up, we are adding text. Every game engine needs text and next up, we are adding that. See you next time!

Devlog #1.3: Let there be Movement!

Hey everyone! In this devlog, I added movement to our game engine: Olympus!

New functions!

I created two new functions: btn() and btnp().

btn() is for when the key on your keyboard will be held down. This can be used for movement.

btnp() is for when the key is only going to be pressed once. This can be used for actions such as jumping, shooting, or confirming something in the game.

How does the movement work?

An objects position is two variables: px and py. px is the x-axis (left and right) and py is the y-axis (up and down). If you remember from algebra, when you subtract your initial position in the x-axis, you move to the left and when you add your initial position in the x-axis, you move right. The same applys for the y-axis. If you subtract, you move down. If you add, you go up. So, we check the keys using the btn() function. So, if btn(LEFT) == True when the left arrow is held, it will subtract from px on whatever value you want and it will move the character that way.

What’s next?

That’s it for today’s devlog. Tomorrow, I hope to finally implement sprites into the game, so you can add custom models instead of using just circles and squares. See you later!

Devlog #1.2: Adding Elements One Shape at a Time!

Hey everyone, devlog #2! This week I added the first real drawing tools to the engine: lines,rectangles, and circles, all from scratch, no graphics library. Here’s how each shape works:

Lines

Lines use the Bresenham algorithm, which is an algorithm which finds the best way to create a straight line between two points. At first, I tried using the built-in SDL2 Line function, but it would produce choppy lines that wouldn’t be a straight, full line (see screenshot below). But, after implementing the Bresenham algorithm, it worked perfectly! Lines can be called using the line() function.

Rectangles

For Rectangles, I created two new functions. rectfill() and rect(). For rectfill(), I just hand to numpy to fill a whole block at once. For rect(), I just use the line() function 4 times to create the rectangle.

Circles

Circles use the midpoint method. The circles gave me the most trouble. My filled circle used different math than the outline, so it grew these weird single-pixel spikes around the edge (before pic). The fix was making the fill reuse the exact same midpoint math as the outline, so they finally match (after pic).

What’s Next?

In order for a game to work, we need the player to control something. So, the next step is adding movement. See you in the next devlog!

Devlog #1.1: The Start of a Long Climb!

Hey everyone! Starting a new project: Olympus, a little game engine like PICO-8, built from scratch in Python.

What I’ve Done So Far:

So far I’ve got a window opening and my 16-color palette working. The annoying part was SDL2. I’m using it raw through ctypes, so it wants C-style byte strings and pointers everywhere, and I spent way too long just getting a blank window to show up without crashing. It works now though in the screenshot below.

What’s Next?

Next up: drawing actual shapes onto it. I’ve already tried implementing lines in the screenshot below, but it isn’t working currently. Hopefully in the next devlog, I can get it to work!