What are your thoughts...
by Melv May · in Torque Game Engine · 06/22/2004 (10:20 am) · 24 replies
Alright,
I've not got much time to answer this and I should've got this answered at the weekend so here goes...
As you may know, I'm hard at work on Torque Retro (seems to be a good a name as any) which is a 2D engine written such that it integrates within the stock TGE code with *minimal* effort. The next important note is that it's *really* simple to drive.
All the objects that I've created (and folks will probably create lots of others) use functions to configure them but can also be configured from datablocks. All the objects are ultimately based upon the NetObject but at the moment operate in their initial domain on the 'client'. As you know, there's no distinction when operating within the same process, especially as I'm not even starting a 'server'.
This leads me nicely onto my question ... how important do you think is having networking as a fundamental element to creating and driving this 2D engine. The reason I ask is not one of any technical challenge on my part but quite simply, complexity from the users point of view. How many people are struggling with the concept of the networking as a whole? If you're not interested in multiplayer but simply making games quickly and easily from a *really* basic mod-base then no networking is the best but with networking added, it *is* more complex, it cannot be avoided. The fragmentation due to the networking layer can be confusing to people.
What is the concensus? Would you rather be creating swish 2D games quickly without having to mess with networking or would networking be an essential element?
I'll give this 24hrs and then I'll decide whether to promote to use the NetObject properly and fill-in the relevant pack/unpack routines as well as the localised graphics loading etc.
Jeff mentioned that he thought networking was essential and it can always be done but I was considering delaying making it more complex for people to use for the moment to see how people get on.
A quick response would be appreciated.
- Melv.
I've not got much time to answer this and I should've got this answered at the weekend so here goes...
As you may know, I'm hard at work on Torque Retro (seems to be a good a name as any) which is a 2D engine written such that it integrates within the stock TGE code with *minimal* effort. The next important note is that it's *really* simple to drive.
All the objects that I've created (and folks will probably create lots of others) use functions to configure them but can also be configured from datablocks. All the objects are ultimately based upon the NetObject but at the moment operate in their initial domain on the 'client'. As you know, there's no distinction when operating within the same process, especially as I'm not even starting a 'server'.
This leads me nicely onto my question ... how important do you think is having networking as a fundamental element to creating and driving this 2D engine. The reason I ask is not one of any technical challenge on my part but quite simply, complexity from the users point of view. How many people are struggling with the concept of the networking as a whole? If you're not interested in multiplayer but simply making games quickly and easily from a *really* basic mod-base then no networking is the best but with networking added, it *is* more complex, it cannot be avoided. The fragmentation due to the networking layer can be confusing to people.
What is the concensus? Would you rather be creating swish 2D games quickly without having to mess with networking or would networking be an essential element?
I'll give this 24hrs and then I'll decide whether to promote to use the NetObject properly and fill-in the relevant pack/unpack routines as well as the localised graphics loading etc.
Jeff mentioned that he thought networking was essential and it can always be done but I was considering delaying making it more complex for people to use for the moment to see how people get on.
A quick response would be appreciated.
- Melv.
About the author
#2
06/22/2004 (10:49 am)
I would like networking in. 
#3
06/22/2004 (11:40 am)
I had planned to use this for a networked game right off the bat =)
#4
I've planned for networking already and there's hardly any work at all to get it running that was simple because of the way it's been designed but I want to be cautious and see what's expected.
- Melv.
06/22/2004 (11:42 am)
"Networking 3 : Non-Networking 0"I've planned for networking already and there's hardly any work at all to get it running that was simple because of the way it's been designed but I want to be cautious and see what's expected.
- Melv.
#5
If you havent played Link: legend of the 4 swords on GBA then you dont know how nice multiplay in a 2D game can be. Plus throwing your friends like rocks is always a hoot in itself. heh :)
John H
06/22/2004 (11:56 am)
Networking Yes:If you havent played Link: legend of the 4 swords on GBA then you dont know how nice multiplay in a 2D game can be. Plus throwing your friends like rocks is always a hoot in itself. heh :)
John H
#7
You mentioned having these objects being driven by local object parameters, instead of datablocks. Would this still be possible, plus the NetObject functionality? So it gives people a choice.
06/22/2004 (1:07 pm)
I want to say, Networking, but I've already started to get used to thinking in network terms when it comes to Torque.You mentioned having these objects being driven by local object parameters, instead of datablocks. Would this still be possible, plus the NetObject functionality? So it gives people a choice.
#8
That way, those that don't require the networking options can have a smaller executable.
06/22/2004 (1:17 pm)
I'm not sure how practical this would be, but couldn't you place the bulk of the network code in a separate file and have the compiler decide whether to link it in based based on a flag and/or if statement?That way, those that don't require the networking options can have a smaller executable.
#9
06/22/2004 (2:27 pm)
Networking: yes. Seems to me that as long as your code is "TGE native" and fully integrated into the whole, networking should be part of the concept. 
#10
-Jeff Tunnell GG
06/22/2004 (2:46 pm)
When Phil and I were talking about this issue, I strongly argued to keep networking in. There are probably a thousand 2D engines on the market, but few to none with networking. From a selfish GG standpoint, I would like to see people that use T2D learn a lot of the methodologies for moving up ti real Torque, i.e scripting, networking, etc.-Jeff Tunnell GG
#11
But, how hard would it be for those who need it to implement TNL?
06/22/2004 (3:02 pm)
I'm toying with a 2D game that would benefit from having networking.But, how hard would it be for those who need it to implement TNL?
#12
06/22/2004 (3:39 pm)
Definately networked. We live in a networked world that's not likely to get less connected. And playing by yourself is a dying art. Competing and chatting with others is becoming more and more popular all the time.
#13
06/22/2004 (3:50 pm)
Networking in! I would like to try a multi-player Atari-Go mod with this. No need for AI, if I can play my friends.
#14
I just thought the idea of running the TGE, placing a 2D engine scene window on the screen using the GUI editor and then simply start writing code to generate and control 2D objects was a neat and simple way to get people writing simple games. The script-mod to do this is *really* lightweight and easy to understand, especially without all the mission/server support. With networking, the programmer would have to still understand the server/client seperation as well as setup/mod the scripts appropriately. I know for lots of people here this isn't a problem but I suspected that lots of people here are not the people who want a much simplified mechanism to create simpler games.
My idea was to provide something where there are little to no dots to join.
I am here to obey and provide, networking it is then...
- Melv.
*EDIT*: The above sounded a little like a slam but that's wasn't my intention. I just wanted to make sure that I don't release an equally complex game API but in 2D!
06/22/2004 (11:44 pm)
I think the overwhelming consensus is for networking.I just thought the idea of running the TGE, placing a 2D engine scene window on the screen using the GUI editor and then simply start writing code to generate and control 2D objects was a neat and simple way to get people writing simple games. The script-mod to do this is *really* lightweight and easy to understand, especially without all the mission/server support. With networking, the programmer would have to still understand the server/client seperation as well as setup/mod the scripts appropriately. I know for lots of people here this isn't a problem but I suspected that lots of people here are not the people who want a much simplified mechanism to create simpler games.
My idea was to provide something where there are little to no dots to join.
I am here to obey and provide, networking it is then...
- Melv.
*EDIT*: The above sounded a little like a slam but that's wasn't my intention. I just wanted to make sure that I don't release an equally complex game API but in 2D!
#15
06/23/2004 (12:04 am)
So, if I can handle scripting fair enough, can I make a game? Or must I learn C++? :)
#16
Helllllpppp!!!.
@Eric: You can make a game only using scripts. Obviously you can only do this to the limits of the capabilities of the objects provided. I haven't got time to write every conceivable C++ object to support every type of genre but I wanted to keep even this stage simple e.g. without networking so that even with a basic understanding of C++, you should be able to write one. An object would be something that perhaps rendered something like an isometric background or perhaps something that rendered vector graphics etc. I'll try to provide as many of these things as I can but initially, I've focused on scrolling backgrounds (non-tiled), static/animated objects using IFLs, collision detection, basic physics, particles, 2D mounting (both rigid and spring mounted for trailed objects), layered rendering and some other stuff. The list of objects can be extended infinitely to support things like tiled backgrounds but those obviously need a simple editor to generate their source-data. I want to create a solid framework first and then add cool fx-objects as I go along.
Without networking, these objects would be easier to create and control.
- Melv.
06/23/2004 (1:27 am)
Now Phil's gone and confused me again, but in a good way.Helllllpppp!!!.
@Eric: You can make a game only using scripts. Obviously you can only do this to the limits of the capabilities of the objects provided. I haven't got time to write every conceivable C++ object to support every type of genre but I wanted to keep even this stage simple e.g. without networking so that even with a basic understanding of C++, you should be able to write one. An object would be something that perhaps rendered something like an isometric background or perhaps something that rendered vector graphics etc. I'll try to provide as many of these things as I can but initially, I've focused on scrolling backgrounds (non-tiled), static/animated objects using IFLs, collision detection, basic physics, particles, 2D mounting (both rigid and spring mounted for trailed objects), layered rendering and some other stuff. The list of objects can be extended infinitely to support things like tiled backgrounds but those obviously need a simple editor to generate their source-data. I want to create a solid framework first and then add cool fx-objects as I go along.
Without networking, these objects would be easier to create and control.
- Melv.
#17
Yeah, it's a shame you can't drop it in like a plug-in or something. :)
BTW, is there anything art-wise you could use some help on?
06/23/2004 (1:52 am)
Is networking something you need to take into account while writing this? Or does it take as much effort to put it in now as it would in the future?Yeah, it's a shame you can't drop it in like a plug-in or something. :)
BTW, is there anything art-wise you could use some help on?
#18
The big difference comes from the way objects are internally configured, when texture resources are loaded and how the collision/prediction works. If networking was added at a later date then existing objects would have to be reconfigured in the way they handle their data.
The big concern are the complexities involved with collision detection/prediction across the network. This simply makes the objects more complex when developing them. The scripts aren't affected, it's just that the programmer will need to understand how to drive the server/client functionality.
- Melv.
06/23/2004 (3:33 am)
@Eric: I've already got networking in mind. By this I mean that the objects are based upon the SimObject and I've messed with switching them to use NetObject with the addition of using the pack/unpack routines and everything is fine. I've also adopted, from a configuration standpoint, the ability to configure the objects in any/all of three ways, one, using it's fields when created, two, using member functions and three, using datablocks as references to preset parameters. Because I've given the objects the ability to use the datablock system, it's easy to allow the objects to work more efficiently across the network.The big difference comes from the way objects are internally configured, when texture resources are loaded and how the collision/prediction works. If networking was added at a later date then existing objects would have to be reconfigured in the way they handle their data.
The big concern are the complexities involved with collision detection/prediction across the network. This simply makes the objects more complex when developing them. The scripts aren't affected, it's just that the programmer will need to understand how to drive the server/client functionality.
- Melv.
#19
"I came across the same thing Melv. For my purposes (teaching 2D games design and simple scripting), it really SHOULDNT have networking."
Well, that's a valid concern for Phil, but I don't see the logic in it. (No offense intended Phil.) Using Torque Retro doesn't automatically require one to access it's networkable features, right? That would be up to the designer. So teaching its simpler 2D non-networkable aspects remains the same. Phil simply leaves out the networking...
On the other hand, in my experience, advanced users will always zero in on what the engine "doesn't" have and I think having networking would fit in the "advanced" category. As Gonzo points out, it's becoming a very networked world.
So, it might as well be there for them if they need it.
Just my $0.02... 8^)
06/23/2004 (5:30 am)
@Melv; Is this the one?"I came across the same thing Melv. For my purposes (teaching 2D games design and simple scripting), it really SHOULDNT have networking."
Well, that's a valid concern for Phil, but I don't see the logic in it. (No offense intended Phil.) Using Torque Retro doesn't automatically require one to access it's networkable features, right? That would be up to the designer. So teaching its simpler 2D non-networkable aspects remains the same. Phil simply leaves out the networking...
On the other hand, in my experience, advanced users will always zero in on what the engine "doesn't" have and I think having networking would fit in the "advanced" category. As Gonzo points out, it's becoming a very networked world.
So, it might as well be there for them if they need it.
Just my $0.02... 8^)
#20
It would also be great if people took up the gauntlet and started generating cool objects that supported all sorts of 2D wizardry. :)
- Melv.
06/23/2004 (9:00 am)
@Jeff: I think the big thing to remember here is that networking will come. It's just that I really wanted to know if it would be a show-stopper if it wasn't in on the initial release. I didn't want to work hard on something that people wouldn't use. I can definately see that networking is a *must*, both in terms of it being a stepping-stone to bigger things like the full 3D TGE itself and to make it useful in your "very networked world".It would also be great if people took up the gauntlet and started generating cool objects that supported all sorts of 2D wizardry. :)
- Melv.
Torque Owner Ben Woodhead
I would like to see the networking in. I think this would be important.
Ben