Feature Requests Thread
by mtgrares
Moderators: timmermac, Blacksmith, KrazyTheFox, Agetian, friarsol, CCGHQ Admins
Re: Feature Requests Thread
by friarsol » 22 Mar 2013, 00:31
Yea this is exactly right. We have had several devs coming in and attempting as their first task either trying to implement game state (for potential min max) or network play and just burned themselves out in two weeks never to be heard of again. Forge is an old project with a ton of history due to its origins. I'd definitely recommend trying something a bit smaller.myk wrote:Frankly, though, I think this is too large for a first-time contribution. You will be touching nearly all subsystems in this, and each have their own little quirks and histories. It might be wise to make some smaller contributions first, just to get some familiarity with the codebase. It will also give the devs a chance to become familiar with you and get a feel for how likely you are to destabilize currently working code : )
I know Max has been eyeing Network Play for a while, and has been making small chunks worth of progress. But it's definitely not one feature away still.
- friarsol
- Global Moderator
- Posts: 7593
- Joined: 15 May 2010, 04:20
- Has thanked: 243 times
- Been thanked: 965 times
Re: Feature Requests Thread
by uhlersoth » 22 Mar 2013, 02:11
I agree completely regarding your "integrate in one go" comment - not gonna happen. But that's actually why I'm hoping to use this dev model - determine some hookpoint that leverages multiplayer, which can be opened up without any impact on the existing dev stream. The last thing I would want to do is have any of your current resources redirected toward a side project like this. Given a choice, I would much rather see Forge stay up to date with all the latest rules changes than to see multiplayer added.
But this feature request of mine follows this model. It opens a hookpoint for creating the lobby. I'll then be able to create a lobby in my own local code without impacting the existing dev stream.
I definitely want to put together a prototype first, which is really why I was reluctant to bring the multiplayer discussion up at all. What I realized, though, is that here in the very first steps of my prototype, trying to get my local friends to test it out with me will be painful without this feature. Without it, I'll have to extract the Forge code every time there's a new release, modify it with the changes I described above, build it, jar it up, and send it out to my local friends. But with this change, my local friends can continue to simply download Forge releases on their own, since the prototype I'm working on will just specify a different FControl in its own main() method.
That said. I want to simultaneously agree and disagree with your comments on the scope of the contribution. On one hand, I'm a professional Java developer of more than a decade. These days, I speak Java better than I speak English. But at the same time, my professional experience with Java makes me wary in approaching large, mature projects such as Forge, since it goes without saying it'll have a myriad of hidden quirks. I completely agree that adding multiplayer capability robustly is a project that should involve several experienced Forge developers, rather than a Forge noob such as myself. But putting together a prototype, or determining the feasibility to begin with, should be within my capabilities.
But this feature request of mine follows this model. It opens a hookpoint for creating the lobby. I'll then be able to create a lobby in my own local code without impacting the existing dev stream.
I definitely want to put together a prototype first, which is really why I was reluctant to bring the multiplayer discussion up at all. What I realized, though, is that here in the very first steps of my prototype, trying to get my local friends to test it out with me will be painful without this feature. Without it, I'll have to extract the Forge code every time there's a new release, modify it with the changes I described above, build it, jar it up, and send it out to my local friends. But with this change, my local friends can continue to simply download Forge releases on their own, since the prototype I'm working on will just specify a different FControl in its own main() method.
That said. I want to simultaneously agree and disagree with your comments on the scope of the contribution. On one hand, I'm a professional Java developer of more than a decade. These days, I speak Java better than I speak English. But at the same time, my professional experience with Java makes me wary in approaching large, mature projects such as Forge, since it goes without saying it'll have a myriad of hidden quirks. I completely agree that adding multiplayer capability robustly is a project that should involve several experienced Forge developers, rather than a Forge noob such as myself. But putting together a prototype, or determining the feasibility to begin with, should be within my capabilities.
Re: Feature Requests Thread
by Chris H. » 22 Mar 2013, 15:04
I think that we should continue the multi-human network mode discussion on the Developer's Corner forum.
I started a topic at Network Multiplayer (Multi-human players).
I started a topic at Network Multiplayer (Multi-human players).
-
Chris H. - Forge Moderator
- Posts: 6320
- Joined: 04 Nov 2008, 12:11
- Location: Mac OS X Yosemite
- Has thanked: 644 times
- Been thanked: 643 times
Re: Feature Requests Thread
by Max mtg » 22 Mar 2013, 15:16
Fully agreed with myk.
Yet, I'm more than happy to see that the destination I've been driving the changes towards attracts many fellows the closer the destination is
The changes you plan are too extensive, they should really concentrate on smaller portions to merge them frequently into main codebase. This way you'll work with an up-to-date revision of our fast-changing code.
Yet, I'm more than happy to see that the destination I've been driving the changes towards attracts many fellows the closer the destination is

The changes you plan are too extensive, they should really concentrate on smaller portions to merge them frequently into main codebase. This way you'll work with an up-to-date revision of our fast-changing code.
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Re: Feature Requests Thread
by uhlersoth » 22 Mar 2013, 16:51
Hmm.... I don't think I'm making myself clear here. My goal is to approach this as a gradual process, beginning with a prototype that does not involve any other Forge resources.
However. I'll drop the discussion and continue my efforts without this feature request. It will be more challenging, but not impossible, to create my prototype this way.
However. I'll drop the discussion and continue my efforts without this feature request. It will be more challenging, but not impossible, to create my prototype this way.
Re: Feature Requests Thread
by Slimmo » 25 Mar 2013, 03:17
Im not sure if this is the right thread or if the things I bring up is already pointed out but I will tell you my requests/feedback anyway.
1. When playing Planechase isn't it supposted to be FFA?, because all the AI players only attack/cast spells to target me and completly ignores the other AI players. They also never roll the planar dice.
2. If the above AI issue is resolved then perhaps you should add a regular FFA mode. Perhaps with some choices like attack rules (attack left/right).
3. Being able to choose if you want to be the Archenemy or not in Archenemy mode.
4. Add Two-Headed Giant game mode. Love this gametype so please add it
5. When playing with more than 2 players the UI tend to be confusing because you have to switch between tabs to see all of the player's fields. Could you atleast squeeze in 4 players per on one tab before having to switch between them or just limit so there is maximum 4 players per game then you dont have to bother about annoying tabs.
Thats all from me for now.. please consider what I have said
1. When playing Planechase isn't it supposted to be FFA?, because all the AI players only attack/cast spells to target me and completly ignores the other AI players. They also never roll the planar dice.
2. If the above AI issue is resolved then perhaps you should add a regular FFA mode. Perhaps with some choices like attack rules (attack left/right).
3. Being able to choose if you want to be the Archenemy or not in Archenemy mode.
4. Add Two-Headed Giant game mode. Love this gametype so please add it

5. When playing with more than 2 players the UI tend to be confusing because you have to switch between tabs to see all of the player's fields. Could you atleast squeeze in 4 players per on one tab before having to switch between them or just limit so there is maximum 4 players per game then you dont have to bother about annoying tabs.
Thats all from me for now.. please consider what I have said

Re: Feature Requests Thread
by Max mtg » 25 Mar 2013, 11:38
1. For over 4 years AI never expected that there would be more that two players in a game. They are still unaware of other players in most cases.Slimmo wrote:Im not sure if this is the right thread or if the things I bring up is already pointed out but I will tell you my requests/feedback anyway.
1. When playing Planechase isn't it supposted to be FFA?, because all the AI players only attack/cast spells to target me and completly ignores the other AI players. They also never roll the planar dice.
2. If the above AI issue is resolved then perhaps you should add a regular FFA mode. Perhaps with some choices like attack rules (attack left/right).
3. Being able to choose if you want to be the Archenemy or not in Archenemy mode.
4. Add Two-Headed Giant game mode. Love this gametype so please add it
5. When playing with more than 2 players the UI tend to be confusing because you have to switch between tabs to see all of the player's fields. Could you atleast squeeze in 4 players per on one tab before having to switch between them or just limit so there is maximum 4 players per game then you dont have to bother about annoying tabs.
Thats all from me for now.. please consider what I have said
2. Yes, this will be made as soon as AI gets at least a simpliest hate and love list.
3. It's because of AI... it never thinks of human as an ally.
4. Pretty the same reason here (besides the need to handle teams and their joined turns in code)
5. Try dragging the tabs to bring every player on top of the screen like this: viewtopic.php?f=52&t=8391 (note the attached picture)
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Re: Feature Requests Thread
by lazylockie » 25 Mar 2013, 14:30
also on 5, maybe a (long term) feature that allows forge to be played on more than one display? That way you could easily put 2 fields on one monitor and 2 other fields on another monitor.
a short term feature I would like is hotkeys to targeting myself or my opponent (clicking on the portrait)
a short term feature I would like is hotkeys to targeting myself or my opponent (clicking on the portrait)
- lazylockie
- Posts: 508
- Joined: 13 Jul 2010, 22:44
- Has thanked: 74 times
- Been thanked: 15 times
Re: Feature Requests Thread
by myk » 25 Mar 2013, 22:47
What would you suggest the default bindings for this to be (taking into account that there may be many opponents)? Perhaps 0 for self and other number keys for opponents? But how to make the mapping obvious when there are many?lazylockie wrote:a short term feature I would like is hotkeys to targeting myself or my opponent (clicking on the portrait)
- myk
- Posts: 439
- Joined: 17 Jan 2013, 02:39
- Location: California
- Has thanked: 38 times
- Been thanked: 57 times
Re: Feature Requests Thread
by lazylockie » 26 Mar 2013, 10:23
maybe as an additional hotkey, just like attack with all or toggle targeting options. then let the user just choose their own keys.myk wrote:What would you suggest the default bindings for this to be (taking into account that there may be many opponents)? Perhaps 0 for self and other number keys for opponents? But how to make the mapping obvious when there are many?lazylockie wrote:a short term feature I would like is hotkeys to targeting myselthe user or my opponent (clicking on the portrait)
- lazylockie
- Posts: 508
- Joined: 13 Jul 2010, 22:44
- Has thanked: 74 times
- Been thanked: 15 times
Re: Feature Requests Thread
by myk » 26 Mar 2013, 10:41
The issue still stands that no matter what keys you choose, in the current UI there is no way to tell which opponent maps to which key. If there were always one opponent, this wouldn't be so much of an issue, but an Archenemy game with 7 opponents isn't as clear cut. How would you feel about a number being prepended to the opponent name, e.g. instead of "Dawn Field" it was "1: Dawn Field", and that number being the hotkey to select that player? The same hotkey can also show the tabs for "1: Dawn Field" and "1: Dawn Command", with the field taking precedence if they both have the same tab parent.lazylockie wrote:maybe as an additional hotkey, just like attack with all or toggle targeting options. then let the user just choose their own keys.myk wrote:What would you suggest the default bindings for this to be (taking into account that there may be many opponents)? Perhaps 0 for self and other number keys for opponents? But how to make the mapping obvious when there are many?lazylockie wrote:a short term feature I would like is hotkeys to targeting myselthe user or my opponent (clicking on the portrait)
- myk
- Posts: 439
- Joined: 17 Jan 2013, 02:39
- Location: California
- Has thanked: 38 times
- Been thanked: 57 times
Re: Feature Requests Thread
by Max mtg » 26 Mar 2013, 13:32
Display numbers next to player names, then use Fn keys to target them. F1 should always stand for 'self' as it is made in many MMOs 
Numbers may be assigned to entities on stack or creatures.
But please inplement that either in input_sync branch or after it is merged.

Numbers may be assigned to entities on stack or creatures.
But please inplement that either in input_sync branch or after it is merged.
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Re: Feature Requests Thread
by myk » 26 Mar 2013, 14:29
Don't worry -- I've got other items I'm working on right now; I wouldn't be able to get to this for a while anyway. I'll put it on the backlog for consideration later, though.
- myk
- Posts: 439
- Joined: 17 Jan 2013, 02:39
- Location: California
- Has thanked: 38 times
- Been thanked: 57 times
Re: Feature Requests Thread
by Choral » 26 Mar 2013, 23:15
Hello, here's a feature I'd like to see:
an option in the "Quest Options" to improve the rate of unlocking new sets. I started with 3 sets to be able to fight and get cards in the same flavor, but my goal is to unlock all sets, starting from one block. However, the rate at which sets get unlocked is unbelievably slow (at least, to my experience). I'm at 149/16 and I've unlocked maybe 5 or six sets. Taking into account that there are much, much more sets to unlock, I get quite discouraged in this approach (which seemed fun when I began).
An option in the quest settings could help here, I think.
an option in the "Quest Options" to improve the rate of unlocking new sets. I started with 3 sets to be able to fight and get cards in the same flavor, but my goal is to unlock all sets, starting from one block. However, the rate at which sets get unlocked is unbelievably slow (at least, to my experience). I'm at 149/16 and I've unlocked maybe 5 or six sets. Taking into account that there are much, much more sets to unlock, I get quite discouraged in this approach (which seemed fun when I began).
An option in the quest settings could help here, I think.
Who is online
Users browsing this forum: No registered users and 51 guests