Purchased! Thank you :)
Recent community posts
Hi! Thanks a lot for the updates lately. I've used Pixel Fireplace since 2015 when I started college, and it's been around way before that so it's great to see it not fall into software hell.
I hate requesting features for software I purchased years ago, but I noticed that GMS2 now supports ARM builds for Linux; any chance to get a build to run on a raspberry-pi? That would open up so many avenues to run it standalone in custom cabinets, and I would personally love to build a physical, portable pixel-fireplace to keep running in the living room.
Anyways, thanks for all the good work and for building a staple in indie-dev culture!
This is a pretty solid platformer! The controls feel great and the camera control is really helpful. That being said, I'd seriously suggest adding some checkpoints or splitting this into separate levels. The difficulty ramps up quickly and having to re-start from the beginning is quite demotivating.
Can't wait to play the finished version though!
Thank you! I had a tight self imposed deadline and a lot of stuff on my plate so it's great to see that the ideas still made their way through to the player.
Wish I had more time to flesh them out, but I'm pretty happy with what came out :D
My name is Gabe. Last Monday I decided to make and release a game within the week for fun, so with a little help from my friends I made a game called TIME LOOP. It's a short and sweet platformer about running away from time loop doubles. The game runs right in the browser and I would be more than happy if you checked it out!
You can play it here: https://elgabe.itch.io/time-loop
Here is a smol video showing some interesting gameplay bits:
I also made a devlog about it. That video will be edited and uploaded soon™
You are fundamentally wrong. FPS has everything to do with, well, everything. Games need math to be calculated every frame, the time the frame takes to calculate changes how you perceive the game. For example, if you didn't implement a delta time into your movement code, your character's speed would be frame-dependent, which would make it run slower or faster on different computers.
Same thing goes for collisions. If your computer didn't check for a collision on time, you might get that collision checked after you moved into a wall, which is how you get characters clipping into walls and then being pushed away. This post has a pretty good fix for that.
I recommend you don't criticize people's post when they're trying to help others, unless the information is wrong. But that requires you to double, triple, quadruple check your criticism.
It's Sunday so I decided to make an HTML5 version of my game "HellHole". You don't have to download it to play, but I still recommend it!
HellHole is a top-down shooter where you use your soul to kill demons and dodge saw blades. Trick is, you can only move while you're not shooting.
Here's a saucy gif:
You can find the game here: https://elgabe.itch.io/hellhole
Hope you have fun!
I'm having a similar problem using Windows 10, Chrome version 70.0.3538.102. The UI (Chrome and Bitsy) works just fine, but the controls are delayed by almost a full second, making Bitsy games unplayable :(
Hopefully this problem can be solved soon.
When I start Left, it opens with the developer tools shown:
It's not a huge problem as I can just close the developer window and use left as normal, but I think it's something worth fixing.
Also, thanks for making this, it's my go-to text editor for game design notes!
Thanks for playing! I'm glad you picked up on the altar thing!
Yeah I meant to polish the bad ending a bit, but the idea was a one day build and I'm just figuring this Bitsy thing out.
I learned about the GDWC a while ago, and I've been working on something ever since. Hopefully I'll enter next time!
This Is The Game:
That's the main mechanic, toggling a light on and off to interact with a different version of the level. It's a really cool thing that I first built in about 30 minutes for a class in college and now turned into a full project that I intend to finish before the end of summer.
The light itself is just a circle with a little shader to make it wobble and a destination out blending mode applied to it. That blending mode allows the sprite to "pierce" through the first layer and show the layer behind it or, as I call it, the other dimension. To organize the collisions, I just change a "solid" property on the collision boxes depending on whether the light is on or off. Like I said, it's a simple mechanic.
What I did not expect, however, is how complex the level design process is. Every time I decide to create a new level I have to sketch two, one for the top layer, and one for the bottom (or hidden) layer. Not only that, the two layers must interact with each other. It's not just about making two levels per "screen", but about creating a little story about how each dimension exists within the game world. A level is not good unless there is a "oh shit" moment when the player sees how that inter-dimensional iteration looks. AKA, the moment the puzzle is solved because the player sees that they're dealing with two worlds at once (as you can see in the image above).
A bad example of level design is the image below. Even though I think it looks cool, the two layers have almost no interaction with each other, they just exist there. Separately.
So yeah, this devlog is just me venting about how a simple idea can turn into a design nightmare. But I'm having fun making this game! All the menus are done and now I just have to focus on level design and adding some other mechanics I have in mind that play off the light and collisions.
If you read this all the way through, thanks! I'm planning on writing more of these to keep me on track and active in the game's development.
Of course, you can follow me on Twitter for smaller bits of progress and screenshots: @elDaddyGabe.
I was in the red-colored world and ended up pressing the "A" key by accident, which brought me back a couple of levels. That didn't bother me at all, so I decided to explore what other keys did unexpected things, that led me to press the "1" key, and that brought me to the very beginning of the game.
My question is, why does the "1" key do that, and the other number keys don't take me to previous levels I've finished? Also, If there is a go back/skip level button, I would explain those in a simple README.txt document.
Last thing, the speed-run and practice keys don't seems to work, is that because I must beat the game before using them?
Thanks for your time, and this is a great game!
If you don't know me, my name is Gabe, nice to meet you. I've been making games for a while now but they are usually very small, tightly looped arcade games that I pump out in a couple of hours and polish over a week or a month (i.e: CrossedFire). This time I wanted to make something a bit more... linear? By that I mean: A game that has levels, a beginning and end.
The mechanics so far consist of moving around and dodging sea mines, shooting at the mines to relocate them (before they explode of course) and juggling the shooting with the knock-back from the bullets. It's still very early so I might cut stuff, or add things (probably the latter).
The thing about this game is that I want it to be both linear and level-based, but open as well. What that means is that the game is organized by levels, but the levels are organized around the world, just out there in the open. Think of it as a top-down metroidvania, but with no walls. The levels are (will be) recognizable areas around a big-ish world map and players will be able to just move around them freely, so that there's no order to complete the game and it'll be as hard as you want it to.
Right now I'm focusing on designing and developing basic systems such as shooting, moving, camera motion, mine physics, etc... I'm hoping finishing most of the mechanics will make it easier for me to understand how they interact with each other and design levels that take full advantage of that. The biggest challenges so far are how to make the levels recognizable and open, how to make the background a bit more varied (mostly because seeing movement is hard if there's no point of reference) and how to keep it all within one color palette.
So yeah, that's pretty much it for now. I'll try to make this game in a month, but I don't think that's a realistic expectation since I'm a one-man-army and have college things to do. I'm thinking about making a PC version and mobile versions as well, mostly because I've never worked with touch controls. Until then, you can follow me on itch.io and twitter for screenshots, gifs, devlogs and, of course, the game once it's finished. I'll leave you with a little dramatic (probably a thumbnail) image:
Tanks for reading and see you soon,
I've been working on this little game as a distraction from college stuff and, for once, I finished it: https://gabed.itch.io/crossed-fire
Crossed Fire is an arcade hypercolor game about reaction, timing and, most importantly, use of the game's mechanics. There is a wide variety of moves you have to survive long enough to get the white box on top of the screen: Double Jumping, Wall Sliding, Controlled Jumping and Bullet Hopping.
Give it a try, it's crazy hard and you might like it, or hate me for even making it.
About 3 months ago I decided to make 3 games about jumping. And no, i didn't make a Mario-like platformer, it was more about how I would make a one-screen arcade game where all you do is jump. The first game was trash, it was me trying to make flappy bird without making flappy bird if that makes any sense. The second game was about you bouncing between two walls and avoiding rockets and saw blades, it was interesting. The third one was a bit better in my opinion. It was about timing your jumps to two bullets on both sides of the screen and hitting a box on the top part of the screen.
Timing the jumps to those bullets was quite enjoyable to me, but it was still -essentially- the same "flappy bird" mechanic as before, so I deiced to add something to make your choice of jumping matter: A big fucking laser. The bullets fire at a constant time, but the laser is random.
Why? If all you have to do is worry about counting to 2 and jumping to score a point, the game gets boring in 10 seconds. But with one element of randomness in the consistency of the rest, the game gets interesting and hard, very hard. Suddenly you have to worry about timing AND reaction. You can't just count anymore, and that's fun. But one thing isn't: Unexpected deaths. The laser is fast, so fast that reacting is hard (not impossible, but hard) and I realized people would die and ask themselves "what happened?" and you never want to confuse players! If they don't think the game is fair, they'll walk away. The obvious solution to that is, well, a warning. Something as simple as a "hey! Something is about to happen!" was enough for people to understand that they might not want to jump super high right then. Sure, they didn't know what it meant the first time, but I'm counting on it; They need to die in order to learn the rules of the game.
I also thought the game needed more cool stuff. What are cool stuff? any mechanic that makes interacting with the world fun. in this case, that would be wall sliding and bullet hopping. Wall sliding is just what it sounds like: You slide on walls and fall slower. that helps to control where and when you'll land so you can avoid getting hit as you fall, pretty simple. The other, bullet hopping is more complex. Basically, if you jump directly on top of a bullet, you'll bounce off of it. That allows all sorts of neat things to happen, for example, if you keep moving to the same direction as the bullet you'll "surf" on it; If you hold the jump key when you bounce, you'll bounce higher and when you bounce, you get an extra jump. But this is a risky thing to do, it's very likely that you'll just hit the side of the bullet and die. That means this mechanic is more about player expression than an advantage, you can play it safe and just jump normally and wait, or you can look cool AF and do all these tricks.
Time To Die
Another important thing to think about is TUD, or time until death (fancy name I made up). That is: How long until the player dies, and how long until they get back on the game? This is not a hard concept, the quicker you die, the quicker you should be able to just jump right in again. Think about Super Meat Boy or Hotline Miami and how fast things feel, partly because you restart the level almost instantly. In my game, I wanted you to restart so fast, you wouldn't have time to consider stop playing. At one point, pressing the space bar becomes instinct, so when you die, you automatically press it and restart. But the restart button isn't a specific key really, outside of the escape and enter keys, any key will restart the game, so you could restart the game by accident and, funny enough, players that do that will likely just say "OK, one more" which works for me.
And this is pretty much it, the design of a *very* simple game. It's amazing what you can do with a simple starting mechanic, a combination of timed consistency and randomness and some cool player expression stuff in your game. The visual style was just a color combination that I thought looked cool really, I just wanted a clear difference between you, the space and the bullets so that even if you're squinting at the screen (or drunk) you can tell what's what.
The game will release later this week, I'm just fixing some high-score related stuff and adding a button to send people's high score to me over twitter if they want, since the game is fucking hard.
Thanks for reading this long post!
OK. I'm not talking about you (necessarily). It's just a thought that I've had for a while: A lot of indie developers make these games that are super fancy and "elegant" because that's what they think indie is supposed to be about. The term "art game" or the phrase "it's not a game, it's an experience" makes me wonder if these developers realize that some people's negative reaction might just be because the game is not fun, or engaging. I'm not suggesting that every game should be fun, or just a rogue-like top-down shooter, but I disagree with the mentality of "if it's not 'artsy', it's not worth it". I believe that some games should be considered art, like Gone Home. But I also believe that some game should just be fun, like the newly released High Hell and there's space for both of these types, it just depends on what kind of game you want to make. This got started as an argument I had with a colleague about how art games try to be smart and how often that gets in the way of an enjoyable experience, so I would love to hear your opinion on this: Are indie game supposed to shoot for the moon in terms of narrative and "artsyness", or are they supposed to be entertaining and just fun?
Hey all! Me and the friend who did the art for the game decided to talk about remaking this game as a full browser game with more shooting types, enemies, and other potentially secret stuff since a lot of people asked for a fully fleshed out version.
Thanks for playing and leaving comments :D
If you have any projects in development and want feedback or even some help (I don't charge for help), feel free to send me a message!
I exist here: