Post by Cupid Hyci in The Stars Here Below jam comments

RPG Maker MZ Touch the Stars Game Jam » Entries » The Stars Here Below

Viewing post in The Stars Here Below jam comments

[jokinglyly]Ouch, I'm going to react badly and blame you for this game I worked on in less than two weeks being kinda bad![j/okingly]

Some of this stuff I kinda already knew were problems, but I didn't get to fix for one reason or another. (Like the prices and the UI) Some of it's because I've never made a real game before and am very green.

As for the Lightning area - it was supposed to seal all yer equipment but that seemed unfair so I changed it so Acc. stayed on and forgot to remove the fact that I told the game to remove them.

I'll keep this all in mind for future projects (and probably going back to fix this one in the future tot he best of my ability). Thank you for yer input, it's very important.

Like Reply

AI Sin3 years ago (1 edit) (+1)

Yeah, I mean I did my game in about the same time, but I have quite a bit of experience with RPG Maker in general (My total usage time is only 249.5 hours for RPGM MZ, which amounts to about 10 or so days including the time I've had it up post contest and the time I've had it up before the contest, but I've also clocked over 5250 hours in RPGM MV).

One thing I will suggest is to really get to know common events. You have some events that repeat and could be better controlled with a common event as they all do the same thing at some point. There are pros and cons to this, but the biggest pro is it makes editing easier if you decide to make changes. Instead of changing 14 or so events that all do the same thing, you have them all call the same common event and you change one common event to change all those events that call that event.

Also, as a note, the happiness ring from the statue will only work on the character it is equipped to unless you have a plugin to spread the effect.

I forgot to mention this here, but also, that shard kept showing up when doing the keys. Personally, the shard should've either been removed from the inventory on use or been a lower number than the cards so that the cards show up first.

I highly recommend that in the future, you give yourself at least 1/5th of your time to do playtesting and fixes if you don't have a dedicated playtester and 1/10th to do fixes if you do. This isn't industry standard, but it gives you some leeway to see if anything is wrong and then make changes.

Like Reply

Cupid Hyci3 years ago (1 edit)

Over 5000 hours, I don't even have half of that. (cries)

But silliness aside - I need a lot more practice if I'm gonna make anything truly professional feeling. I'll keep working hard. If you think of anything else let me know, this kind of feedback is really important.

My tester for this game was my brother and co-partner for game creation (although he didn't help much outside of test playing with this game). I worry he was a bit to lenient on the game so I'll search other people for later games - which would be wise anyway since he works on most of those games too lol.

Edit: I'll totally have to give yer game a play through - beware though - I won't hold back MY harsh criticisms. :D

I'm kidding.

Like Reply

AI Sin3 years ago(+1)

Generally those too closely involved in the creation of something are either too critical or not critical enough.

When playtesting something you've worked on, there are a few things to consider, including:

Having worked on the project, you are:
- Better informed about your project than others. What seems obvious to you might not be obvious to others.
- More used to the project than others. What might seem obvious to others might not stand out to you.
- More prone to ignoring mistakes, errors, etc..
- Able to work around mechanics and puzzles more easily due to knowing the intended solutions.
- Have a hard time seeing alternative solutions due to already knowing an intended solution.
For effective testing, you want to:
- Be able to step back from the game. No longer see the game as 'your' game, but as 'some stranger's" game.
- See the project from the perspective of a player:
  - With no preconceptions.
  - With preconceptions from similar games.
  - That has just beaten the game.
  - That has spend a long time away from the game.
  - Doing a new run/from a previous game of a series.
- Be able to consider playstyles different from your own/what you expect.
- Really want to try to break the game. Look for ways that you can break the game.
- Try the consider how the game might behave under different conditions. If you have a really powerful rig and a cheap rig, you can do a test on both rigs. If you have just a powerful rig, you can use emulators or other methods to simulate a weaker or different rig. (Like Windows 10 and Windows 7 and Windows XP might all handle the same game differently and have different bugs). One very common issue is the game behaving differently at different FPS values. So like a game might be fine at 30, 60, 120, 144, then break at 146 and higher. A game might also be fine at 300,144,120,60,30, then completely break at 28.
- Ignore your own personal feelings, but also consider in feelings.
  - Example of why to consider in feelings: How is a scene supposed to make you feel? How does it actually make you feel? If your MC's father dying is supposed to be a sad scene, but you feel happy about it because the father was a jerk, then the scene isn't working as intended, as an example.
  - You don't want your personal emotions to cloud your judgement. (Having emotions affect your judgement is normal.)
For effective fixing of issues, you need to:
- Understand how bugs and issues happen. The better you understand the problems (and solutions), the faster and more thoroughly you can fix problems.
- Be able to understand what problems your fixes might cause and avoid those problems.
- Be able to prioritize what is important and what can wait.
  - There is a development side to this choice: Budget, Time, etc. can affect that side of the decision.
  - You also want to consider in the user/player side of this choice: What issues are the players going to see? What will a player be willing to deal with and what will a player find frustrating to the point of quitting?
  - Balance what the players will want with what makes sense from a developer standpoint.
    - For example, players see new UI as being most important, then sound, then a few minor graphical errors. Your budget provides enough to fix one UI issue, or two sound issues and one minor graphical error. Your time left allows you to fix two issues. Which do you choose? You could fix just the UI, which the players want most, or Sound and sound or sound and some graphic error.
      - This is actually more complicated than just that as what will the players find most annoying. When they just started, what will make them quit before giving the game a chance vs what will make them quit over a longer period of time? Which is more important to prioritize? There are many more factors to consider and you also have the issue that you can't spend a lot of time making that decision because that is spending time and possibly money.

That isn't an exhaustive list, but those are some things to consider. I put some of the ones that are harder to do in italics.

Like Reply

itch.io

Viewing post in The Stars Here Below jam comments