fearyourself says:

Sanctimonia: I also agree, I think it’s very interesting to start with Ultima I instead of Ultima V as I did (the reason I did this is because to disable features already implemented is easier than adding concepts that didn’t exist first).

However, I saw some rendering elements and things that shouldn’t be difficult to integrate into Backtoroots. Others such as real-time movement might be more tricky but not impossible.

If you’re interested Time Machine Dragon, we could see how to share code, decoding data files, or even just merge the projects into a single bigger project system.

Tell me what you think since our goals are relatively the same,
Jc

fearyourself says:

I think it’s because they simply center the view with the main character and it isn’t a constant movement system such as the one we see from VAGUE. Being such a tile based system, they maybe wanted to keep that kind of view.

In the end, they could add it but perhaps it isn’t what they are looking for.

Jc

fearyourself says:

I’ll inline my comments:

>> The camera is fixated on the ‘avatar’, though it can be fixated on any tile.

Yes it is the same. I call it the “Group” but the idea is the same. Basically, depending on the borders of the map and the size of it, the start tile to draw is decided. The camera doesn’t really move it’s what you draw that changes.

>> Pardon my inconsistent API-filled grammar, but here’s how it all fits together:

No worries.

>> Things exist on Tiles.

Tiles are called Cell in my engine and they contain basically three level of “things”:

– AnimatedObjects which are on top
– Corpses which are dead AnimatedObjects
– Objects

>> Tiles are collected together on Facets (think of Facets of classic Ultima “chunks”).

The tiles for me are simply collected in a 2D matrix which is a Map. However, since you can have multiple levels in towns or dungeons, a MapHandler contains multiple Maps.

>> Things may have an offset from the center of that tile, which at the very least can be visualized.

Each Object gets a call to render. If it did contain an offset, it will change the position it gets with its inner offset. For the moment, I don’t have offsets since I haven’t seen the use of it.

>> Things can have Actions committed to them.
>> Actions have durations.
>> Actions may affect the state of the associated Thing atStart of the Action and/or atEnd of the action.
>> Throughout the duration an Action, properties of the Thing may be affected by a FunctionOfTime where the time(0) is “start” and time(duration) is “end”.

I don’t have any implementation of handling actions to objects for the moment.

>> The various FunctionOfTime effects will be mostly for animation of effects, and are currently responsible for displaying the Things between the “start” and “end” of their movement Actions.

Objects have their inner properties and a Sprite which handles the rendering. Therefore, an object basically just passes the rendering call to its sprite. The Sprite contains the information related to animation between frames. It handles it internally and the Object is not concerned with this except with passing the update information to give the sprite the information of time passing.

>> So if I remember correctly, a typical MovementAction consists of a startCell (tile), endCell, duration/speed, and a FunctionOfTime that sets that Thing’s x/y offsets appropriately based on the gameclock time.

Since I’m turn based and didn’t try anything else, you have a time clock that resets at each user input. If there is no user input, you pass that turn.

At each end of the user’s turn, the rest of the world gets a turn and the system updates the movement for the different animated objects (NPCs and monsters) of the current maps being considered.

# Gameclock time moves forward with rendertime, except when there is a pause due to ‘wait for action’ lockups on UserControllable Things. In the demo there are no ‘wait for action’ lockups because I’ve hard-coded the avatar to automatically invokes a ‘pass’ action of 1 duration if his BehaviorController has no movement actions enabled.

Yes, I do the same kind of thing.

>> So in short, implementing a turned-based tile game is possible with this engine. More dynamic approaches to turn-taking are also possible. It is very tile-based however, and will probably remain that way. I’m hoping to implement hex cells for fun strategic battle stuffs.

Yes, I can see how that makes sense too.

>> Since you have a lot of your engine implemented, you’d probably only potentially want to use this for an alternate world, object, and effects renderer.

Most likely. Were we to integrate both systems, probably the rendering would be integrated and then see if we want to make it less tile based.

>> In that case, VAGUE would only care about the following interactions:
>> How can I display your terrain tiles?

At each frame of the engine, each cell/tile says: “draw me at this screen position”. We could change this into: “draw me at this world position” and VAGUE decides where that is.

>> How can I display your objects?

When a cell is rendered, it requests its objects to be rendered and provides the same position information.

>> So I’ve tried to make things as abstract as possible. My measure of success will be the amount of joy you can derive in wrapping the VAGUE engine around parts of your engine. I still need to iron out a lot of details, and open stuff up. A lot of it takes advantage of the simplicity of the U1 world with a few lazy assumptions. This project would benefit from this sort of collaboration.

That is why I’ve integrated both U4 AND U5 at the same time. It keeps the engine generic to not over specialize.

>> Anyway, I gotta run. I’m open to further discussion, and eventually collaboration once I’ve blown enough dust off of the old code.

Most likely we should see how we could work together. Either by merging the two projects or creating hooks that make both work together as an option, etc.

Jc