v0.16 Discussion

[clintbellanger]

Let's discuss the release of v0.16.

We have several important new features already. Some are WIP but nearly finished:

• A-star Pathfinding
• Spawn creatures via Powers
• Patrolling Enemies
• Transform to any existing creature
• Permadeath
• (WIP) Config Menu
• (WIP) Flying creatures

With Flare being in so many high-profile repos now, the Config Menu especially is a nice feature to release. I'm glad it's gotten bumped up from 0.17.

Are there any other features you think we need in this release?

Are there features you're interested in working on, but feel it can wait until v0.17?

[clintbellanger]

In this post I will keep a list updated of remaining tasks for v0.16.

• Update collision routines for flying/incorporeal creatures (v0.16, assigned to clintbellanger)
• Create a map to showcase wyverns (v0.16, unassigned)
• Keybinding functionality (v0.16, unassigned)

[dorkster]

For the config menu, I've added a background image to make the tabs look better. Also, maybe the keybind options on the input menu should be functional for the v0.16 release.

[igorko]

Note that standart InputWidget lacks functionality for key bindings. So we can either create new widget or extend current functionality. Clint said we should look into other SDL projects to make correct decision. Also joysticks combobox is stubbed. I don't have joystick so even didn't try.

[dorkster]

I'd be for using a button-type widget. Changing a key would go as such:

1. Click button
2. Display prompt asking to redefine action 3a. If the user presses a valid key, assign the action to that key 3b. If the user presses Escape (or a similar key), cancel the prompt

[pennomi]

I agree with the solution proposed by dorkster.

One issue I keep having with the screen resolution page is that it doesn't have enough defaults for people whose graphics cards don't support many resolutions. I'd recommend adding in at least a few more "obvious" resolutions, like 800x600 and 720x480.

In addition, I think we should look into automatically resizing the window when the new resolution is applied. How hard do you think that would be?

Another highlight to this release would be "permadeath mode."

[pennomi]

Clint, what about "swooping AI"? Is it complicated enough that we should pause on that for now?

In the short-term future (eg. next month) I'd like to see support for non-iso tilesets, so Flare can be a possible engine for the Liberated Pixel Cup. If you think it will take enough time to polish off the other features, I'd be happy to try coding that one up for this release.

[clintbellanger]

I'll be attempting the swooping AI. If I can't get it done in time it's not a terrible thing (the wyverns will still look cool).

[wokste]

The TODO list can be as large or small as you want. Personally, I would just set a release date and see what features are included at that time.

[igorko]

"Transform to any existing creature" can be marked as "basically working".

[clintbellanger]

One note about keybinding: capturing the keybinding ID is relatively simple in SDL. But showing the player what character represents that key is harder. E.g. the keycodes for WASD on a qwerty keyboard are reused for completely different characters on azerty.

We'd want to display the bound key in the config menu and on the action bar (currently we have a static png overlay that shows the default keybindings, which is old/silly).

We'll need someone to research this. Other SDL projects have dealt with it, and we want to see what they've done.

[igorko]

I'm for changing current mods list tab schema to next:

I have done needed changes in my WC. But IMHO WidgetScrollBar should be reworked. Except slider is missing. i think buttons should be moved inside ListBox. how it is planned for log.png. And buttons art should be more "standart". like rectangle with an arrow

Also we could add tooltip to button Widget to display Move Up, Move Down text

[igorko]

Maybe something like http://imageshack.us/photo/my-images/839/scrollbardefault.png/ , but width should be as in log.png

[dorkster]

I like that layout igorko. I made some changes to the scrollbars, so now they won't be confused with the other buttons. They're 15 pixels wide now, so they should fit well on log.png. http://i.imgur.com/sKzLL.png

[clintbellanger]

Note that the Inactive mod list doesn't need move up|down buttons. It's used in active mods because it denotes load order.

[igorko]

Done. The question. that remains is the main question: Issue #206 is still open, so this can lead no unexpected situations. This can be reproduced even now: create some test mod. that uses orthogonal tiles, and loading old saves(isometric) will cause broken graphics. So we can do next:

1. Rename "Inactive mods" listbox to "Avaliable mods", and avoid changing it
2. This will always display the right order of mods to allow revert changes and avoid errors
3. Mark tab as "Huge experimental", or do not mark :) (In other words be aware that you can break stuff)

[pennomi]

Most people who will be adding mods will know that doing so can inherently break the game.

However, in order to alleviate the chance of a Total Conversion type mod wrecking the player's existing saves, I recommend some form of an engine setting called "game prefix" or something that will stop saves and configuration from colliding.

So instead of having save1.txt, all data files could be [game name here]_save1.txt and [game name here]_config.txt, etc.

In addition, it's likely that different games will ship with different versions of the engine, so I'd recommend we find a way that the binaries don't collide.

[clintbellanger]

We'll probably have other options for people doing total conversions. E.g. specify a data/config/save/bin folder name besides "flare".

[pennomi]

In that case, we won't worry about people making an ortho mod for an iso game. My guess is that the mods will all be somewhat compatible for any given game.

[mothmaster]

Hi, I recently delved into the code and whipped up a config menu combo-box option for the difficulty level. Basically I'm using a multiplier to increase or decrease (or leave untouched) the initial MaxHp of creatures, as well as the damage they deal out. Currently I have Easy = 0.75, Normal = 1.0 and Hard = 1.25 as difficulty modifiers. These are all stored in a text file in the usual manner, so could easily be modded. I tested it and it seems to work pretty well. Would this be of interest?

[clintbellanger]

mothmaster, that's a very interesting feature. Let me think on that for a bit. On one hand, It may not be practical to be in the basic engine (would it make sense for most games made with Flare? don't know yet). On the other hand, it might not hurt to add it now and devise a more practical solution later. I'll get back to you on this.

[mothmaster]

I guess my motivation for this was from playing the game where I initially found it a little tough. Now obviously, it's not a game yet and the gameplay is not balanced, but in general allowing players to customise their experience in order to avoid frustration is usually a good thing. I tend to like to play games that are forgiving to begin with, and then have the choice to ramp up the difficulty level, but that's just my preference. However if it doesn't fit your vision for the engine, that's cool :)

[dorkster]

I'd be for a character creation setting (like permadeath) for difficulty. The player shouldn't have to be messing with the difficulty level as they progress just to have a good time. The game should be balanced so that it's forgiving at the beginning, and harder later in the game after the player's gotten used to the fundamentals.

[Bertram25]

Hi,

My apologize if it isn't the right place to put this in:

• I was confused when I created a character and saw the permadeath checkbox. Do you have a tooltip or a similar feature? Would be maybe better to explain it a bit, IMHO.
• Unchecking the 'Use Joystick' checkbox doesn't disable joysticks input and I'm forced to use the 'move with mouse' option, or my character goes random because of a virtual joystick seen by my system (using Debian).

Otherwise, great changes so far :)

[igorko]

@Bertram25 Joystick combobox is not yet working, though checkboxes should work ok. Joystick number can be changed manually in settings txt. Also see issue #288, maybe it's yours case. To use keyboard uncheck both Joystick and Use mouse checkboxes. This SHOULD work.

Permadeath == Permanent death, means that you can die only once and can not resurrect :) Because that savegame is deleted on death. This is common game term. See http://en.wikipedia.org/wiki/Permanent_death

[Bertram25]

@igorko Thanks for your answer. :)

I'm indeed concerned by issue #288. And yes, this is working as for the latest master version with both check-boxes unchecked

But yet, even if permadeath (I knew that with pain in Diablo II) is a common game term, its meaning isn't clear about whether the player can still be restored through a game fee, or has a limited number of return. Anyway, I get the point. Best regards,

[igorko]

@Bertram25 "Unchecking the 'Use Joystick' checkbox doesn't disable joysticks input". Sounds strange. But anyway in latest master it should work.

[dorkster]

Note that Flare needs to be restarted after changing joystick settings in order for it to take effect. Would it be possible to have these changes take effect during runtime?

[igorko]

@dorkster Well, It should work for Default/Cancel buttons, but looks like i have missed logic for Ok button. try to add: if ((ENABLE_JOYSTICK == 1) && (SDL_NumJoysticks() > 0)) { SDL_JoystickClose(joy); joy = SDL_JoystickOpen(JOYSTICK_DEVICE); }

to ok_button->checkClick().

Does joystick combobox work for you now?

[igorko]

Also as for me GameStateConfig.cpp should be cleaned up a little. Some code can be moved to and from update() function to avoid unneeded calls and to make code more compact. As a lot of this code is my, it would be nice someone to check it with fresh look and optimize code if possible.

[dorkster]

igorko's suggested that the Input tab on the Settings screen be made scrollable to accommodate a more clean layout and larger buttons. However, implementing this has proven to be troublesome. The way that widgets are positioned and drawn right now, there's no way to "trim" them within the confines of a rectangle.

So instead of overhauling everything just to get this all to work, I'd like to propose something different. I'm thinking about having 3 tabs: Input, Keybinds 1, and Keybinds 2. The Keybinds tabs would have the buttons for changing bindings and bindings_alt. The Input tab would contain mouse, keyboard layout, and joystick options. I don't think this will cause much confusion, since lots of other games separate input options from keybinds.

[igorko]

Maybe we could just change widget positions on scroll, and not draw them if position is out from 640:480 rectangle?

[igorko]

@dorkster I have pushed pull request with my implementation. Knob doesn't work yet, but the rest is ok.(Label position check should be little different)

[clintbellanger]

The way I'd implement a scrolling pane, assuming the visuals of the pane are not constantly changing.

Make the pane an SDL_Surface * as a buffer, the entire size you need it (scroll length and all). Redraw the entire buffer only when something changes. Then each frame, draw the buffer to screen (trimmed by the current scroll position).

[clintbellanger]

Great work everyone. The code tasks are essentially done. Closing this issue as we've covered the original purpose of the thread.