Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[IndigoFenix]

The background settings are new, but they don't work yet.  Ignore them.

The pit physics aren't finalized yet, they're just a placeholder so they function as jumpable obstacles.  You jump with the C button by the way.
It's basically this big question that has been in the game since the beginning: Grid-locked motion is bad for action, but good for puzzles.  The way the tiles worked in the original was tied heavily to the grid-locked nature of the game.  With free motion comes voluntary jumping, and that means you need to time your jumps over the pit.  Unless I make it so you automatically jump when you try to step onto a pit like in the 3D Zelda games...?  Actually that's not such a bad plan now that I think about it.  Maybe while dashing?

I was already planning on different gate types, but I did get the multi-tile gate idea from looking at your world.

[IndigoFenix]

As for having the "pit" property be overwritten by other tile types, I did consider this.  The problem is that this then leads to the opposite issue - intentional pit tiles being overwritten by blank, non-pit tiles in other tilesets.

It's doable, but it might also be too confusing to have different tile properties use different rules, and I'd rather avoid making it more confusing than it is.

The thing is, for all but the simplest of tilemaps the ideal practice is to make the visible tilemaps non-colliding and then add an invisible tilemap on top of them to handle the collisions.  It makes it much easier to keep track of what you're building.

[Daren Kazzarch]

Nice, the jump fyzics allow jump seqences to be used as an obstcle where the same in grid motion would be flavor only. But i imagine that world builders will have diferent opinions on that, depending on how causual or skill based they want thier worlds to be. I think the optimal would be to allow the designation of areas as grid based or free. Though for practial reasons probably at least the whole room, so you don't have to deal with objects which leave and enter these areas.

As for jumping, my own preferences lay with only manual jumping in the free movment mode and only automatic jumping in while on grid.

I don't see why i would place invisibe tiles over pits other than intentionaly prevent jumping over them or by accident. But then how about enforcing what you have described? Make all normal tilles propertyless and than have a special tileset, which contains tilles with all distinct option combinations, colour coded, half opaqe and only visible while editing the current layer.
Also please add a way to find invisible tilles, like filling all invisible pixels with solid orange temporarily or something. Finding these things is a pain and involves a whole bunch of random clicking around.

Btw. how can i leave from a world to the main menu, other then opening the editor and relouding the page?

[IndigoFenix]

The problem is that due to the way tilemaps work "no tile" is actually a tile.  This is why you can give properties to the blank tile.  So if you create a tilemap, even if you don't place any tiles, you're placing invisible "normal" tiles over the whole map.  If non-pit tiles block pits, you would have to designate all blank tiles in all tilesets as pits to prevent them from being blocked off.

There will be a default tileset containing all of the basic tile types.  However since you can mix tile properties together in different ways I don't want to restrict tile properties to it.  There may also be a point where you can give functions to tiles and that will open up a whole new set of rules.

There might be grid-lock tiles later, to designate grid areas.  However, you can set the player to grid motion with a function, set @._grid to 1.

It is now possible to change the size of sprite images using the Image Scale property.  You can also use _rand to get a random number in an expression.  Both of these are used in The Nope Room.

[IndigoFenix]

Dialogue boxes are now a thing.  You can set the default background color, font color, font size, and font family of a sprite, as well as give specific settings to each dialogue box.  You can also create selectable options, which will set a reference variable that can be used in later If statements.  Options can be conditional as well; if you give an option a condition it will appear only if that condition is true.

I may make a more specific editor for creating large, complex dialogue trees more easily later, but this will suffice for now.

You can insert variables and expressions into text boxes.  Parts of the text that are in {curly braces} will be evaluated as expressions.  For example, "Hello, {_game._username}!" can be used to greet the player.

There are still some more things to be done with dialogue, which will come along with new targeting and conversation mechanisms.  There will also be free text inputs, although the usefulness of those will be limited.

Despite all this, I'd like to discourage excessive use of dialogue trees for atmospheric reasons.  Basically if world builders "put words into the player's mouth", the player's personality may change arbitrarily from world to world, making them harder to characterize from the player's perspective.  To that end, I'm considering the idea of including certain "gestures" into the game that will allow the player to communicate with NPCs in ways that do not involve dialogue trees.  I don't want to overdo it with the buttons though.  I'm thinking four main gestures: threat/anger, peace/calm, laugh/taunt, and surrender/sadness.  In addition to being possible reactions to dialogue, these gestures can have additional effects on enemies and neutral creatures, like provoking them into attacking, scaring them away, or getting them to join you.

There will still be dialogue trees of course, but I think it would be a nice touch to give players another option for communication, letting most worlds maintain the player as a (mostly) silent protagonist.

I am playing around with the controls, so some things may feel different.  Jump height has been lowered significantly to give free-motion and grid-motion similar capabilities; you can now only jump over one pit at a time while dashing.  The shift button is used for dashing.

There is an interesting effect where jumping repeatedly makes you move a little faster, especially if you time your button presses well, but also makes your movement harder to control.  While initially unintended, I rather like the effect and may utilize it later.

It is worth noting that all player physics only apply to default behavior.  You can use a function to change any player variable you want, like _jump, _speed, _accel, and so on.  Or you can simply turn the player sprite into a custom creature, that's always fun...

Oh, right, if your world looks weird, Daren, it's because I changed the rendering order of layers and tilemaps to operate in reverse.  Basically so that layers and tilemaps that are "on top" in the object list will appear "on top" in the game, making it more intuitive.  You can reorder them easily enough though.

[IndigoFenix]

Doing some more things with physics and creature behavior.  Flying creatures are now a part of the game, both in the overhead and sidescrolling modes.  I made some bats that flap around your head and occasionally swoop in for a bite.

One plan I have with the creature physics is that it should be reasonably simple to turn the player into any given sprite, at least as long as you don't make their custom behaviors too complex.  A "change into" event with the player (@) as the target lets you test out your custom object in-game.

EDIT: You can use basic attacks now.  Basically you target an enemy by holding Z while facing them, and then collide with them to attack.  This is also how enemies attack you (they choose a target on an enemy team, then run into it).  If your attack is on cooldown, you will not be able to do damage.

I'm planning on making a default "defense" property as well; targeting an enemy will automatically defend you from their attacks, but strong attacks will be able to break your guard.  Enemies will also be able to do this.

EDIT2: To deal with the multiple tilemap and pit issue, I added a new type of tile, "Floor".  These tiles do nothing on their own, except they cancel the effects of pits occupying the same tile.  So by designating a type of tile specifically as a floor, you can designate empty tiles as pits and not have to worry about them.

You can also exit to the main menu by pressing "Q".  There will be a proper status and item menu there later, when there are items and things to show on it.

Still messing around with controls to get a result that feels natural.  Keyboard limitations are also an issue, since most keyboards can't have more than 2 keys held down at the same time.  The dash button is Z right now.  This may change.  Actually, I'll probably just make it possible to customize controls.

[IndigoFenix]

Backgrounds are now in.  You can do all kinds of things with them, including tiling, parallax effects and auto-scrolling.

"Background effects" actually apply to the entire layer.  This means you can create parallax background layers with sprites and tilesets that interact with each other in the background, making a cool 3D effect like a battle between two distant armies in the sky.  You can also turn whole layers transparent.  With functions, it may even be possible to make a pseudo-3D area like some of the bosses from the SNES era, though I haven't tried that yet.  However, do not put the player in a layer that has, say, and auto-scrolling effect, or they will be forced off screen.  (Maybe in the future this could be used for auto-scrolling levels, but for now it's just a logical bug.)

[MoonyTheHuman]

This is amazing. The clientside is in Javascript, right? if so, i think i could help you

[IndigoFenix]

This is amazing. The clientside is in Javascript, right? if so, i think i could help you

What kinds of things do you want to help with?  I'm working on pathfinding now.
If you want to look at it and offer suggestions (it is kind of spaghetti), nothing's stopping you.  Protecting Javascript is a futile endeavor anyway.

[Kamani]

I am definitely watching this to see how it continues. I can't help or anything, but this is a really neat idea.

Edit: Trying to figure out the editor, I may have made a junk level. Oops. Well, deleted

[IndigoFenix]

Okay, I think I've spent long enough on this last update... there's a good reason though, I had to basically restructure the entire screen system.  But now the game uses a matrix graphics translation system.  What does this mean?  Well, basically it means that graphics will be capable of being rotated, stretched, squished, etc.  Theoretically, anyway; slowdown seems to be a problem when messing with excessively large graphics.

You can't do too much with it yet, aside from making layers spin around (which unfortunately seems to cause significant slowdown) and making free-rotating sprites.  But, it opens up a lot of possibilities.  It's basically like the SNES Mode 7 graphics system.  I'm going to play with it a bit and see what sort of options can be made easily accessible to world builders.

[IndigoFenix]

Okay, so matrix transformations aren't quite as versatile as true Mode 7 graphics.  No trapezoidal transformations, so can't do stuff like FF6 airship or Super Mario Kart graphics, which I was hoping would be possible.  Realm of the Mad God type camera rotation is doable though, I've been playing around with that, unfortunately rooms that employ both camera rotation and 2-d platforming look weird for technical reasons and there's probably not much that can be done with that.  Also rotating tends to cause slowdown if you're using multiple layers.  It does make a cool effect for exploring overworlds, boss battles, and outer space.  Asteroids-type ship with a rotating camera and Zelda-esque lock-on sounds like it could make a fun game by itself.

Urgh, I'm spending too much time with this graphical fun and not enough with the actual meat of the project.  Next on the list is making proper combat skills, finalizing the physics engine, and finding a happy medium between utilizing pathfinding AI and not slowing down gameplay to a crawl.  I guess the parameters of pathfinding intelligence should be customizable.

[Kamani]

Good to here that there be more combat stuff, physics, and path finding AI. I haven't been on, since there isn't anything to do, but I am still following.

[IndigoFenix]

Well, you can build worlds for exploration and make gates and dialogue and scripts... In fact it is already more complete than the old Flash version was.  It's only the action aspects that might change.

The main issue I'm having with the physics is working out stats that are both simple and flexible.  On the one hand I want it to have things like mass, force, balance, elasticity, hardness, shear modulus and blood sugar, on the other hand I want the game to be accessible to players who just want to make an enemy that deals 5 damage and has 10 hp without having to deal with engineering homework.  Too many options can be overwhelming.

Edit: How to determine the exact balance between operating as an autonomous creature and operating as a physics object?  Three words: drunken master stat.

[Kamani]

I'll try making another world tomorrow (or whenever I am not busy I guess). Hopefully it will turn out better then the last.