next »

[Octopus Tophat]

100th POST! WOOO!

For the past week, all I've been doing is trying different lighting techniques to see what's fastest. I need to get it working in real time. I think I'm getting close! 

This was one of the versions that looked nice, but was way too slow.
I looped around the area of the light, and looked at each block of light, and compared each of the RGB values of it with the 4 blocks surrounding it.
So one tile was like this:
-Check right red value
-Check right green value
-Check right blue value
and repeat for all 4 directions.
If a neighbor was empty, it'd set it to the parent color and subtract some brightness.
If a neighbor was not empty, but had a lower light value, it would blend some of the parent color into it.
You can see the green and red blend really well, but it's really slow to loop through that many array checks.
This was definitely a no-go .

So my focus was:
     -Make less redundant checks
     -Don't have separate checks for each individual color
     -I don't want to check empty spots, I just want to update spots that are known to have light

So I started thinking, "what if I store the coordinates for spots that have some sort of light level, then just loop through those instead of looping through a big area?"

My solution was to have a stack that stores an index, and an x and y value, so I could loop through the stack and figure out which spot I need to check next. If that spot can spread, spread the light 1 space in that direction, and add that spot to the stack. This is what it looks like:

This runs amazingly quicker. It doesn't have color yet, but it will be simple, I just haven't gotten around to doing it yet.
The number in the middle-bottom-left is the stack index.

This whole process will happen in 1 frame, or maybe I'll drag it out over a few frames and draw them when it's done. But it will be real time either way. Lights will be able to move.

The blur effect will be on, unless you choose to have lower graphics settings. This really helps with making the lighting seamless. It is tile-based, obviously, but when it's blurred, you can't even tell.

This is what it looks like with more lights, if you were curious. Notice how much less checks there are when lights are close, the last one had very few checks compared to the others. Efficient!  Also notice how much the stack increases when I add more lights. Those lights will all be updated once the stack reaches them.

*this gif is pretty long.... I'll start using videos soon*

This was a super frustrating week for me  , but I'm definitely making progress. I might be able to make it even faster! 

[Cakeprediction]

those effects look pretty nice
One thing I just noticed that kinda bothers me though, is that the healthbar in the gifs is way too small in comparison with the screen. If you're doing that to have as little hud as possible, it might just be nice for players to be able to toggle between this one and a bigger one. Just a random nitpick of mine though

[Octopus Tophat]

those effects look pretty nice
One thing I just noticed that kinda bothers me though, is that the healthbar in the gifs is way too small in comparison with the screen. If you're doing that to have as little hud as possible, it might just be nice for players to be able to toggle between this one and a bigger one. Just a random nitpick of mine though

Oh yeah, the health bar will be twice the size it is now. I just have to change a few values to get everything to line up. I just haven't done it yet. There will also be a lot more hud elements. I just removed all the "fake" ones. The ones that I had in older gifs were just drawn on. They didn't actually work.

I'll be adding more hud stuff soon, probably. The minimap will be fun to make.

[Recs]

following, very interesting woork, I enjoyed tower climb as well.

[Octopus Tophat]

CHUNKY CHUNKS!

I've implemented a chunk system.

(THE LEVEL SHOWN IS COMPLETE NONSENSE RANDOM CRAP. THE LEVELS WILL NOT LOOK LIKE THIS)

This means that the level is loaded as you move, and gives levels unlimited size.
I don't mean levels go on forever, I mean there is no limit for how big a level can be. A 10 by 10 level runs just as fast as a 10000 by 10000 level.

Each chunk has 3 layers. A background layer (which is just a solid color in the gif, so you can differentiate the chunks), a foreground layer, and a lighting layer. The sprites/other game objects are placed in a layer between the background and foreground layers.

No chunks are actually created or destroyed. They just jump over to the other side of the screen when out of view, like a conveyor belt. The chunks are textures, so when one of them jumps, it calls an update, and draws all the terrain, borders, and static decals to the textures. Dynamic decals (like torches, mushrooms, and grass) and entities/enemies are just spawned as sprites, and are linked to the chunk that created them. When the linked chunk gets another update, the old decals/entities/enemies are destroyed and the states they left off in are saved in data. So if you damage an enemy, and come back to it later, it'll still be hurt. (The enemies are persistant, unlike terraria. They don't just spawn randomly and despawn when far enough off screen. Levels are generated with enemies placed, and they don't go away until they're killed.)

At the normal zoom level, you won't notice the chunks being loaded. As far as you can tell, the world is just really big. If I add items/events where the camera zooms out, I could always add more chunks.

The process of drawing the textures is dragged out over a few passes so the framerate doesn't get a sudden dip. For the foreground layer, the first pass is the tiles. Then it draws out the tile borders. Then it draws decals. Fourth pass spawns the dynamic decals. And fifth pass spawns entities/enemies. If a chunk is on screen before all the passes are finished (if the player is moving really fast), the rest of the updating will finish on that frame. The background layer works pretty much the same minus the entity spawning.

The lighting layer draws a region of the lightmap to a low res texture, and scales it up to fit the chunk. 1 block of light=1 pixel. (the lighting layer isn't shown in this gif but it does work, I promise)

Anytime the lighting in a chunk changes, it will call an update. Same goes for when you blow up a block. The chunk has to be re-drawn.

I can also dynamically change the chunk system just by changing a couple of values. I don't know if there would be any actual point to doing this while the game is running, but I can change the size of the chunks, as well as the width and height of the "chunk grid".
The setup I have in the gif is a chunk size of 10 (10 by 10 tiles) and a grid width of 5 (5 chunks from left to right), and height 3 (3 chunks up and down). Basically I made it adjust to what ever values I give it, just to see what gives the best performance. If the chunk sizes are too high, they take a while to load, but I only need to load chunks when the player has moved a fair bit. If the chunk sizes are too low, they are quick to load, but I practically have to load a whole new row when the player jumps. Finding a good balance will be hard.

Even for small levels, this chunk system makes the game run a lot faster. Previously I had on average ~20,000 objects, now I have about 230. LOL. And I can make the levels absolutely MASSIVE. I'm only limited by ram. TROLOLOLOLOL.   

Now that I think about it, it might be a good idea to mention that the chunks aren't generating the terrain. The chunks just "display" the terrain. The whole level is created before you enter the level.
So in that sense, it doesn't work like minecraft(generating the world as you move), it works like terraria(generating the whole world before you play). If you return back to a spot in the level, it'll be exactly the same.

[mokesmoe]

For the towerfall lighting:

You need to use a separate surface for all of your game that should be affected my lighting, then apply your lighting to just that surface. You will need to use a shader or maybe a blend mode to keep the transparency intact, but then you can just draw that whole layer over your background to have a lighting affected layer over a non-lighting background.

Here's a quick example of the process I drew up in a minute:

[Octopus Tophat]

Thanks mokes, but I already solved the problem. Someone wrote a shader for me.
It's not shown in the recent gifs, because they've all had completely filled backgrounds, but if I were to remove one of the background tiles, you'd see that the "far background" is lit regardless of the light in front of it.

Beautiful drawing by the way.

[Octopus Tophat]

Ok I have some big news.
I'm porting the game to gamemaker studio.
This means I have to remake the whole game. Woohoo! 
I was having problems with getting the lightmap working in construct, and I realized that construct actually has an un-fixable problem with drawing textures. This was heart-breaking for me, and EXTREMELY frustrating. But I'm not giving up. I looked into game maker, and it just seems so much more superior, so I decided to use it. Plus you can actually write code in gamemaker. It's not just drag and drop, like construct.

Not only does this mean lightmaps will work properly, like I want them to. It also means I can do a lot more things, like online multiplayer, which isn't possible in construct. It also means the game will run better, (I think). Construct is very dated software, so I'm sure game maker is better optimized for today's hardware. I can also write my own shaders easily, and more easily manage objects. Scripts are also really handy in game maker. Rather than have all my physics objects being one object with many different sprites, I can actually make them seperate objects and run the physics script on them. This shit is amazing!

Here's where I'm at so far. Please note I've just been spending a lot of time learning how game maker works. I haven't actually  gotten that much work done. For this new version of rogueworld, I decided to first work on the physics. I will be using verlet integration instead of euler, and this should allow more interesting object interactions.

This was all written from scratch, I'm not using the built in box2D physics.


I wanted to do these kinds of physics originally, but with construct, when you detect collisions between two of the same objects, you can't specify which instance you want to alter. Any instructions you give after the collision event will apply to both of them. Game maker has an "other" keyword, which makes this possible. I'm already loving GM.

This'll mean that all objects, like coins/enemies/items/guns will be able to interact with each other and bounce around/pile up. Fun fun fun! After I implement quad trees, I should be able to have tons of objects moving around. I might even be able to simulate water!

I'm excited to see what game maker is capable of. This is a huge step for the development in rogueworld. I only have to port the code and sprites over. It shouldn't be too much work getting the game the way it used to be.

[mk]

Wow, it's really a big news. Good luck to you!  

[Crabby]

Gamemaker Studio is awesome. The physics are pretty cool looking too!

[Octopus Tophat]

New song for the Bitlands dungeon!

Here's a song I wrote 2 nights ago.
I also just made my soundcloud profile, so now I don't have to fill my dropbox with songs. Woot!

[Octopus Tophat]

I've re-added climbing to the game and made collision detection 100% perfect. (You will only be able to climb on walls/ceilings with a grabbable surface, otherwise the player would have too much freedom  )
Collisions with other entities (well, for now the player is the only entity) aren't totally perfect yet, and they never will be, but they should improve over time.

I've been real busy with my job, so I haven't made much progress, but I've come up with some fun new ideas for the future.
I'm planning on making a complex rope/tether system, where I can make dynamic ropes for objects/enemies/traps/hazards. They will bend around terrain, pull on objects, and do all sorts of cool stuff. I want it to be really dynamic, so you could like grapple two enemies together, and pull them together, or grapple a spike, and reel it just enough to swing it around you to hurt enemies.
Here's some more examples horribly drawn in paint.


A.Vines that the player can bounce on. Depending on what angle the vine is at/the position of the player on the vine, the trajectory of the player will change. And you can bounce on them to gain more height like in mario sunshine.
B.Jungle explody things. I have a gif of these if you look back a bit. But I had an idea to make them grabbable. You have to pry them off the wall, then you can use them as grenades. I think it'll be really satisfying to do this. It'd also put a bit of strain on the player, so you really have to pull on them.
C.Using grappling hooks to pull an enemy into spikes. You could also then pull the body out, and do something with it (I'm not sure if you'll be able to loot bodies, or something like that yet)

This rope system will be hard to make, but I'll use it all over the damn place! I can tell it'll be fun! 

[Octopus Tophat]

Hey.

I just wanted to announce that rogueworld is gonna be on hold for just a bit. I'm working on a small mobile game with my sister.
I might put up a devlog at some point.

Once it's done, I'll get back here to my "real" project 

[gimymblert]

o

[Octopus Tophat]

I know this isn't much, but I'm really excited that I got this working.
Rigid connections between objects! PHYSICS!

[Octopus Tophat]

*Gif*


Surprise! It's been 3 years since my last post and I've been working on the game this whole time! I'm just too lazy to post, cause a lot of the changes haven't been visual, until recently.

My birthday is tomorrow (I'll be 23), and it's given me thoughts of how much I've learned since I started working on this when I was 18. My code has gotten much cleaner. I've learned about shaders, optimizing, game design, physics engine programming, making better music, sound design, the list goes on.

I'll talk about one thing to get myself back in the swing of things here on TIG- Physics.

The physics engine has improved immensely. It's much more optimized than before as I've implemented a resting system and spatial hashing. All objects collide with each other and can have different collision behaviors, like mushrooms launching objects into the air. I'm introducing polygon collisions as well. My engine has support for AABB's, circles, and polygons.
I don't want all objects to rotate, because I still want some of that old school charm. Like, you can stack crates without them falling over, and make a stair case or something if you want. I think that's more fun than wrestling with boxes that won't stay stable... but that's just me! So AABB's will stick around.

This opens up the possibility for super interesting object behaviors, like Breath of the Wild.
If something makes sense to you, it should work in the game. Shoot your gun into a mushroom to bounce the bullets to hit a hard to reach enemy. Jump on the mushroom, then shoot down so the bullet comes back to you and damages you, but knocks you higher into the air. Push an enemy into bramble so it gets hurt. All objects also have the ability to damage enemies based on the weight to velocity ratio, unless specified not to. Throw a rock at a thornbulb to set it off and have thorns spray all over the place, damaging the enemies they hit. You can set up some interesting chains of events.

That's just a small portion of what's been new in the game. If anyone has seen this devlog before, I'd like to welcome you back and thank you very much for sticking around with me! More to come soon! 

Edit: Some stuff in the gif is a little weird now that I think about it, but I've been so used to seeing it that I don't notice it. There's no chest-opening animation, the trees have no tops... Just try to ignore that stuff lol.

[alvarop]

Incredible jump from your last post to this one lol.

Your game is looking great

[Kyzrati]

Whoa

Congratulations on what has apparently been a very good few years!

[flex$]

holy shit dude. after essentially losing your progress, you re-made the game in GM:S and came back three years later with an update to the project... that's awesome and inspiring to me, dude. i'll be checking back here. glad you didn't give up.

[Octopus Tophat]

Thanks so much guys!
Very honored to have the creator of cogmind seeing my game 

holy shit dude. after essentially losing your progress, you re-made the game in GM:S and came back three years later with an update to the project... that's awesome and inspiring to me, dude. i'll be checking back here. glad you didn't give up.

Yeah I'm resilient, haha. This game will get done! Thanks for the kind words