In response to Bravo1
Stop, I can only get but so excited!


Need to work out some of the kinks but this creature's almost finished.

Edit: Nothing new to show specifically but I've gotten a lot of added functionality/fixes and I wanted to talk about them. I'm also doing it as an edit because I dislike double posting.

This creature: It's not finished just yet, but it's almost done. I still have to work in a better pathfinding for it as it currently just follows the player in a very hacky way. Once that's done I should be able to wrap it up and finalize its design. One thing I have done additionally with it is add a smoke effect that billows off of its body. I always wanted this thing to be like a cloud of darkness with eyes and legs poking through. The body is going to remain as it is, but with the smoke, its form is obscured a bit, adding to the mystery.

Bugs: I noticed an issue with my effects system, which has come back in full force since I thought I fixed it a while back. When adding and removing vis_contents very rapidly and in and out of the players' view, it seems to cause a weird artifacting effect where some vis_contents are duplicated, as if the object has multiple vis_locs even though it only has one. It's incredibly frustrating so I dropped using vis_contents entirely and reverted back to using images. They aren't as CPU efficient as vis_contents, but I did rework the pooling system for the effects and the end result is overall the same on CPU but without all the obnoxious buggy behaviors. I'd get a proper bug report together for LummoxJR but I just can't replicate it outside of the game. =(

New implementation: I've got a new system for handling plane_masters all at once that I like to call plane_god. It's an invisible object that attaches to the player, and all the plane_masters are images attached to that object. This lets me modify all the plane_master's transforms, colors, filters, etc. by modifying those attributes of plane_god. It all looks the same as before, but it's far more efficient and reliable than the system I had before which was to loop through a list of all the plane_masters the player was using and apply the changes to each individually. It worked but it was susceptible to fall out of alignment in rare cases. I had means to correct those misalignments, but now I don't need them.

I've also managed to get the map loading system working so I should be able to load and unload large rooms and/or areas instead of having the entire game world loaded all at once. This should cut down significantly on future CPU and RAM usage as having enemies offscreen but disabled still causes CPU spikes when they run their wake checks.

As for how this will affect players... That's something I need to discuss with the community. I'm not going to be able to load/unload areas as evenly as I was with Lux, mainly because this is a co-op multiplayer game, even though you can play it alone. The way Lux worked was that when you loaded into a room, all the rooms connected to that room would be loaded, and any rooms not connected would be unloaded. This meant that you wouldn't ever really notice load times because they happened in the background while you moved from room to room, since any room that you could move into would already be loaded by the time you reached its door.

I can't really do that for Dark Star though, as I want larger "rooms" in general, effectively loading entire large blocks all at once, and I don't want the players getting to far from one another. Last thing I want is to have the game track and load/unload all the areas connected to each player. In many cases, that would cause far more to be loaded at any given time since the players can split up, resulting in dozens Z levels being loaded and unloaded at once, and then I also have to avoid conflicts where players try to load the same areas at the same time... ehhh.

Instead I'm thinking more of a Borderlands approach, where the larger areas means less traveling to and from, and zone transfers are handled so that the players all see a loading screen and are pulled to the area together as a group. I'd implement the same safeties as Borderlands does where being in a menu or being downed would stop the countdown to move areas.

That's all I have to rant about for now, sorry for the wall of text, but I managed to get a lot of work done fairly quietly and I wanted to talk about it. =P
I made an update to a few of my libraries.

KaioCode has been fully pulled apart into separate hubs; some of which aren't even published yet.
It's now just a library that includes a bunch of libraries, with no code of its own. Aside from some name changes, everything should be backwards-compatible, assuming BYOND installs dependencies properly.

- Vector2 is now its own library. Full operator support as well as interactions with /matrix. Would like to see this optimized and built into BYOND someday.

- Pixel Movement is its own hub and includes procs such as PixelMove and SetCenterTo. Naturally, it supports sub-pixel movement, as that's now built-into the engine. What's not built-in... are all these libraries.

- Button Tracker received events. This is used by Any Macro and Mouse Buttons to track the state of the buttons on your keyboard, gamepads, and mouse.

- Button Timer is what used to be the "TimerButtonTracker" in KaioCode. Instead of overriding /button_tracker and replacing client.macros/mouse_buttons with it, you can now just attach a /button_timer to your existing /button_tracker to time your button presses and trigger an OnRepeat event every tick while any buttons are pressed.

- Mouse Position received events and vector2 integration (Position, WorldPosition).
It now supports the isometric map format: https://streamable.com/4d1ya (this demo not included)
And it allows for passing the transform of your world plane master, so you can get the mouse's position in the world even when the world plane is transformed, such as in zooming and rotating (see video at the bottom for an example of this).

- Pixel Positions received vector2 integration (LowerPosition, CenterPosition).

- KaioCode Demos is now on its own hub with some updates and new features:

Move To Mouse now has an arrow pointing to where you're going:
https://streamable.com/wcej4

And so does Move Toward Mouse:
https://streamable.com/f2g0f

CarMovement was renamed to TankControls because that fits better:
https://streamable.com/t8e78

TopDownShooter received a couple other example guns: a semi-auto pistol and 3-round-burst rifle.

You can very easily include TopDownShooter on top of TankControls, as well as other features, such as:
- CameraTurning (rotates the world plane to match your "forward" direction)
- SpeedZoom (scales the world plane to match your velocity)
by simply checking the box to include the file. There are many file combinations you can try that function as expected, since it's about as modular as it should be.
https://streamable.com/z3pwe

Decided to do a quick mock-up of what some areas can look like. I'll have to take the time to turn a lot of these objects into separate items to use when mapping to make it easier to add some flair. Currently, nearly everything seen in this room is part of a single image. The walls also need an update where the player will be able to see through them a bit which helps with the feeling of depth, but I haven't gotten around to mocking up some art for that just yet.

The concept of the room: You've smashed your infiltration pod into the side of the station in order to enter quickly, avoiding the hordes of creatures that have set up near the docking bays. Automatic foam seals the edges of the hole made by your capsule, and the damage caused by your insertion appears minima. Unfortunately, the small office is the scene of something gruesome, as the splash of the blood on the wall paints a picture of what's to come once you leave the room and head into Idaho Station proper.
I love the laptop shining light on the wall. Also the whole thing reminds me a little of the art style in Flashback, which is awesome
1
Awesome work Gold94 :o :o
I wrote a big post but Byond logged me out in the time between typing it and hitting save so I guess I'm just going to stick this here...



These are the kinds of things we knew were possible as soon as vis_contents was released, but I haven't seen anyone bother to actually do it yet:



vis_contents makes the world go round. The visible part of the boat is actually on another z-level.



Round and round and round. Basically, turfs at the world edges have the turfs on the opposite edge in their vis_contents.
In response to Bravo1
That's why I always write long posts in Notepad/Notepad ++ and then paste them in when I'm done. Typing in browsers is really fucking finnicky.
In response to Kaiochao
Kaiochao wrote:
These are the kinds of things we knew were possible as soon as vis_contents was released, but I haven't seen anyone bother to actually do it yet:


vis_contents makes the world go round. The visible part of the boat is actually on another z-level.


Round and round and round. Basically, turfs at the world edges have the turfs on the opposite edge in their vis_contents.

Can you explain round and round a bit more? My brain is melting at the thought of the edge turfs having each-other in one another vis_contents and then how that impacts the mobs.
He's giving the world the appearance of looping back on itself by forcing the world to draw turfs from the other side of the world. He then teleports the player when they hit the edge of the world instantly, giving the appearance of a seamless world.





I used a similar concept a year ago, except instead of linking edges, I created look-down layers on the map that caused the player to be able to look down into different Z-levels.
In response to Ter13
I actually love the aesthetic of this. It reminds me a lot of Dwarf Fortress.
I actually have probably 200+ tiles and ~100 or so sprites done in that style for a roguelike set. I keep meaning to package them up and sell them on itch or gamedevmarket, but then I get sad that I'll only ever make $50 off of them... Which is 5 burritos richer, but still. I probably put at least 20 burritos worth of effort into the set.


Click for full-size view:



(And that's only a fraction of that set)
In response to Ter13
If you're ever interested in doing something with it, I'd be down to collab on a side project.
@Ter13 - The effect you're displaying can be achieved by simply teleporting a player to a different z-level. What Kai is doing is a little different. Still don't understand it.
In response to PopLava
PopLava wrote:
@Ter13 - The effect you're displaying can be achieved by simply teleporting a player to a different z-level. What Kai is doing is a little different. Still don't understand it.

It can be achieved by teleporting a player to a different z-level. This isn't the case in his example though. What he's doing is actually very similar to Kaio. It's just in the Z axis instead of in the X/Y axis.
Page: 1 2 3 ... 351 352 353 354 355 356 357

Login to reply.