Immersion - [#13/10/2019] - 0.2.4

[Kvothe]

Name: Immersion Package
Version: 0.2.3
Download: Github (Please, read the 'readme.me' for instructions!)
Page: Here

"This is a plugin-package that will allow the RPG Maker MV users to create a more immersive experience for their own game. In which include several tools to make more easy to do it!"​

I'm posting it here to get ideas and feedback about this plugin-package project. Of course, by now I don't have any demostration to you guys play by ourselves, or I don't have shared the code yet. But, I'm hoping that you guys can share some thoughts with me

My main motivation to create this, is to help everyone to make their game more impressive and more beautiful xD

Features (that I've done by now):

• Light system using <pixi-light>
• Editor in-game to make everything more easy
• Collision and Pixel Movement system... there will be a editor off-game to setup the collisions body and the animation sheet of any sprites.
• Time system that affects how everything it's showed on the map, like the light system for example.
• Particle System using the <pixi-particles>, then you can use their online editor
• Spatial 3D Sounds, so you can create a nice atmosphere.
• Map System: Now it's really a lot more easy to create parallax maps in a "light *(size)" way. The map system include a 'floor system'. In which, for every map, you can create three map on one! The floor is: under, base and high. Every floor can have 4 layers (ground, npc/object, above npc/object, above everything)
• ....

Screenshots:

Spoiler: Screenshots

Videos:

Spoiler: Videos

Well, is it guys... I hope that you can provide me some feedback and so on! Let's make this together something incridible!

 

[bazrat]

This sounds really cool man!

One thing I'll bring up since you opened it up is with the pixel movement it would be nice to have a proper pathing system for moveroutes. Right now with altimit pixel movement plugin, all good pathing plugins like yanfly/galv moveroute and yanfly event chase go out the window and events get stuck on any event/restriction blocking them.

The editor is such a great idea, can't wait to learn more.

 

[mathmaster74]

@bazrat To keep events from getting stuck, have you tried setting skip if unable to move and giving the events a way to check if their screenX() and screenY() values are not changing? If the event checks itself for getting stuck, you can make a conditional to have the event turn. Also, I hear you. It stinks that when you get a cool feature like pixel movement it has to come with added complexities like these.

On the topic of the OP, this is yet another cool use of perspective I've seen giving more life to RMMV of late. I would love to work out the creative process for implementing stuff like this in my games!

 

[Kvothe]

@mathmaster74 : Hahah thank you dude. In truth, for people that are creative and like to use, for example, parallax maps and do something more complex with their maps, this plugin will help a lot

@bazrat : Okay, dude, I'll add it into my todo list of the pixel-movement system. In truth, this system follows up a grid of 8x8 that checks up the block path and so on. And yes, the main ideia behind this system overall, is this editor, to help everyone make the collision part of their much more easy to do

 

[Kvothe]

A little video showing the part of the in-game editor. You guys can see the result on the first video of the topic (in-game playing). It's important to say that the UI of the in-game editor will be changed on future, I'll do something really easy to-do/ edit, for the users at the same time, complex for people that are more advanced.

I recommend to advance this video on 2x xD

 

[ShadowDragon]

from te video's, its something really neat, but most plugins specially pixel movement have either vehicle problem, stepping problem or talking problem or not compatable with other plugins, but so far I see in here on the video and demo. It's really promising.

Its really ideal for a little start up of a project. Keep it up.

 

[Kvothe]

The key point of this pixel movement system is that I'll build up something that work around the system, I mean... the mapping system (collision part), the collision body of the sprites and so on, then I guess that will be not that problematic... But of course, I'll try to take care of these details (specially the detail of the 'talking problem')

And thank you Keep following!

 

[bazrat]

The key point of this pixel movement system is that I'll build up something that work around the system, I mean... the mapping system (collision part), the collision body of the sprites and so on, then I guess that will be not that problematic... But of course, I'll try to take care of these details (specially the detail of the 'talking problem')

Is this pixel movement similar to Galv's where it's more a pseudo effect?

For instance in your 8x8 moves, if you are on the far left side of a 48x48 tile, will an event be able to trigger player/event touches from the opposite side of that same 48x48 tile? Or in other words, will the events sometimes look like they are not actually touching the player when they trigger?

Sorry all these pixel movement questions xD

 

[Kvothe]

@bazrat Don't worry about the amount of questions xD

Well, let me try to explain you the pixel movement:
Why 8x8? I've choose this grid just for the position of elements in map sakes xD
About the question of triggering the player by touch: What happens is: the event will only trigger the player by touch, if his collision body touches the player collision body (and that it's free of the grid system, I mean, the collision body just follow up the position, you can then setup a free collision body if you want to); Then the part of "Or in other words, will the events sometimes look like they are not actually touching the player when they trigger?" This can happens only if you setup a higher collision body for the event. Let me picture it for you: You have a normal sprite 48x48, if you use the default collision body, in which is a circle shape, the radius of this circle will be likely 13px and will be locate at the center-bottom of the sprite (in his feet). Then, the event will only trigger the player by touch, if his collision body touches the "feet of the player (if you let the default collision body)". But now, if you setup a square or higher circle for the event, for instance a circle of 30px.... then yes, your question can happen

I don't know if this was confuse hauauhauh anyway, any more question, feel free to ask it always!

 

[bazrat]

@bazrat Don't worry about the amount of questions xD

Well, let me try to explain you the pixel movement:
Why 8x8? I've choose this grid just for the position of elements in map sakes xD
About the question of triggering the player by touch: What happens is: the event will only trigger the player by touch, if his collision body touches the player collision body (and that it's free of the grid system, I mean, the collision body just follow up the position, you can then setup a free collision body if you want to); Then the part of "Or in other words, will the events sometimes look like they are not actually touching the player when they trigger?" This can happens only if you setup a higher collision body for the event. Let me picture it for you: You have a normal sprite 48x48, if you use the default collision body, in which is a circle shape, the radius of this circle will be likely 13px and will be locate at the center-bottom of the sprite (in his feet). Then, the event will only trigger the player by touch, if his collision body touches the "feet of the player (if you let the default collision body)". But now, if you setup a square or higher circle for the event, for instance a circle of 30px.... then yes, your question can happen

I don't know if this was confuse hauauhauh anyway, any more question, feel free to ask it always!

That makes perfect sense and was honestly the answer I was hoping for xD

I'm glad you're adding for us to make collision bodies specific for player and events.

Will these pixel movements be connected to the current moveroute commands in anyway? Like, will moving Left in a normal moveroute command move left by 8 pixels, or will it stick to the 48x48 grid during those commands? I know with Altimit movement you can't get the pixel movement in a moveroute, you have to do it through plugin commands, which is kind of annoying when you want to setup more inside a specifc moveroute and have pixel movement.

 

[Kvothe]

@bazrat : "I'm glad you're adding for us to make collision bodies specific for player and events. " My main hope and ideia is that, at the same time that the system is complex, it is easy to add/edit things. And with the editors, I will let the third person edit the max that it's possible

Will these pixel movements be connected to the current moveroute commands in anyway? Like, will moving Left in a normal moveroute command move left by 8 pixels, or will it stick to the 48x48 grid during those commands? I know with Altimit movement you can't get the pixel movement in a moveroute, you have to do it through plugin commands, which is kind of annoying when you want to setup more inside a specifc moveroute and have pixel movement.

No, you can use the standard moveroute system that shall works perfectly with pixel movement. Of course, some commands will not be already developed when I release the beta version of this, but in the final product (1.0v), all standard commands shall be working well with the systems. The only thing that I have to stay clear is: since I'm changing a lot of things, this plugin maybe not be compatible with a lot of plugin (unless if is battle system plugin, because I'm not changing anything in this part). I'll release a pdf for both user and developer, for the users.. just the basic, for the developers, there will a lot of examples to work with this plugin and integre their own system

But I doubt that the users will keep using the detault event editor of the maker when I show them my own editor for this :v

 

[bazrat]

@bazrat : "I'm glad you're adding for us to make collision bodies specific for player and events. " My main hope and ideia is that, at the same time that the system is complex, it is easy to add/edit things. And with the editors, I will let the third person edit the max that it's possible



No, you can use the standard moveroute system that shall works perfectly with pixel movement. Of course, some commands will not be already developed when I release the beta version of this, but in the final product (1.0v), all standard commands shall be working well with the systems. The only thing that I have to stay clear is: since I'm changing a lot of things, this plugin maybe not be compatible with a lot of plugin (unless if is battle system plugin, because I'm not changing anything in this part). I'll release a pdf for both user and developer, for the users.. just the basic, for the developers, there will a lot of examples to work with this plugin and integre their own system

But I doubt that the users will keep using the detault event editor of the maker when I show them my own editor for this :v

Sweet, can't wait to learn more and start testing this out

 

[definite_lee]

This looks very interesting!

Will there be any way to separate certain features, such as turning on/off the lighting system, time system, pixel movement, etc.? In case we want to use certain systems but not others

 

[Kvothe]

@definite_lee Well, no... because they are connected to each other. However you can, for example, choose not to use them... as for example, the light system, the only requirement is that you set the ambient light. But the pixel movement, there is no way

 

[rafman2k]

This looks great I've been following your vids since the first pixi lights demo.
Only thing that might be missing is pixi shadows.

https://github.com/TarVK/pixi-shadows

Will keep following the progress!

 

[bazrat]

Hey Kvothe, wanted to see how things were going with this project?

 

[Black Mamba]

i only want light system, can i turn of the others features?

How can i controls the light with event, like i add a light with in-game editor and later i want to turn it off, or change something

 

[Kvothe]

@bazrat : I stopped the project because I was sick (I explain it below). But now I'll turn back
@Black Mamba : Hmm well, my intention is to create a 'modular plugin', maybe you will can... but I'm not sure

[hr]

I was bite by the aedes aegypt these past of days... so I was really bad of health and so on. Happly, I'm okay now and I finally can turn back to the project and so on

 

[bazrat]

@bazrat : I stopped the project because I was sick (I explain it below). But now I'll turn back
@Black Mamba : Hmm well, my intention is to create a 'modular plugin', maybe you will can... but I'm not sure

[hr]

I was bite by the aedes aegypt these past of days... so I was really bad of health and so on. Happly, I'm okay now and I finally can turn back to the project and so on

Jeez, glad to hear you’re feeling better. That doesn’t sound fun

 

[so1us]

Hey, Kvothe, hope you're doing better.

Just wanted to chime in and say that this is such a cool looking set of tools and hopefully, you'll be able to release these someday when they're ready.