Torque 2D Future Plans

#1 Feature requests: Opus audio format support and Android Wifi peer-to-peer networking (either integrated into the existing networking or exposed to TS).

#2 I think 3.0 is significant. It shows that the community cares and that we can undertake bigger projects.

I think that we definitely need better ways to organize. It has been said before but the engine's web presence is spread thin. GG forums, Trello, G+, github...

I think a community project game would be a nice thing to try.

#3 I've been here since T2D MIT was announced (on and off) and I'll give you my impression of a few things that probably should be taken care of:

1- I feel like even in the development branch of the engine things were sometimes left broken for too long. I finally tried to compile for Android a couple weeks ago, and honestly if it weren't for practicing01 helping out I could never have managed it. This was due to errors in the script that had been found and reported months beforehand, but were not fixed. I haven't checked the release version to confirm that it's all correct now. Similarly, smaller issues like the CollisionGroups code were left untouched for over a year, and to my knowledge still haven't been fixed, despite a couple bug reports.

2- It's time we got some solid looking editors, similar to how the Sandbox is set up (a collection of modules accessed from a menu). The old T2D still wins in this instance. I know it's a community thing, but someone really needs to be on this (I am not talented enough/don't have enough time to volunteer to do anything but test).

3- The Documentation since 2.0's release has improved greatly, but I think needs updates sometimes.

4- The big one: By 4.0 let's see some solid multiplayer support on all platforms.

That would be my thoughts at the moment. Now I'm going back to working on my little game ;)

#4 I agree with all of Chase's points, except I put editors at priority #1.

#5 Good stuff so far. Keep it coming. I'd like to dive deeper into your points Chase.

1. What do you think was the root cause of this? Are there any logistics that can be added/improved/removed to speed up bug fix frequency?

2. I do think editors are the next big thing, most needed out of everything. More on this later.

3. Agreed here. I pose the same questions I asked for #1.

4. Real-time? Turn-based? With physics? Without physics? What plan of attack should we all take?

@Chase and Shaolin Dave - Editors are a big endeavor, but sorely needed at this point. They would be useful to everyone and help pull in more beginners, designers, and artists. What's missing is a plan. If the community were to work on editors, we'll need another thread/blog to discuss how it would work.

This may be moot since I'm working on editors, but then everyone will be waiting on me. If it takes me all year to do them, would anyone stick around and wait on them? Is there a faster, collaborative way?

#6

Quote:Is there a faster, collaborative way?

Sure - make a branch and let some of us pitch in where we can!

I was a big fan of the 3SS tool views (I see that persisted in a distilled version in the Sandbox) - though maybe not as whole tab pages. Using that idea and making the import/edit tools GuiWindows instead of just preempting the whole window....

Some design docs for a guide and we're off to the races!

Added bonus - everyone gets to see first-hand how difficult, time-consuming, and complex editor-building is.

#7 Editors are definitely a hot ticket item, and will likely boost the usage of more people who aren't as code savvy as others. Having used TGB for quite some time, I have enough foundation to build just about anything, but newer users have to fuddle through.
As Richard said a design doc outlaying a plan for editors would likely give those of us who can the ability to start helping with a more clear direction.
More tutorials would also likely benefit the community. Some key ones that come to mind would be the "shooter" spaceship game that was made as a tutorial series, but not converted fully yet. Platformer tutorial would be good as well, and converting the Adventure Kit would be another big one.
I'm sure there are more ideas that could help boost things, but the more ability to replicate and replace, would be more ideal for the casual minded designer.

#8 Two things I should mention about my own editor work:

1. I'm going at it alone. I'll be open to feedback, but I want the project to be a solo endeavor for a few reasons.

2. Since I have experience with the tech and the process of creating editors, I'll be tackling my own work without any preproduction docs. I know what I want and there's already progress that I don't want to slow down.

That being said, I think any community-based editor work SHOULD have some preproduction. A plan, design doc, and maybe even a tech doc will make it easier for contributors to slide in and out of the project.

#9 I'm a huge fan of adding more tutorials at this point. My one hesitation, Doc, is that the particular ones you mentioned could be full blown genre kits. The good news is that we have all the art already available, which dramatically cuts down on time to create the projects and document them.

However, the adventure kit and a platformer project will take quite a bit of coding and documenting. The decision of how much to provide up from would make or break the work. Writing every line and asset file from scratch for those kinds of projects would take a lot of time if not scoped properly.

The shooter one would probably be the fastest, since we already have a tutorial, code, and art. It just needs to be updated for T2D MIT.

#10 I'm guessing when most people say they want an editor they mean a toolset that's included in the Torque 2D repo along with the engine, with the same MIT license, to which anyone can contribute to, provided a committee member approves the pull request. If people have different assumptions then we should clarify that now.

Mich, do you want any of part of your editor suite to end up in the official repo or will it strictly be a 3rd party tool?

#11 For the time being, I will be utilizing my own repo. Anything that goes in my fork will be freely available to anyone, including the steering committee. If anyone wants to copy my free, basic editors into another repo (like the official T2D MIT), that will be acceptable. If I need to make engine changes, I will submit pull requests to the main repo. It goes without saying that if I'm on the steering committee, I would assist with any porting or copying of the basic editors if that decision is made.

My decision to work in my own fork is a personal choice. I want to work unhindered. No red tape, no time consuming design cycles, no delays, no waiting on pull requests, etc. I will be completely open to feedback, but not I already have my plans in motion, so not everything would get addressed.

Now, I will also work on advanced editors that will have a price tag. I haven't decided on the cost, licensing, full feature set, or timing. That work will obviously happen in a private repository and only be available to paying folks.

#12 Basic Editors Fork

All work in that fork is considered highly unstable and nowhere close to completion. I need to cleanup the EditorShell module, add to the PluginSystem module, then I can start restoring the basic editors I created previously.

#13 I am a oldy programmer,

Back to the day of apple soft, Pascal and basic C on the PC. I have continued to learn more languages C#, C++, XNA, and many many others. Torque script 3d/2d along with python being the newest

I am told I need to invest in t2d 1.8 because legal reasons and the toolset/editor you speak of. I have t3d professional which has a toolset etc, that is nice I must admit. Keeping to your style that you have in both t2d and t3d I think is good idea. Not sure how hard that is.

The big issue I have is Documentation, some are blocked out due to weather you have purchased kit, others are out of date if you don't have t2d 1.8 etc.

Then when you do a search on the forums... rather then taking you to the thread that it has suggested what you might have searched it takes you back to the beginning of the forums. Maybe fix the search on the forums so it can direct you to others ideas and help. I have spent hours on them... to find a little info on newest stuff, or found info on older info which has still helped a little to understand torque script.

A LEXICON in form of a help file or anything would be great. Teaching structuring of mods and mains etc. A little giving snippet of code to show how it works. If ya need a reference down load the NWN1 Lexicon they did great work in teaching people ( who have never programmed ) how to code Never Winter Nights. The community is very helpful and encouraging, each of us giving help or code, even generous amounts of code. Resulting in many wonderful servers to play on, and wonderous neat ways to do things.

If you look at my T2DMit_Adventure_RPG_Toy repo you can see how mixed up I have gotten trying to figure stuff out. If I had never programmed I would be heavily discouraged. I am frustrated but that is programming, I would ENCOURAGE DETAILED Documentation.

I LOVE Torques flexibility, what you have done with both t3d and t2d. I really want to use it well, and help others use it well.

#14 Concerning multiplayer: besides that it won't work with physics enabled, I think most dedicated servers that you can rent don't come with opengl. So a T2D linux dedicated server with opengl-dependence removed would be needed (correct me if I'm wrong).

#15 Feature Request: CompositeSprite element moveTo(). This way you can make an entire world within a CompositeSprite, free of Box2D physics. Edit: On second thought, it wouldn't be a good idea to call thousands of TS onMoveToComplete()'s.

Edit: Better request: Assimp 3d model library integration. Nothing fancy, maybe an object derived from SceneObject with the regular physics except it renders a model instead of an image. Even better if you could mount objects such as weapons and clothes to the model.

#16 I've been here since the early adopter days of T2D and I'm still using 1.8 but I plan to upgrade at some point this year. The only editor I really need is the particle effect editor. It is more or less impossible to make a particle effect without the editor.

I would also like to see built in support for an automatic updater. I suggest winsparkle (Sparkle for Mac). It seems like it would be an easy win for the engine and I'm sure there's a lot of developers who could use it.

Finally, a better TCP object would be awesome. There's no support for HTTPS or post (as far as I know). It could certainly use some love.

#17 @Peter - Good suggestions. I disagree with you on it being impossible to make particle effects without an editor. All the effects in the Sandbox demo were made by hand. The new format is far easier to work with than the legacy TGB particle system. Regardless, have you read Simon's blog about his particle editor?

The auto-updater suggestion is interesting. I think a lot of games benefit from the feature. The one problem I see is that it could be very game specific, which makes a generic solution for T2D difficult. GG implemented a custom solution for 3 Step Studio (predecessor to T2D MIT) using Qt. While the Qt code was not released, a great byproduct that came out of it is the module system. The module and asset systems are primed for an auto-updater. Do you have any suggestions on a generic implementation?

Can you provide some use cases for a better TCP object?

#18 Edit : All written before Mich answered of course :)

@Peter : Not to toot my own horn but the Particle Effects Editor will be at ready by the end of the week => Check it out here

#19 Great news about the particle editor. I don't stay up to speed enough and I was talking about the old particle effects. So with that in place I can safely say that I don't care about the rest of the editors but I think I'm in the minority.

I'll probably be working WinSparkle into my current game. It seems very generic. To use it just involves making sure the compiler can find the lib and then adding two init lines and one closing line of code. From there you could just create a config setting to set the RSS 2.0 feed that it's supposed to point at (basically an update url). You'd have to leave developers to figure out how to do the RSS feeds (called appcasts) but at least people could use it without having to compile. You can find out more on git hub.

Using the TCPObject and a PHP web server I just built the online version of my game. The entire thing works by sending simple GET commands to the server. It works because it's a turn based game, but it would have been nice to use HTTPS because then I could actually have players login using a password. As it is now a player's online account could technically be hijacked. HTTPS would have avoided that. Also I am limited on how much info I can send to the server at any one time because it's all going in the address of a normal web GET request. If I could send a POST request I could send as much info as I wanted in the body of the request. I got around these requirements now but someday I'd like players to make custom maps and upload them and since that's a lot of data to send I'll probably have to send it in several GET requests instead of one large POST request.

And if you're wondering why I didn't just user the normal networking stuff, it's because I didn't have a dedicated server - just a web server. All part of working on a shoestring budget. :)

#20 You should be able to send a post request, in Marble Blast Platinum which is a mod of marble blast gold using a version of TGE from 2002 they were able to use script post requests. I'm sure the networking didn't just auto remove it from the engine.

They built their own post method in script to help simplify the process, using the TCPObject::send() binded method