Grauw’s RPG in development

Ascended (10859)

19-03-2018, 00:19

Since I showed an early build at Nijmegen already, and also posted about it in some other threads, I figured I would create a thread for the MSX2+ mini-RPG I’m working on, so I can share my progress, ask questions and get feedback.

The goals for this game are:

Pretty SNES-style graphics
Running at 60 frames per second
Limited scope, finishable
A few hours worth of gameplay
Dialogue, quests and puzzles, but no battle mode
Hopefully done in time for MSXdev’18

p.s. No official announcement so no need to post a news item . Will do when I decide on a name.

By Grauw

Ascended (10859)

19-03-2018, 12:38

The current status is that it’s still very much in its infancy, graphics-wise I’ve done some experiments in the pixel art thread, practicing drawing and animating the graphics, and how to use the limited number of palette colours most effectively.

Some artwork I posted in the pixel art thread before:

Character outline experiments

Character outline conclusion

Integrating objects with the environment

Different character style (face, hands) + orientations

Running animation

Note that these are in no way final or may not even be used in their current form; I’m still in the research phase, working on establishing the art style and process before I move into production work.

There’s still a lot to do art-wise. Aiming for three environments with tile animations (village, field, cave), character animations, a few particle effects, and some bigger intro/outro graphics. I think that’s achievable :).

In terms of game code, what I’ve got right now is a scrolling play field rendered from a tile map with 16x16 tiles, with a character displayed on it using eight sprites. The two big items I should do before it really starts to feel like a game is collision detection and triggers, and dialogue boxes.

I previously posted about some of the challenges I faced, as of this week I’ve optimised the sprite code so that the game runs at full 60 fps at all times now. The way I managed sprites previously was really too complex, it’s much simpler and faster now. I should really learn not to overengineer things ;). I still need to do that 30 fps game update loop with 60 fps motion idea, but that’s pretty close to completion.

In the mean while, since I got the sprites in better shape, I had a stab at a nice full screen rain effect. Took me just an hour orso to make, nice evidence that the sprites code is good now :).

Video (make sure to watch at 60fps): ▶️

By santiontanon

Paragon (1868)

19-03-2018, 00:43

Very cool! Are you planning for action-RPG style combats like Zelda, or turn-based combats like Final Fantasy?

By Grauw

Ascended (10859)

19-03-2018, 00:58

For a potential follow-up game I’d like action RPG, but I’m not adverse to turn based either. I like how Chrono Trigger’s encounters work; enemies are fairly static when walking around (just tile animations), and when engaged the scrolling stops. So in battle mode one could use softsprites for the enemies and player, possibly 30 fps, and dedicate sprites fully to effects. Seems like a good way to focus VDP resources.

But for this game, no battle mode . Saves a lot of work, increases the chances of completion significantly.

By santiontanon

Paragon (1868)

19-03-2018, 01:04

Makes sense!! Have you played "To the moon"? ( https://www.youtube.com/watch?v=sqkJuSV-23U ), great game and without combat!

By Grauw

Ascended (10859)

19-03-2018, 01:21

No, looks nice, I’ll watch some vids!

By keith56

Master (162)

19-03-2018, 04:50

The graphics look spectacular! I like the character design!
It sounds like you're really going to optimize all the power out of the MSX2+, but then again I expected no less from you!

I can imagine an RPG could end up a huge task because of the endless potential for sprawling map design, so I wish you luck working on the project and keeping it within a manageable size!

Is it just me, or does the running character look like (s)he has Marill ears?
http://pokemon.wikia.com/wiki/Marill

By Victor

Champion (510)

19-03-2018, 06:14

Woow!!! It looks amazing!!!

Great work Grauw!!! Yeaaahh!!

By alexito

Paladin (761)

19-03-2018, 06:45

Look really good, looking forward for sure and good luck with the project.

By wyrdwad

Paladin (934)

19-03-2018, 07:23

Another cool sprite- and tile-based RPG-like game with no battles is Corpse Party (which I was the translator on, so I always feel compelled to recommend it to people! Heheh), and Corpse Party kind of started a whole movement among RPGMaker enthusiasts in Japan to create horror-themed games with no combat -- other popular examples being Ib, The Witch's House, and -- of course -- Yume Nikki: Dream Diary, which caught on so much that it just had a 3D sequel released like, last week. Looking at what you've managed to do with the system's limitations makes me think a horror title along those lines might be right at home on MSX:

https://www.youtube.com/watch?v=UC6GwS2f3a0&list=PLs4TSfc3PY...

Anyway, sorry for the tangent, but all this talk of RPGs with no battles just immediately made me think of this! More on topic, this looks superb, and I can't wait to play it!

-Tom

By DarkSchneider

Paragon (1034)

19-03-2018, 09:41

Use a clear color for rain, the white or almost white one you have in your palette.

Waiting to see it with the character animated, it seems interesting.

Could I ask what did you changed for sprite handling?

The system we use is:

- Attributes are handled one by one, this is needed because our frame is complex, as you can define offsets of the sprites involved in the animation (something like the Flash games animations but only with translation, no rotation). But we work with a SAT in RAM, that is faster for CPU. Once finished add a sprite in the sprite off Y position and copy that number of sprites attributes data to the VRAM (the offscreen one, double buffered) at once. Later at VBLANK simply exchange the tables pointer registers (double buffer method).

- For data, like color, we precompute the contiguous blocks of sprites per frame, like "0, 1, 2, 3", and with that data we copy all the data involved in a single operation, all in a row. This gives less accesses for larger data, that I think is faster. A typical humanoid character is divided in 2 contiguos blocks, upper and lower body, so they are copied in 2 operations instead the number-of-sprites.

- Only copy this data if the frame has changed. So we store the previous one drawed in that sprite position by its ID, at this moment animation ID and frame ID, that are 16-bit integers autogenerated numbers at load time, we are yet thinking about modifying this. But only the first one and the others are set to 0 (as I think is faster than setting all to the same, so 0 is reserved for no-ID), i.e., we draw animID 1 frameID 1 at sprite table position 2, the frame has 4 sprites, we put [1, 1] at the prevFrame structure position 2, and fill with 0 the next 3 ones (for the 4 sprites), this array has 32 positions for the 32 sprites available. In the next frame, if drawing the same [1, 1] at position 2, then no need to copy. See that setting to 0 the others is needed because we could draw a character at position 0, 1 or 2 taking partially or not taking at all the space used by the previous one, setting them to [0, 0], reserved for no-ID, if we put any frame there, it will be copied.
Anyway, the idea is to apply a basic principle for drawing, the fastest drawing, is no drawing, so using some CPU to save in many cases the need to access to the master bus really gives performance improvement. Tested with many cases (multiple characters on screen with different animations) and the improvement is easily about 30% o greater.