Untitled RPG Project

Show off your games, demos and other (playable) creations.
User avatar
Hugues Ross
Party member
Posts: 112
Joined: Fri Oct 22, 2021 9:18 pm
Location: Quebec
Contact:

Re: Untitled RPG Project

Post by Hugues Ross »

zingo wrote: Sun Jan 21, 2024 5:15 am I started making a "map editor" at one point in hopes of streamlining/automating the process as much as possible, but then realized that I could design areas/levels just as fast in an image editor using a few layers and a grid with marked coordinants, and then code all the actual data later.
Ah yes, this is a solid approach for simple maps too! I had an abandoned love project that was doing that a few years back: https://huguesross.net/2021/02/atlantis

Currently the map editor is still in progress, I got the first pass on tile and trigger volume editing done and started on entities before the first of the 'medically-induced breaks' I alluded to last month hit...for obvious reasons that'll be on hold for a few weeks, but in the meantime I'm doing a little more work on the script for chapter 1 via dictation.

Beyond that, there's still a little bit of work to do before the first draft version of the editor is production-ready but I don't think it'll take super long either.

As for the fun...I'm looking forward to making full-blown segments of the game without constantly diving into the code. It'll be nice seeing the plans come together into a real game :nyu:
zingo
Citizen
Posts: 55
Joined: Mon Jan 16, 2023 7:34 am

Re: Untitled RPG Project

Post by zingo »

Well...with any luck you won't have anymore serious "medically-induced breaks".

Even a "small" RPG is a beast to tackle, because there are so many seperate parts that need to ultimately mesh together into a cohesive final product...and that's just the game mechanics, so I greatly admire your perseverance ;)

On a side note...as you suggested, I actually decided to use "sprite batches" for tiles, because those are much more efficient, and only require a single draw call. However, the table for each map now also needs to include the X and Y locations of all the tiles (as well as a reference to the image atlas,) so there's a bit more data to keep track of than just the quad number, although the payoff is worth it.

Anyway...everything should go a lot smoother once you get into the more interesting aspects, such as story, characters, art, music, etc. You already seem to have a solid idea for all of that, so I'm really looking forward to eventually seeing what this is all about :ultrahappy:

Onto another tangent...one of my personal favorite RPGs of all time is Final Fantasy 6 for either the SNES or PS1, because it was a sort of "steam-punk" departure from the traditional "medieval" setting, and for me, became the "standard" for what I expected for future titles in that series (and RPGs in general). Also, Kefka was one of the most entertaining villians I can recall from the 16-bit era, and I'll never forget the literal "world shattering" last portion.

Good luck. Stay healthy, and keep at it. :cool:
User avatar
Hugues Ross
Party member
Posts: 112
Joined: Fri Oct 22, 2021 9:18 pm
Location: Quebec
Contact:

Re: Untitled RPG Project

Post by Hugues Ross »

Alright, it has been a few months so let’s get a little update post out. This is sadly gonna be another one of those slim updates, but hopefully we’ll be out of those soon enough. In the meantime, let’s talk level editor.

Doneish

At the end of last year, I had started on the level editor. And now, I can announce that it’s…erm…mostly done. Pretty much all of the basic tools, tile editing, object & trigger editing, undo/redo, etc. work as expected. But as is customary for most software, the devil’s in the details. There are lots of little things to fix and adjust, particularly since I had to update the game’s map format to make it all work.

Nevertheless, I could probably take a little video showing off what’s there. I’m trying to avoid using my hand while I rest (all of of the text I’ve written recently is dictated, not typed), but hopefully I can put out a mini-update in a couple weeks showing how it all works. For now, you’ll have to make do with a screenshot:
Image

About That Hand…
One of the perennial problems with this project has been my health, particularly various hand & wrist problems. I went in and got surgery on one of my wrists in January, which should ultimately be a boon but unfortunately also means post-op. I’ve previously alluded to some expected breaks this year, this is the cause of those. As a result of that, and a slightly rocky recovery where I tried going back to work too soon, there have been long periods were I couldn’t do much. Things will hopefully have cleared up (at least for the first wrist) on that front by the time I make my next update, but in the meantime it’s obviously delaying things a lot.

And of course, the editor itself doesn’t have a voice interface yet. That was planned for future dev, but sadly I could really use it now!

In the meantime, I’ve been keeping myself busy/entertained with voice-art. It’s mostly off-topic, but I did scrape together a few icons for assets that I can add to the editor later:
02-26-big.png
02-26-big.png (3.09 KiB) Viewed 12774 times
Each icon represents an asset type but exists in the game right now, though some of them are a little convoluted. If you're bored of waiting for me to make progress, why not try to guess what they are?

In other news, I also figured out a title for this game! The RPG technically isn’t untitled anymore! But I’m a terrible drama goblin, so I’ll hold off on actually revealing the new name until I’ve finished this long ongoing process of restructuring the project. You’ll just have to sit tight until then :D
User avatar
Hugues Ross
Party member
Posts: 112
Joined: Fri Oct 22, 2021 9:18 pm
Location: Quebec
Contact:

Re: Untitled RPG Project

Post by Hugues Ross »

For those wondering "why did he post now instead of waiting to recover fully?" it's stupid.
I thought the date this thread started was the end of Feb/start of March. It was, in fact, the end of March. :?
User avatar
Hugues Ross
Party member
Posts: 112
Joined: Fri Oct 22, 2021 9:18 pm
Location: Quebec
Contact:

Re: Untitled RPG Project

Post by Hugues Ross »

Despite my continued inability to keep to a schedule, I’m still here and still working on this RPG. Or, uh… a tilemap editor for this RPG. But that’s done now, honest! Done-ish! Kinda!

Didn’t You Say Doneish Last Time

^^

More seriously, “done” is a difficult target to identify when it comes to games and software. Every time you look at a supposedly finished project, you find another spot that needs work. Sometimes, addressing that spot reveals larger problems that went unaccounted for–and that’s what happened here.

When I set out to make this thing back in November (ye gods, has it been 6 months?!), I made a checklist of all the things that needed to be present in order to support my one ‘finished’ map, on paper. I successfully did most of those things before my last update, with a few caveats:

Caveat 1: The tiles in the screenshot weren’t ‘real’

That’s not to say I faked the screenshot! I had the editor properly loading the old map, making it possible to view and edit stuff in it. But it wasn’t being converted to the new terrain system that would generate new tiles, instead using a hack to preserve the original tiles from Tiled through the map conversion process. That’s good for compatibility, but it also meant that I had not validated how well the map could be recreated using only new system.

Finishing the terrain rules for my test tileset was one of the remaining items on the list. And unfortunately, that included these things you may have heard of called stairs. We’ll get back to them later!

Caveat 2: The objects were also not quite ‘real’

Tiled has a nifty feature that lets you define and add arbitrary properties to objects. It’s not a good approach for making complex games, but I was using it for the sake of simplicity early on. Initially I was going to add this feature to the new editor, but I changed my mind. It would take a lot of time and effort to recreate this kinda bad way of working, so I changed my plans to include reworking actors with a more composition-based approach.

This will make it easier to build levels later, but also means that I can’t set up new actors the way that I used to in this new map editor. And a rework like this is a large undertaking, too large to embark on while still working in my map editor branch. In the meantime, I hard-coded a bunch of temporary object types in the editor so that I could load and edit the existing objects in my demo level. This is another fine temporary measure for viewing & editing existing data, but it’s one that can’t sustain itself forever.


To wrap it up–I had most of the to-do list handled, and took measures to continue supporting my old maps, but some blind spots remained. So why is the rest taking so long?

Big Problem 1: Autotiles
I have a confession to make. The tiles of my first map have seams at some of the corners. In fact, they have always had seams at some corners. This is because I’m lazy and can’t be bothered to make a million variations unless I have to.
Image

When I sat down to actually finish these terrain-based autotiles, I knew I had to finally tackle this problem. However, my wrists were still very screwed up and recovering…I’ve only really been back to something resembling ‘full form’ (and even that’s a bit of a stretch) for a couple weeks at the time of writing. I knew I didn’t have it in me to click a million times making repetitive permutations of tiles.

But Just Then, Ol’ Hugo Had A Terrible Idea
What if I thought…smaller? What if, instead of making zillions of tiles by rearranging bits and pieces of my existing ones, I had the computer do it? What if every tile in my map was several smaller tiles in a trench coat? What could possibly go wrong?

Literally nothing. It worked out great, that’s what we’re doing now, it kicks ass.

Still, it represented a major increase in scope. And more importantly, it became impossible to preserve the old map like I was doing before since tiles had…fundamentally stopped existing in their prior form. The new approach, which I’ll show in more detail later, requires a disconnect between the visuals of a tile and the gameplay properties. It makes sense if you think of it, if you’re drawing several miniature tiles in every ‘tile’ of your map then there’s no way to know which one represents the larger tile’s properties. I could’ve simply scaled the grid down, but leaving tiles at the same size greatly simplifies the gameplay code. And the terrain data in the new map format can easily dictate what a tile is for gameplay purposes so it was only an issue in my older maps


Then I found a second reason to ditch the old map:
Problem 2: Return To Stairs Hell

Here’s a funny story: Every tilemap I’ve made since the start of this project contains at least one critical problem with its physical structure, bar none.

I guess that wasn’t actually very funny, but it illustrates how hard it is to make these 3D-ish tilemaps in a program like Tiled.

Of note here are the stairs, specifically any vertical ones like these:
Image

That’s not stairs, that’s a wall. It looks a lot like stairs, but when you really sit down and diagram it out, it makes no sense. This doesn’t matter in a game with 2D physics, but it’s a huge deal in a game doing 3D stuff.

I spent a very long time mapping out how exactly these stairs would need to be structured as terrain in order to be physically viable. And maybe, just maybe, I lost my mind a few times:
Image



I was immediately forced to rewrite all of the staircase physics in the game. And I continued to lose my mind for a while:
Image

…but eventually the deed was done, and stairs work and they’re fine and I’m fine and I still haven’t written all of their tile connection edge-cases into the terrain rules because that’s just visuals and there’s like a million of them but for now I don’t care!

Where was I before I went into a staircase-induced fugue state? Right! I couldn’t keep using my old map, because it was structurally unsound to begin with. And so was every other test map I’d made to date. Cool! I’ll have to remake them. But am I forgetting something?

What Are Doors, Anyway? We Just Don’t Know
Before I could get to work remaking the levels, I still had a couple things in the tilemap that I couldn’t make. Doors (or more accurately, doorways) were the most obvious thing that needed work. But how?

Doorways have some funny properties. They connect to walls, but you can walk through them. They also generally appear in fixed sizes–You don’t usually streeeeetch a doorway into a different shape, it’s a fixed structure rather than a dynamic one. And yet, my only way to make maps (the terrain system) was dynamic in nature. I knew I’d need ways to make static structures eventually, but I had assumed during initial planning that it could be put off. Now that I could no longer preserve my old maps, it had to happen immediately.

Enter Stamps
This one also wasn’t that bad. I probably spent a week or so rotating ideas in my head until I had a design that seemed sound, then I sat down and made it happen. Stamps are a pretty simple concept in the new editor: They’re a pre-made arrangement of tiles (visuals and/or gameplay data) that you define in the tileset itself. Then, you can slap them down anywhere in the world and they merge with the tile data they cover but not the terrain information. This should make them ideal for a variety of things such as rocks, trees, doors, windows…really any scene element that’s static in nature and doesn’t fully define the terrain it’s attached to.

At this point, I realized that I could also ditch saving any real tile data in the maps I saved. Today, they just contain stamp & terrain data–when the map is loaded, that data lets it generate all the final tiles on the fly.

Problem 3: Ok, Now Change The Wallpaper
To my horror, working on stamps made me realize something else: How the hell am I gonna make trees work?

I’ve gone and ditched a lot of traditional tilemap concepts in this 6-month map editor project. Most notably, I replaced layers with a proper Z-axis: That’s how I do 3D tile connections with my terrain.

Now let’s talk about the elusive tree, never before seen in any of my maps. Trees have a base, a trunk, and a canopy. These need to draw in front of / behind the player and terrain. For the trunk and canopy, this is child’s play: Thanks to the Z-axis, tiles draw over objects when those tiles are closer to the camera. It’s simple!

But what about that base?
You see, I’ve been informed that trees have these funny lil squiggly guys called ‘roots’. They go into, and sometimes out of, the ground. In this new paradigm of tilemaps, these roots occupy the same space as the ground. They’ll still connect properly if I use a stamp for the tree, which I probably will. But that still implies integrating the ground tiles into the base of every tree, because there are no layers and those tiles overlap in 3D space. That’s…I mean, it’s not gonna work in the long-term. Having to carefully avoid using certain types of ground tiles near trees, or worse having to make multiple variations that connect to different types of ground, would extremely suck!

Now extrapolate that problem to every decoration in the game. Furniture? Windows? Banners? Animal pelt rugs? Fountains? Random piles of boxes? Those doorways from earlier? Every single thing that wasn’t closely tied to a particular type of terrain would require workarounds. Or I’d have to do the old NES thing where they all have black rectangles behind them to save on color-count.

You get the idea. So I had to go back and re-structure how the visual part of tiles worked in order to support overlapping ‘layers’ of those mini tiles inside of the big tiles. Here’s how it all comes together:
2024-05-17-untitled-rpg-devlog-11-5.png
2024-05-17-untitled-rpg-devlog-11-5.png (3.41 KiB) Viewed 10531 times
The reality is a little more complex than that, but I could write a whole ‘nother post just about how tilemaps work. The important thing is that we’re finally done! Right?

But What About That Map Editor?
With that (and countless smaller issues) out of the way, we come to the moment of truth. I finally felt ready to sit down and remake those maps, so I popped open my editor and…it sucks to use.

I’m not surprised. It’s an early in-development tool, there’s obviously not going to be any quality of life features or polish, the design will need adjustments, etc. But I think the current state of the editor makes it very difficult to build anything large or complex, even when I have the blueprint in front of me:
  • It can be very difficult to tell where exactly you’re pointing at in 3D space. I tried to provide some helper features for this, like ‘vertical grid lines’ that appear above & below the cursor and highlighting the Z-level being edited by fading out the others, but it’s not enough.
  • It’s especially difficult to work when walls are obscuring parts of the area working on. There’s not really any way to hide them right now, which makes it very tempting not to put them in at all until the very end.
  • Speaking of walls, the terrain tools are really built around the idea that you’re going to fill in all of the ‘solid’ space with wall terrain. But that’s a lot of work, even with the ability to draw on multiple Z-levels at once, and it makes it hard to remove them later if you want to extend the floor. This is another area where not knowing where you are in 3D can work against you: You can visually line up two walls that don’t physically connect. It’s easy, I’ve made this mistake multiple times…
  • There are also no buttons to be had anywhere in the editor. This was fine at first, but we’ve hit a point where there are too many actions and not enough obvious keys for them. This means I wind up forgetting which key an action was bound to, slowing things down even more.
These are all problems that can be solved, but as it stands I feel like I’m not in a place where I can just jump into level design. If I can’t remake my existing maps without trouble, what chance do I have when it comes to fresh content?

This puts me in a strange position–between the unforeseen scope creep and major medical delays, I’m half a year into this editor project now. And while it basically checks all the boxes, it doesn’t feel like it’s meaningfully done. And yet, it’s blocking some major–and necessary–work such as revamping how actors are set up. The backlog is growing, even while I’ve taken a step backwards when it comes to game content and haven’t managed to…re-step it.

Sometimes, You’ve Got To Keep Moving
Despite the above, I think it’s time to wave the flag of victory, click the big ol’ Merge button in my git forge, and move on. I think solving everything is going to take a long time, and if I dedicate all of my energy to inching this through the last 5% or 10% we could be stuck in this position for months to come. Instead, I’m going to accept that the editor is still a bit of a mess, that I don’t have my maps remade (yet), and hack away at the remains on the side over a longer period of time.

This sort of scope monster is basically the reason I didn’t want to make a level editor, and only sat down to do it when it felt like I was out of options. Give me a few years and I’ll make you a fantastic level editor. But there won’t be a game attached if that happens! And when I say monster, let me be clear–this change weighs in at 5,600+ lines of code added and 650+ removed. It touches so much of the codebase at this point that trying to juggle it with other development tasks is a really bad idea. If I push the change and build over top of it, I can at least benefit from what’s there and make little improvements as I go…it’s not an approach that I could ever use at the office, but in solo-dev town it’s just fine. And as alluded to above, I do use source control. I can grab old versions of maps whenever I want, they’re not gone forever.

Let’s pivot to the future: What do I do after this? I have two plans for the rest of the year:

Plan 1
This one’s easy, and you may have guessed it already: I really want to get that actor stuff sorted. This change is tangential to the level editor, since creating and editing actors all happens in there. Thus, it gives me a very good excuse to start polishing the UI bits related to these tasks, which in turn should help alleviate one or two of the problems with the editor today. I have some other exciting surprises planned for that as well, stuff I started working on in the backend of the game as part of my current task but didn’t get a chance to properly finish.

Plan 2
What is this game going to look like? That’s a question I still can’t answer, despite taking a crack at some concepts last year. I’d really like to nail down a visual direction for the game this summer, now that my wrist is doing a little better. And while we’re at it, I have another editor-adjacent goal in store (how very convenient, it’s almost as if I’ve been planning this).

One aspect of exploring the game’s aesthetic has to be seeing what assets and finished scenes might actually look like. With that in mind, I want to produce a handful of “visual benchmark” maps using the new editor, both to see what the game’s maps might look like and to validate how easily the current map structure lets me make a variety of different environments. I’ve been working with this very basic and clean level design tileset, which means that the new approaches to building & rendering a map haven’t been tested with anything that looks like a real game asset. I’m expecting further issues and oversights to be highlighted by doing this, the same way I realized how much of an issue trees were going to become.


In the end, both of these threads of development ‘play nice’–they’re touching very different subjects from very different angles, so it should be possible to work on them sort-of concurrently. More importantly, they also meet at a single point: the level editor. This gives me an opportunity to continue iterating on this tool without halting the rest of the game’s development, as well as testing it in ways that haven’t been possible with my limited set of assets. I would be lying if I said I wasn’t nervous about knowingly pushing code that breaks some existing data, but in this case I think it’s the right call.
User avatar
Hugues Ross
Party member
Posts: 112
Joined: Fri Oct 22, 2021 9:18 pm
Location: Quebec
Contact:

Re: Untitled RPG Project

Post by Hugues Ross »

One thing that bothers me about the past year of this thread is how it feels more and more like Blog 2 rather than a forums thread. I think a lot of that is my fault, falling into the trap of long-ass meandering posts that read more like a narrative to read than something to actually be talked about or responded to. But I really do appreciate anyone following my bumbling exploits, so today I am giving this thread a little more raison d'etre:

That's right, I am punishing you all for following the thread by making you read just a little more of my terrible writing! It's a bonus double-post!


Some stuff I didn't fit into the post above:
  • One of y'all has been gamedev penpal'ing with me via email for a while now. I'm leaving the name out for privacy, but you know who you are--I wanted to drop a thank-you in public so you know I really mean it.
  • On that note, I recently drew up a more detailed diagram of The Stairs Madness that led to the almost Dali-esque screenshot above for said penpal the other day, it didn't fit into the post but I figure it's worth sharing. If you're a freak like me who wants a 3D physical structure in your 2D top-down game: "It's dangerous to go alone. Take this."
    stairs_pls.png
    stairs_pls.png (3.8 KiB) Viewed 10525 times
  • More specifically on the health-side of things--I still have somewhat screwy wrists, but I'm no longer actively recovering from an operation and the one I got done is showing some positive improvements. It will take time to see how much things improve and drawing is still quite rough (not to mention how rusty I am now), but I'm only using 1 wrist brace instead of 2 now!
  • I wasn't joking about that map systems deep-dive. I will genuinely sit down and bang that out sometime if someone wants to know more, I'm also willing to answer questions if y'all have any. I suspect it'll be hard to shut myself up once I get going tho so I tried not to overdo it for this last post
  • Oh right also the lack of video. Yeah, that. Mostly just because the old maps don't load so some parts of the editor are hard to showcase rn. I'll do a proper one later this year, hopefully
zingo
Citizen
Posts: 55
Joined: Mon Jan 16, 2023 7:34 am

Re: Untitled RPG Project

Post by zingo »

Whew...what a beast of a post...and that's a good thing, because I was very curious about what's been going on with your project. It's great knowing that you're still hanging in there. Creating any kind of game solo is difficult, but an RPG is an endurance trial for sure.

In my opinion, RPGs (or even "Action Adventure" games like Zelda) are often the most complex and layered genres to code...there's just so many different parts that have to properly fit together, and each of those parts, on their own, are often rather complicated. In essence, an RPG isn't a single game, but a lot of smaller games, all mashed into a sort of chimera.

I ran into the "stairs" issue fairly early on myself...in fact I would say that the most frustrating aspect of my own project, thus far, has been trying to ensure that everything is drawn properly, according to the projection. This has taken up a considerable chunk of my time, and to keep from pulling out what little hair I have left, I've set it aside for now to work on other things.

Hopefully your hands and wrists will continue to improve, and maybe even be fully recovered eventually. It's fantastic seeing some screenshots, and I'm looking forward to the day you've got a working demo (even if it's just a single area).

Take care, and keep at it :ultrahappy:
User avatar
Hugues Ross
Party member
Posts: 112
Joined: Fri Oct 22, 2021 9:18 pm
Location: Quebec
Contact:

Re: Untitled RPG Project

Post by Hugues Ross »

I’ve been wanting to get back into the old schedule I had, posting at least once a month. And judging by my current state of health, I think it may be doable again…so I’m back again already! I haven’t finished any of the things I was planning for this summer, but I’ve made some pretty big strides on one of them this month.

TL;DR: I wrote my own type system

Dear God, Why

The truthful answer as to why I went and wrote a type system is because I’m the kinda weirdo who likes scarping together tech by himself. But the fun answer is that this type system is a little bit unusual.

I strongly believe that one of the most important aspects of developing a turn-based RPG is authoring and managing data. There are so many little dials to turn everywhere, so it’s important to ensure that it is easy as possible to do so. You also need to consider the possibility that data structures will change in the future–we saw a great example of that last time with my sudden need to change a lot of things. And of course, RPGs are massive systems-heavy games. Long-term, it’s not realistic to test every single part of the game whenever you make a change to the code somewhere.

The first thought that come to mind when defining data structures in code is…classes. But of course, class libraries in lua are almost all just focused on importing OOP concepts from other languages. They don’t really address the needs above–you can build constructs over top of them to help, perhaps, but if we’re going to be building a new foundation then we may as well build one that’s designed to complement the task at hand.

That and I really wanted to try playing with more functional synta–
Traits, Schemas, and Behaviors

The general idea goes like this: I really don’t care about logic (that is ‘normal’ functions) in this type system.

Rather, I wanted to delve deep into defining the structure of data and how it should be analysed, processed, and presented. So the first thing you should know about this system is that it has no concept of type inheritence, and also no real concept of a function. The result is definitely not pure data, but that should at least make the priorities of this API clear!

With that in mind, I wound up calling these things ‘schemas’ rather than ‘classes’. Here’s an example:

Code: Select all

Schema "gameplay_tile"
.named "Gameplay Tile Properties"
.has.name "string"
.has.solid "boolean"
.has.block_jump "boolean"
.has.climb_x "integer"
.has.climb_y "integer"
Wow! How simple! Why did you make a type system to begin…with…

Code: Select all

Schema "trigger"
.with { "position", "volume" }

.has.id "string"
.has.name "string"
.has.require_flags { type = "string", optional = true, }
.has.collisions { managed = false, hidden = true, transient = true, } -- "Look Ma, no property type!"
.has.last_collisions { managed = false, hidden = true, transient = true, }

.can.enter { has = "target_actor" }
.can.step { has = "target_actor" }
.can.leave { has = "target_actor" }
So! Point #2. You can’t inherit from types, but you can have traits. Our friend trigger has position, for instance, which is defined as

Code: Select all

Trait "position"
.has.x "number"
.has.y "number"
.has.z "number"
…and lends its properties to any schema that has it, allowing the programmer to know for sure that it meets certain criteria. This also extends to type matching at well:

Code: Select all

Schema "actor"
-- ...
.has.renderer { type = { has = "renderer" }, optional = true }
And while there’s no way to define what functions an object might have in its schema, a schema can perform behaviors. These aren’t quite functions though–if anything, they’re closer to events. A behavior is a special type of schema that is also a functor. Like so:

Code: Select all

local warp = Behavior "warp"
.named "Warp to"
.with "target_actor"

.has.map { type = "asset:tilemap", optional = true }
.has.position "vec3"
.has.relative "boolean"

function warp:canExecute()
    if not self.target then
        return false
    end

    if self.map and not self.target:is "player" then
        return false
    end

    return self.target:has "position"
end

function warp:execute()
    if self.map then
        physics:set_map(self.map, self.target)
    end

    local x_offset,y_offset,z_offset = 0,0,0
    if self.relative and self.parent and self.parent:has "position" then
        x_offset = self.target.x - self.parent.x
        y_offset = self.target.y - self.parent.y
        z_offset = self.target.z - self.parent.z
    end

    self.target.x,self.target.y = physics.map.data:to_world_coords(self.position[1], self.position[2])
    self.target.z = self.position[3]

    self.target.x = self.target.x + x_offset
    self.target.y = self.target.y + y_offset
    self.target.z = self.target.z + z_offset
end
As you can see above, our friend here has target_actor. So an instance of it can be will fit any behavior slot on the trigger Schema from before, causing it to fire in response to actors. Ooooor, you can just make a warp by hand and call it directly:

Code: Select all

my_action = warp:new {
    map = "map_3.lua",
    position = { 12, 23, 1 },
}

-- Later...

my_action.target = player
my_action() -- The player will be transported elsewhere
To some people, this probably doesn’t make much sense–I’m not defining ‘classical’ arguments or return values, you can call a function only for it to do nothing after failing a precondition, and there’s no way to decide what behaviors a schema even has attached… until you consider the context.

In a game like this one, you want to jam little scripts and triggers onto everything. It’s one of the primary things you’ll be doing when making new game objects and npcs! That is why behaviors are the way they are.

There’s a bunch more stuff packed in here that’s hard to show, such as schemas implicitly supporting data versioning or the way that properties can be ‘unmanaged’–left to the programmer to handle manually with no defined type associated to them, but still partially accessible to the overall system via callbacks. The overall end-result is that every piece of data built on top of this system is very well defined in structure, inherently serializable/deserializable/cloneable, and can be easily inspected & edited in the editor UI.

Speaking of editor UI, how’s this for a glow-up?
A screenshot of the game's level editor at the start of this development cycle. An object is selected, and there are some properties just kinda floating and text and buttons in the bottom-left corner, overlapping the map itself

before...
Image

...and after!
Image

At this point, I’m confident that I can edit actors & triggers just as well as I was in Tiled. It’s all generic too, I can inspect & edit any structure built with the system I mentioned above. When I find the time, that will make for a very nice in-game debugging tool.

Just for good measure, I also wrote a little script that loads any asset, walks the fully dependency graph, and returns a complete list of referenced assets that can be reached from the source you gave it. It’s limited in functionality still, but it’s a step towards a loftier long-term goal: Knowing exactly which assets are actually used in the game outside of debugging / dev, so I can slim down the final package. It’s not a big priority for now though, I’m just testing the waters with my new toy!
User avatar
Hugues Ross
Party member
Posts: 112
Joined: Fri Oct 22, 2021 9:18 pm
Location: Quebec
Contact:

Re: Untitled RPG Project

Post by Hugues Ross »

Assuming I can keep to this sorta '1 post every month or so schedule', one thing I'm tying to the associated 'tempo of development' is the idea of a screwing-around week. Basically, every 4th week I'm not allowed to touch my main task at all and have to work on other stuff. I'm probably not going to draw too much attention to them, but that's where the little log in the corner of the screenshot and the dependency-walking script came from.

There are so many little things that get swept aside with a project this big, so I'm hoping an extra bit of 'un-allocated time' will help catch them better.
zingo
Citizen
Posts: 55
Joined: Mon Jan 16, 2023 7:34 am

Re: Untitled RPG Project

Post by zingo »

I'd like to believe I understood...at least some of that. The concept seems very flexible and well structured, anyway. Maybe I'll look into "type systems". My own approach, thus far, has been a bit more...direct/hardcoded (to say the least), which may prove problematic in the long run with the addition of more systems/components :death: , but suits my linear/pragmatic way of thinking for the time being.

I scrapped the whole idea of any kind of "editor" soon after realising I was spending considerably more time and energy on that, than the actual game :shock:

It's good to know your health is currently...healthy :) and you may be posting more regular updates. Really anticipating a playable demo sometime in the future. It seems there aren't very many completed RPGs in the love2d framework (that I'm aware of) other than "Inexperienced Knights", "ItsyRealm", and I think a farming/crafting sim or two. I may be wrong, but 2d, turn-based RPGs seem to be a dying breed now (except maybe as a niche genre, and mostly on mobile platforms).

Keep at it, and thank you for the detailed update.
Post Reply

Who is online

Users browsing this forum: Google [Bot] and 11 guests