KAELAN'S PROFILE

After spending forever working on completing my battle system, it started becoming more and more obvious that the rough, boring grey-on-black programmer art UI was holding my game back more than anything else.

But I can't art, so I tried doing rips & edits from various places (then writing a bunch of menu code to hook everything up). Results:

Edit: Ehh, this forum doesn't like large screenshots. Resizing. Gonna make them a little blurry, unfortunately. Click for full size.

Nonsense, the Sun is a perfectly fine journalistic publication



I'm originally from Brazil, living in the US right now. But, like most people, don't have the money to be travelling right now and like you I don't really care that much about sports in the first place. That said, I'll probably end up watching most of it anyway

author=CashmereCat
@KaelanThat's a really complicated system. Hopefully you have a nice little tutorial to help newbie players like myself understand all the options.

Yeah, I recognize how complicated it can seem at first. I'm doing as much as I can to make it approachable without taking any of the complexity out (since that's what makes it fun). At the start of the game, you'll have only one character and you'll start with only Move/Attack commands. The first few encounters will each introduce a couple new actions at a time, and you'll gradually find new party members one at a time as you progress through the tutorial, so hopefully it won't be too overwhelming.

After that, once the game has properly started - and I didn't show this in the video, but it's already something that's in-game right now - if you right click on any of the actions in the menu, it pops up a tooltip explaining what that action does.

Portraits are from old school infinity engine games (NWN, Baldur's Gate, etc.), most of the rest is from PV Games

Actually, I am doing a tactical RPG. It wouldn't make any sense for me to run it completely pixel-based, it would just make everything more complicated for no good reason (all of my system rules - except the targeting - are currently setup to use tiles as a unit of measurement). I like the "neatness" of tile-based systems anyway.

But yeah, I am treating tiles roughly like giant pixels, in the sense that if any part of a tile that intersects a shape, the whole tile is considered to be intersecting the shape. Handling the intersections is fairly straight-foward with some basic collision tests and little linear algebra. That's not really the problem.




The part I haven't quite figure out yet is mostly the visuals: how do I actually draw shapes on the screen (and have them actually look good and be of arbitrary sizes), given that RM doesn't seem to have methods for directly accessing the lower level graphics functions.

I thought about maybe using pre-made images for the circles, then resizing them to the appropriate size as needed and keeping high-resolution versions of key size categories so the final thing never gets too distorted (like a kind of mip-mapping system, I guess?). That might work for circles, and I suppose it could work for lines if I stretch them vertically before rotating them (to avoid pixellating the hell out of them) but it's still probably not quite going to do the job for triangles.