We all know the single greatest limitation of Gimkit is memory the inability to move things to non-predetermined locations. Imagine if we were able to move props, sentries, even the player to the right or left or up or down whenever we wanted?
Unfortunately, we can’t, and that is just an inherent aspect of Gimkit.
BUT! What if we didn’t have to interact with the player? Or props? Or sentries? What if we could just… make them ourselves?
A while back, I saw and contributed to this topic: Pseudo Player Model
In it, we devised a rudimentary system for tracking and displaying a version of the player.
If we changed the grid system used to display the player to text, we could easily manipulate what is displayed for the cheap price of one block per row.
This way, we could essentially build our own game engine within GKC. We can store the location of anything we want in the grid and move it freely, weather it’s actually in the gimkit map or not. This allows for a ton of cool game ideas:
Vampire Survivors
Puzzle games like Patrick’s Parabox
Open world games with enemies that move like the original Legend of Zelda
Fighting games with interesting moves
And lots more! Virtually anything is possible.
Different objects could be represented by different letters, and empty space could be represented by a character that’s unaffected by text color like .
If anyone wants to throw together a system like this, I’d love to see it!
See, normally I’d take a shot at building this myself. HOWEVER, I’m in the middle of building a visual novel in Gimkit, and then I’m gonna write a guide on how I did it, which is gonna be a lot. This was just a really neat idea I had that I think has a lot of potential. I just wanted to get it out there.
I probably won’t be able to contribute much, but you can always ping me if you need help!
You could use pixel art, but that’d be difficult, and detailed pixel art would end up taking a lot of space, meaning less room for the actual gameplay. I was thinking representing the player with a single character, like just the letter P.
Remember, text properties are only 256 characters long, which means 256 columns, and the number of rows is limited by memory, as we need a text device with a block and a property for each row. 100 rows would be ~55% memory, and that would be encroaching a little too far on the 128 property limit.
If we’re actually moving things around, then every text device needs a block, as I said in the post you were commenting on.
That’s what you need to track the player. In order to let the player move and have their change in location update the text display, you have to change the text in the display. The only way to change the text in a text device is through blocks.
That’s what I said.
I have an idea as to how it would be done, but I don’t have the time to make it. I actually think using solely square emojis like would make the most sense, as it allows for simple, small pixel art. One thing to note is that every character used in the array has to be the same size so that the rows don’t become misaligned.
you could most likely use text blocks in a text device to make a pixel moving around for a player, but a problem with emojis are that they have gaps
Unicode could be better but Unicode is uncolored
I also have no idea how to do this but I think it would be possible
sincerest apologies, I read through but I guess I didn’t notice that.
but as I said I think emojis would be the only way to do this. could you try to explain your idea to me so I could try it?
@some_kid, the reason I was concerned that emojis have gaps is because for the pseudo player model, you have to move and the player could show through
hmmm… if this is what we’re thinking, couldn’t we make a system to transfer the player x and y properties into a substring input that we could change that emoji to?
we would also have to reset the text before we do this but i’m unsure if we could make multiple lines that way
You’re on the right track, I think.
When the player moves, it updates their coordinates, which would then broadcast to a block. The block would then determine which text device to broadcast too based on the y-coordinate. That text device would then change one of its characters based off of the x-coordinate.
Also, the gaps in the text don’t matter because the player themselves can be anywhere, and we can just offset the actual coordinates based on how far away they are from the text array.
I actually built a very similar system to what’s in the guide very recently! The input method is actually completely identical.
However, Fulcrum didn’t really tell us exactly how we could implement a system like this to our advantage because that wasn’t what the guide was for. I also happen to just not really like how that input system feels, especially in the context of something like a fighting game. He made that guide before the coordinate device was out, and I’ve been hoping that the coordinate device would feel more consistent.
I don’t think we’d use anything in that guide. We would probably use a coordinate system more along the lines with what we had in Pseudo Player Model. This would let us more easily change player speed and add platformer physics, since those are built-in to Gimkit’s movement system.
I may be just throwing something into the open and it just falls flat but. what if we didn’t need to track the player we make, but have the environment move instead.
basically what I’m saying is have the area around the player be tiles, and do tile scrolling.
now I cant exactly say how it works without it being confusing though, but if this works you basically could do anything with it.
That’s actually a great idea. I made something similar for a game in python graphics once. This is basically how you’d do a side-scrolling platformer. The text interface would let us have more interesting enemies and mechanics.
.
would make the most sense, as it allows for simple, small pixel art. One thing to note is that every character used in the array has to be the same size so that the rows don’t become misaligned.