next »

[MCSquared21]

Fantastic detail on the enemy sprites, and the music and sfx feel very true to your source inspirations. Great stuff!

[qMopey]

Posting for follow. Love the art work

[qMopey]

Played demo 0.4 about 6-7 times. Had my girlfriend play it as well. Here's some feedback notes in no order whatsoever:

• Love the straight-to-the action style. No items to fuss with. No menus to navigate. No resources to think about, just into the parts of old-style RPGs we all love; walking around, talking to people, cutscenes, and doing some battles.
• Really enjoyed the menu. All the menus. The menu for saving the game was a delight! As the save menu opens the expectation is to hit z or x (yes or no) and for it to just work. No annoying confirmation dialogs. No selecting a save file. It was great. The menu that can be opened in the world map was also a joy. It perfectly matched my expectations. I was looking for exp to next level, and for tech options. It was perfect. No clutter, no annoying odds or ends to learn/navigate. Very polished.
• Battles were super fun. The concept of optimization the 6 slots of damaging an enemy was really fun. It is very easy to understand, and very easy to jump in an start playing. No prerequisite knowledge necessary. I'm a little worried battles can get boring for players as time goes on, but I'm sure that's a solveable challenge. The worry is that the battle system may be a little too shallow to support a grindy style of content, but this can be avoided through playtesting iteration.
• I'm not sure if I remember correctly, but the secondary character that casts fire (Jacob?) seems to do 2 damage if he is low on HP. Is this true? I didn't test it, but I think I saw it happen once or twice. If so this was a very memorable touch! Adding in nuanced battle mechanics for players to discover is enjoyable, memorable, and exhilarating.
• Music kicked ass. My girlfriend and I (and my friend who was there at the time) were all humming the theme from Ogul town the rest of the day after we played.
• Beginning dialog kinda sucked. We all quickly wanted to skip the conversion in the first room with the main character's friend. The dialog itself was hard to read and required a bit of focus to comprehend. It felt fragmented, and made references to things we didn't know anything about. The opening dialog didn't really match the easy-to-jump-in style the rest of the demo achieved.
• Beginning fight with the humanoid zombie creature was great! Very fast intro to fighting. A good cinematic effect. Well executed. Everyone enjoyed it.

If you're open to recommendations I would like to make one: your game is in a great state. We all enjoyed it, there weren't any glaring problems in the design. Start making more content, a lot more, and get as many people to play it and provide feedback as possible. To me it seems clear this would be the best approach to get your game through the next stage of development.

Your core mechanics are solid. Your art style is captivating. The music is a delight. Make more content and get it into player hands. Get some feedback, and repeat.

P.S.
Stop deleting your old videos! I found your old thread and was really annoyed your old videos were removed. It would have been very fun to see old screenshots and old pieces of content (it would be super cool to still have access to old playable builds). There's no shame in keeping them around, they are valuable! Luckily some other members quoted a couple images so there are still a few glimpses laying around from 2011-2012.

[qMopey]

I wanted to ask, how did you implement the GUI menu (File, Input, Display, Help)? I was looking around at a nice way to implement these features, but I was hoping to keep non-cross-platform code to minimum, and was also hoping to keep dependencies down. I don't want to include a giant library just to add in a little menu (like wxwidgets or qt).

Did you just use raw win api calls? Or some other library? I'm curious  

[qMopey]

I ended up implementing a menu much like yours, but with a couple extra goodies. I imagine your source code looks something like:

Code:

HWND hwnd = win_get_window();
HMENU menu_bar = CreateMenu();

// ...
AppendMenu( ... );

SetMenu(hwnd, menu_bar);

And of course the callbacks for WM_COMMAND need to be setup through WNDPROC. In case you, or anyone else was curious, this is actually easy to setup even when using SDL2 via SDL_SetWindowsMessageHook. It looks like the equivalent for winallegro.h would be: win_set_msg_pre_proc.

I take it then your games only run on Windows then? For my own code I'll have to figure something out for Mac/Linux... I was thinking of just using a .ini file instead of writing code to support the menu bar on other platforms. A simple .ini files is cross platform. Most people play games on Windows, so the OSX/Linux users can just deal with a .ini file.

Here are the points I improved after I implemented a menu very similar to yours:

• Changing the pixel ratio from a lower to a higher ratio can place the window outside of the user's screen. This can be really annoying. I implemented a window position clamper; when the ratio is changed the window is clamped within the screen boundaries. I used AdjustWindowRect. It's actually pretty easy; create a RECT on the stack, initialize it to zero, hand it to AdjustWindowRect, use for style WS_OVERLAPPEDWINDOW (it's a good default). The returned RECT will contain border + menu width/height. Add the rect width/height to your game's current pixel resolution, and clamp the position within bounds of the screen.
• Changing the pixel resolution does not retain the window's center position. The scaling happens from the upper left corner of the window. This is annoying as user will typically center the window on their screen manually, and then adjust the pixel ratio. Then the center of the window moves, and the user must manually adjust the position again. I implemented the scaling ratio callbacks so they scale the window from the center, instead of default top left.

Edit: I also noticed you seem to prefer the check marks for your pixel resolution? Did you use a bunch of CheckMenuItem to manually mark each resolution (1:1, 1:2, 1:3, 1:4) to check/unchecked? I was surprised to see that, since there is already CheckMenuRadioItem. It doesn't use the checkmark visual effect, and instead a circle.

Also I noticed you added in a bunch of MF_SEPARATOR with AppendMenu. Any reason? Did you just think it looked cool? Haha  

Edit2: Wow I just noticed you already have your own .ini file setup. Funny

[qMopey]

How have things been?

I still have friends try this out occasionally! Everyone loves it and wants to see more.