Post new topic    
Page «  1, 2, 3, 4, 5, 6, 7, 8, 9  »
Slime Knight
Send private message
 
 PostWed Jan 15, 2020 1:00 am
Send private message Reply with quote
Sounds reasonable. But it has to be taken into consideration, that a locked hero in the reserve shouldn't be able to be equipped then. However a locked hero in the active party should be equipable. Some games have a main character that contests in every fight, so this one might be locked at the first place.

Then we could think about, whether it would be interesting too, to look at stats or spells from heros in the reserve. It would be just practical, or else you shuffle through your party to put the healer in the active party to use an out-of-battle healing spell, and put it back, because it isn't necessary in the next combat.
Liquid Metal King Slime
Send private message
 
 PostWed Jan 15, 2020 2:22 am
Send private message Reply with quote
A bit off-topic, but this reminds me, a feature to swap heroes in the middle of battle could open up some fun possibilities, and maybe might be easier to implement than increasing active party size
Liquid Metal Slime
Send private message
 
 PostThu Jan 16, 2020 8:00 pm
Send private message Reply with quote
I've always disliked making it even possible to recruit more than a total of 4 heroes just because of the kinds of logistical headaches having active and reserve heroes brings altogether. One variant I did like quite a bit in a professional game was Dragon Quest 4; you get a total of eight full heroes and one lesser AI hero who doesn't get experience and if your entire party gets wiped on the overworld, your four reserve heroes jump out mid-battle and take over from there but if you go into a dungeon, half of your party stays in the wagon so you have limited inventory access and a party wipe in-dungeon is a game over as normal.

I sometimes mull over the idea of writing a game over script that, while not having the reserve heroes jump in mid-fight, still has them step up if there are any of them remaining.
NO EAT
Metal King Slime
Send private message
 
 PostSun May 31, 2020 8:04 am
Send private message Reply with quote
Gorgonzola retrospective

-227 svn commits (by James and I)
-32 bug reports
-about 30 fixes to reported bugs (and a bunch of unreported ones)
-0 devlog entries

I'm really bad at blogging.

Gorgonzola was meant to finish a bunch of features that weren't done for Fufluns, but the only one that actually happened was sprite transparency, and that was quite last-minute. I had even planed on posting a new devlog thread, "G is for Graphics".
I lost a lot of time to converting the buglist to github (adapted and wrote tools for bugzilla-to-github and sourceforge-to-github conversion), lost access to my OHRRPGCE files for two weeks due to a filesystem bug at one point, and was quite busy in January.
However I'm pleased with the number of bugs fixed... largely because the release was delayed by a month for bugfixes.

What's new

My plan for the next release (in a couple months) is to focus on animations and graphics, and some scripting features.

It still is, but on a whim I started working on the text renderer. We have a lot of unfinished features not available for use yet, but our "new" (only 8 years old) text renderer is one of the largest. This "feature overhang" (to coin a term) means a small amount of work can have a big payoff. For example, sprite transparency. The overhang seems to increase in each new version, because I often switch to something new before finishing what I was doing.

Anyway I've decided I want to finish many of the features of the text renderer for the next release, including text markup, variable-width fonts, and multiple fonts. But not a new font editor. I'll show off progress next time.

-added "set timer args", for passing arguments to timer-triggered scripts
-plenty of bugfixes already
-added a Slice Editor Settings menu. Press F8 to access it


Also, SwordPlay has been sending me some patches!

One of them orangises the slice editor further and makes the sections collapsible:

I think it'd be good if all similar menu sections throughout the engine worked the same way

He also sent this alternative sprite editor layout and suggested I ask for feedback on it.
(You would switch to this layout using a hotkey)


And more.
Chemical Slime
Send private message
 
 PostSun May 31, 2020 8:15 am
Send private message Reply with quote
blank0010.png
(kinda) important about the drawer layout.

in various canvas sizes you can use more of the screen with this new layout. (thanks for showing it off!)
not to mention the sprite preview doesn't block the canvas. I hope this is worth considering Angel
I think about it every day, and how much I'd love to be able to draw on that corner of the canvas

really previews should be toggle-able to view, maybe with the next/previous frames and some functions to test or preview animations?

But its wholly invalidated by the new animation editor and slice-based layout later on. Right?

If anyone has suggestions for the drawer layout, just throw them out there.
Metal King Slime
Send private message
 
 PostSun May 31, 2020 10:18 am
Send private message Reply with quote
The animation editor will be completely separate. The sprite editor ought to gain features to help drawing animations like previous/next frame buttons and onion skins. Nothing to invalidate.

The sprite editor bothers me every time I enter it too. I made a very small start a couple days ago on converting it to slices so that it can use run at more than 320x200. Then the different layouts would just be different slice collections.
But if you maximise the window it would be pretty awkward if the canvas was at the top-left and the palette over at the far right and the tools at the bottom. And maybe you don't want to edit a walkabout at 40x zoom. So alternative layouts might be a useful way to solve that.
Liquid Metal King Slime
Send private message
 
 PostSun May 31, 2020 12:38 pm
Send private message Reply with quote
I think it looks nice!
Liquid Metal Slime
Send private message
 
 PostSun May 31, 2020 2:57 pm
Send private message Reply with quote
bootler appearing.gif
TMC wrote:
text markup, variable-width fonts, and multiple fonts

Ooh, I wonder if someday we'll be able to do silly things like this with our text
Metal King Slime
Send private message
 
 PostSun May 31, 2020 4:51 pm
Send private message Reply with quote
Well yes, I *had* planned on adding "wave" and "rumble" animations, with adjustable amount, and random or cyclic colour swapping. Any others?

Drat, hosting images on CP backfired.
Slime Knight
Send private message
 
 PostSun May 31, 2020 10:34 pm
Send private message Reply with quote
Very nice. AND congratulations to Sword for his contributions!
Metal King Slime
Send private message
 
 PostSat Jun 06, 2020 4:43 pm
Send private message Reply with quote
I've been doing lots of work on getting the new text rendering ready for use... and am amazed at how much work there was and still is to do. It seems that an awful lot of what I had was just a mock-up. For example the markup syntax was placeholder and incomplete. And most much of the font system needs rewriting or doesn't exist at all.

I've finally managed to convert text slices to use the new system for wrapping text by ensuring it behaves (almost) identically to the old way. (If I were to add a image to this post it would be a picture of a text slice, and a second identical picture of the same text slice.) This is is a major milestone.

I've been discussing text markup syntax with James. We decided to use something similar to bbcode. For example [.b]this is bold[/b] and [.col21]this would be colour 21[/col], and...[.w] that was a half-second pause.[.wkey]

We can't just use bbcode because many games already use bbcode-like text (and I don't want to add a backcompat bit for this).
In fact after scanning over 2000 games containing 658473 textboxes, 101674 attacks, 336286 items and 4967 scripts containing strings I found 3722 bbcode-like tags, like [ESC], [X], and [Suchfunktion]. But just two instances like [/Demo] and a few games using the [. ] syntax, like [.75x,lux,raises ATK] or [...for a cost]. None of those games will be affected.

(Writing the script to do that scanning did take a while.)

I also fixed some small Foemap Stats bugs.

Before, I didn't detail another patch by Sword: to show tile number in the tileset editor, and color and x/y position in the tile editor.
Chemical Slime
Send private message
 
 PostSat Jun 06, 2020 5:33 pm
Send private message Reply with quote
i'm not sure why the sprite drawer still covers the corner of the canvas. albeit a different corner.
Is my suggested layout so abysmal?
Metal King Slime
Send private message
 
 PostSun Jun 07, 2020 3:52 am
Send private message Reply with quote
A different corner, huh? I haven't changed anything.

In order to add an alternative layout I would first need to either add more entries to area() with the location of text which you moved, like UNDO, MIST, ROTATE, or otherwise convert the layout to a slice collection.
Chemical Slime
Send private message
 
 PostSun Jun 07, 2020 7:37 pm
Send private message Reply with quote
You can see in the screenshot I posted how I might suggest it to be laid out. However the Undo/Redo butons should maybe change shape and location.
For example, using icon instead of word "Undo" "Redo" and stacking them vertically.
They could possibly even fit next to the frame/drawer data if it were shuffled along a bit.

We could use even less room if word Rotate section were similarly replaced with icons
Metal King Slime
Send private message
 
 PostMon Jun 08, 2020 1:44 am
Send private message Reply with quote
Yes, instead of <-Rotate->, clockwise and anti-clockwise rotate icons would be nice (with tooltips of course).
The prominence of UNDO and REDO is a little odd. They could be replaced with smaller "Undo" and "Redo" icons or text (small text is nearly a thing!). (Wouldn't want to use arrow icons, there would be too many different arrows.) But we aren't running out of space. In fact, I want to make all the draw tool buttons bigger. They're tiny.

A different topic, but since I'd like to eventually merge the sprite and tile editors (they share no code at all) that means I'd rid of the undo/draw history in the tile editor too, which is such a DOS-ism. You see, the undo history display on the screen IS the undo history! When you undo in the tile editor it copies a 20x20 piece of the screen video page back to the tileset. That was the easiest way for James to implement undo, and saves memory too. Hypothetically the undo display is useful for comparing changes, but I don't think I ever got much use out of that.
Display posts from previous:
Page «  1, 2, 3, 4, 5, 6, 7, 8, 9  »