An offer for MTG Strategic Layer development.

[Headrock]

Good day,

My name is Headrock, and I've been a long-time MTG fan since childhood. I've been playing MTG Forge for almost two years now, and have a great appreciation for its flexibility and its practical execution.

Over the past couple of months I have been spending a lot of time formulating an idea that I've had for a long time. It did not seem too likely to work with other versions of digital MTG that I had encountered in the past, but MTG Forge seems incredibly suited for it - given all the groundwork that's already been done on match play, interface, and the amazing moddability it as through external data (for cards, decks, matches, and obviously the quest system).

The idea I'm working on involves creating a strategy layer that is somewhat similar to MTG Shandalar, but operates more in line with turn-based strategy games. Instead of just walking around to find opponents to fight, cards to buy, and random encounters to loot cards from (which is basically what both Shandalar and the current MTG Forge Quest mode do), I've been thinking hard about how to make a game that models the MTG card gameplay as a functioning world. In essence, the player would have control of areas of the map, draw mana from said areas, acquire cards by capturing and upgrading territory, and then use all of these resources to field armies that would battle each other. The battles themselves would be handled as regular MTG Forge matches. The strategic layer basically provides the over-arching experience, similarly to how the Quest mode works today in MTG Forge, but far more involved and more interesting than that.

I am a game designer by trade, and have created several games in the past. My most successful games so far have been simple ones, Javascript browser games and a few simplified remakes of older games, though my primary experience comes from extensive work on the Jagged Alliance 2 v1.13 project (some of you might've heard of that). Unfortunately I am only an amateur programmer, and have little knowledge on how to properly code in Java. Unsurprisingly, Forge's Java code is utterly baffling to me. I've tried making sense of it, but have failed miserably so far. Though I'm very skilled with graphical design (sorry for the immodesty), I'm afraid I'm not a good enough coder to undertake this project myself. On the other hand, I've already put in a great deal of work designing the concept, gameplay, and some of the graphical elements, as well as some of the content that this strategic layer would presumably employ.

What I'm looking for is someone who finds the idea interesting, and has experience coding in Java as well as some familiarity with the MTG Forge code, to build a "groundwork" that can tie gameplay and interface algorithms into the Forge code. Once this is done, I might be able to code the gameplay in myself, or collaborate with said person to continue creating the strategic layer.

I will welcome any feedback on this issue. Even if you think that this is not a good idea at all, please let me know.

Thanks in advance.

[drdev]

First of all, thank you for contributing this idea. It sounds really awesome.

I'm currently starting up development on a new mobile GUI for Forge that will work on phones and tablets running Android (and eventually IOS and Windows mobile hopefully). It uses the libgdx library, which is built on OpenGL. From what you're describing, it sounds like you're best bet would be to build this game mode using that library as well as opposed to using Swing which isn't really designed for games with real-time animation or rendering lots of sprites. If you're a game developer, you'll probably find the framework I'm building up in forge-m-base more familiar than the Java Swing code in forge-gui.

Have you thought about whether you'd want this game mode to work on mobile devices vs. just desktop computers?

[Headrock]

To be honest, I don't really see much of a difference in creating games for PC and for Mobiles nowadays, so long as the game itself does not require constant use of a keyboard or a large number of fine mouse manipulations. On top of that, redesigning a turn-based game's interface to take less space on a mobile app is usually pretty easy (with the use of self-hiding menus, co-existing tabs, and so forth). In fact, if anything it's harder for me to figure out how an MTG match could play out on a mobile - since you need so much data on-screen at the same time. Of course, I personally have always developed for the PC (mainly since I'm a PC person and don't own a mobile anyway).

I'll have a look at that library you mentioned, though again my understanding of Java is... very limited, probably not enough to create something from scratch. Also, the strategic layer would have to be directly linked to MTG Forge in order to make use of its card, match, graphics and file handling.

[drdev]

The challenge of making a usable interface for playing Magic on a phone is why I took on this project. It's certainly not as easy as just shifting things around slightly on our Swing application, not to mention that Java Swing is not supported by Android. That's why I had to start a brand new GUI, just re-using the AI, Core, Game, and Net components of Forge that Max mtg and others have painstakingly broken off from the GUI code in recent months.

The main reason I asked is because I'm not currently designing my libgdx version to support game play at a desktop resolution, so if you want to leverage an existing Match screen and have it work on a desktop, you'd either need to build your game in Swing (which probably won't work well if I'm understanding your game's design), or I/you/somebody would need to make a version or configuration of the libgdx game I'm working on (or at least the Match screen part) that would look good on a desktop.

Almost makes me wonder if we should just aim to retire the Swing application eventually, and turn Forge into a Magic game portal written with libdgx, on top of which different game modes could be built, such as the one you're proposing. They'd all share the same Match screen, but the gameplay outside of matches would be different. And we could make it flexible enough to support building both desktop and mobile games.

[Headrock]

Lets just say that I could easily make my idea work in HTML5 with Javascript, if only I knew that I could hook it up into MTG Forge (or any other MTG match software for that matter), to give you an idea of the capabilities that would be required. As I said in my opening post, my #1 problem is that I find the Forge java code inaccessible (though it's likely mainly because I've never formally learned Java), so I'm looking for someone who would be able to build essentially what you suggested: a hookup into the MTG Forge's basic features.

[drdev]

It might be worth mentioning that libgdx supports HTML5. So it might be possible for you to build what you're thinking in HTML5 and hook into a Forge implementation on libgdx. You could always start building an HTML5 prototype so you have something to post screenshots from, and then either transition it to java or interface it with java depending on what's feasible. However, as I haven't looked into the HTML5 libgdx support at all really, I might suggest you check it out first before doing too much work.

That said, I had never programmed in java prior to starting development on Forge last summer, so don't be too discouraged if you've never used it before. Never too late to learn something new.

[Max mtg]

Lets just say that I could easily make my idea work in HTML5 with Javascript, if only I knew that I could hook it up into MTG Forge (or any other MTG match software for that matter), to give you an idea of the capabilities that would be required. As I said in my opening post, my #1 problem is that I find the Forge java code inaccessible (though it's likely mainly because I've never formally learned Java), so I'm looking for someone who would be able to build essentially what you suggested: a hookup into the MTG Forge's basic features.

We know what to do! A web-based Forge client.
Ever heard of websockets?

[Headrock]

Just to be clear, I wasn't saying that I WANT to program this in javascript, just that Javascript and HTML5 would provide everything I needed to make it work - so the "requirements" for said project are really pretty low, in terms of libraries. I'm pretty sure Forge already uses everything that would be needed to make it happen (not 100% sure, since again, I can't make heads or tails of the Forge code). Since it'll be a turn-based game, it's all about static graphics - so no need for animations even.

In any case that would be pretty funny, to hook up a browser game into Forge, but it sounds too silly .

[Headrock]

In order to get more interest in this project, I wrote up a basic outline document and made some mock-up "screenshots", but sadly the site won't let me link to them because I'm a new user. Is there a way to work around that problem, such as by uploading the pics directly to this site, or something to that effect?

[friarsol]

In order to get more interest in this project, I wrote up a basic outline document and made some mock-up "screenshots", but sadly the site won't let me link to them because I'm a new user. Is there a way to work around that problem, such as by uploading the pics directly to this site, or something to that effect?

I think after you have 5 posts you can. Try again.

[Headrock]

Thank you, you are correct.

I'll finish writing tomorrow night (it's turned out to be quite long) and post it then. Thanks again.

[moomarc]

Is there a way to work around that problem, such as by uploading the pics directly to this site, or something to that effect?

To upload attachments look below the Submit button when drafting your message. Theres a panel with 'Options' and 'upload attachment'. Click on the latter and upload. I'm not sure if there's a minimum post count requirement for that however.

[Headrock]

A document outlining the project can be found HERE. I'll still be happy to hear more offers for support in this thread, maybe keep the other for discussions on mechanisms and rules...