Author Topic: Pokémon Trainer [FIRST PROTOTYPE FUNCTIONAL WO!!!]  (Read 12162 times)

Just a little suggestion, make the yellow in the healthbar more noticeable, and the green a bit darker, they're quite hard to see from just a passing glance.

Are you kidding?
I know how tedious programming GUI can be, that would have at least taken me 8 hours of work.
It looks great!

Does the HP bars work or are they just placeholders?

Just a little suggestion, make the yellow in the healthbar more noticeable, and the green a bit darker, they're quite hard to see from just a passing glance.
Just draw a little black line at the end.

Just a little suggestion, make the yellow in the healthbar more noticeable, and the green a bit darker, they're quite hard to see from just a passing glance.
The health bars are just translucent swatches; I'll increase the opacity. If it still looks goofy, I can use images with the proper colouring.

Does the HP bars work or are they just placeholders?
Yes, the HP bars work based on a given HP value and maximum HP value with the maximum X extent of the swatch.

If you're going for accuracy, the colored parts of health bars display hitpoints with precision out of 48.
So 2 pixels per 1/48 since your health bars are 96 pixels wide.
Is this the same for all games? I'll want to make sure that the bars work exactly the same. It's a pretty satisfying feeling to watch the opponent's HP bar slowly drop to zero.

And it hadn't even crossed my mind how the sprites would scale but they came out perfectly.
All the assets had to be scaled up at least 2x with nearest neighbour. The back sprites were scaled up 4x from the originals because Torque is pretty bad at scaling on its own. You can tell they've been scaled up, but it still looks pretty good. I guess they're pixelated in the games as well.



After making that, I realise that it would be difficult to fill up an entire screen with this kind of thing, so the battle window will probably overlay the centre of the screen or something. The image I get thinking about that makes me itchy though. I guess I'll have to see how it actually looks when implemented.
« Last Edit: December 28, 2014, 02:28:40 AM by otto-san »

The health bars are just translucent swatches; I'll increase the opacity. If it still looks goofy, I can use images with the proper colouring.

I would recommend using GuiProgressCtrls. That'll let you update them extremely easily.

I would recommend using GuiProgressCtrls. That'll let you update them extremely easily.
I use GuiProgressCtrls for the XP bars, the only issue with using them for health is that it has to change its fill colour. Though, GUI handles profile switching pretty well, so I suppose it's really a non-issue.

Is this the same for all games?

Yes. Here is Showdown's implementation of the rounding for pixels and colors (JS):

Code: [Select]
// In-game accurate pixel health mechanics
var pixels = Math.floor(ratio * 48) || 1;
hpstring = '' + pixels + '/48';
if ((pixels === 9) && (ratio > 0.2)) {
    hpstring += 'y'; // force yellow HP bar
} else if ((pixels === 24) && (ratio > 0.5)) {
    hpstring += 'g'; // force green HP bar
}

Of course you can still see the numeric value of your own hitpoints in addition to this.

Did a bit more work, got the backgrounds in.



Nonsense names were randomly generated using an old recycled function from my old wario ware gamemode. my favourite was 'cheetieng'
« Last Edit: December 28, 2014, 06:07:21 PM by otto-san »

So besides battling, is there going to be anything else to the game? Looks good btw.

Edit: nvm, re-read the OP. Will this work with battling other players, or is it strictly client sided?

The actual systems of the mod are server-sided. PvP will definitely be a thing; that's even easier than PvE since they both use the same base systems. PvE just needs some AI.

Technically, the actual mechanics could run on either the server or client side, but the mod will focus on the server->client scheme instead. If someone wanted to modify the code to make a client-sided battle minigame sort of thing, that would be totally possible.

edit:
Working on the other bits of the battle GUI.
« Last Edit: December 28, 2014, 10:40:34 PM by otto-san »

Looks good so far!

Any idea on how you are going to initiate battles?
Is it just going to be triggering an event or will it be integrated somehow in with the botholes?

Because you could use these bricks as tall grass for wild battles:
https://hostr.co/file/6majFpedLiXp/Blockland_00187.png
The brickpack is called Brick_Plant and can be found in the RTB backups.

I don't really intend on using bot holes for anything at this point. I know I'll probably first have a PvP prototype for the battle system, which would be triggered by simply issuing a challenge. Wild encounters would be a bit different. I'm still trying to figure out the specifics of that system. I'm most likely going to use some kind of trigger system. I'm not sure how I'll determine what wild pokemon can spawn. Maybe I'll make some kind of system where you can define wild spawn groups and assign those to the trigger bricks. It would need to be able to save and load alongside the build and be easy to implement and modify.

Wild encounters would be a bit different. I'm still trying to figure out the specifics of that system. I'm most likely going to use some kind of trigger system. I'm not sure how I'll determine what wild pokemon can spawn. Maybe I'll make some kind of system where you can define wild spawn groups and assign those to the trigger bricks. It would need to be able to save and load alongside the build and be easy to implement and modify.
You could split the pokemon up by their element and possible level.
Like have the builders chose an element and then a textbox with minimum and maximum level, which choses a pokemon at random fitting the criteria.
Then (if possible) have multiple event line to have different elements spawning on the same location.

Something like this could be used:
OnPlayerTouch > Client > PokemonWildBattle [Electric] [5] [15]
OnPlayerTouch > Client > PokemonWildBattle [Grass] [6] [16]
OnPlayerTouch > Client > PokemonWildBattle [Normal] [3] [20]

This would initiate a wild battle with the possibility of electric poke between level 5 and 15, grass poke level 6 and 16 or normal poke level 3 and 20.

Of course, legendaries would have their own section.

But I am being overzealous, you need a working battle system first :P

Sorry that I haven't updated the past several days. I've been working on some less visual things like the trainer system and pokemon storage, along with some minor tweaks here and there with existing systems. I'm trying to keep things simple. Ideally, I want to be able to do a quick save(...) on the trainer object to save everything. File size is an inescapable obstacle, but TorqueScript typically executes pretty quickly. At the moment, each pokemon will take up around fifty lines of code each, though. That's 12,300 lines with eight full boxes and a full party from pokemon data alone. Jesus. I guess we'll just have to wait and see.

I've spent a long time ripping UI assets from B&W but it's difficult to apply them in the game since there are some space restrictions. Perhaps I should start out with a more blockland-ish style for the action menu. This mod won't play nice with small resolutions, I'm afraid. We need a lot of screen space for the battle content. Still dreading the day I have to deal with importing a move database.

I've spent a long time ripping UI assets from B&W but it's difficult to apply them in the game since there are some space restrictions. Perhaps I should start out with a more blockland-ish style for the action menu. This mod won't play nice with small resolutions, I'm afraid. We need a lot of screen space for the battle content. Still dreading the day I have to deal with importing a move database.
If you can point out which assets you want in blockland-ish style, I'll see what I can do.

Basically any UI assets for menus and the like. This .zip contains a bunch of rips and rip resources: https://dl.dropboxusercontent.com/u/11058668/asd/ui.zip
The majority of the work is done there, but there's likely still more to do. I have some extra ideas about how to pull off the GUI, though, so it may not be an issue.