GarageGames Update
by Dexter Chow · 07/19/2011 (5:07 pm) · 77 comments
We get a lot of questions about what we are doing and when things are happening. As you may know, we weigh giving early information out that may not be final (or may change) with guidance on what we are planning. Here is an update that will give helpful information for some of the community questions.
GarageGames is always looking for ways to stay connected to our community. Therefore, the idea of bringing back a GarageGames newsletter makes a lot of sense. Our summer newsletter is here and registered GarageGames customers will see it delivered to their email address by the end of the month. It is called the GarageGames Gazette. We highlight our sale specials, community happenings, our staff and what we have been doing this year. We also catch up with a successful Torque developer for an interview to learn about their development process. If you registered with us and we missed you, our apologies. To be added to our newsletter email list, just send an email to newsletter@garagegames.com with your email address and a note that you would like to be added to the list. Also, you can tell us what you think about our newsletter and even suggest new stories for our upcoming newsletters.
With our new art team, we want to provide professional quality art Torque 3D users can use to enhance their game or show off their code (it always helps to have great art to go with programming). Our first art pack, GarageGames Soldier Pack features 8 skins to put your soldier in jungle, tropical or even arctic environments. It is available now for $19.99. Our second art pack, GarageGames Vehicle Pack, gives the Cheetah from Torque 3D 1.1 radically different looks. It will be available this week for $19.99.
On the hiring front, I’m glad to announce we have three more programmers joining us in sunny Las Vegas. Kyle Miller has been with us a week. He comes from the simulation industry with extensive knowledge of several areas of programming. We did note that he has used Torque 3D extensively in his past job. Dennis Booth is a veteran developer with 10 years at Rainbow Studios/THQ and several software startups. Finally, Masaki Oyata joins us from teaching programming in the classroom to programming in our QA analyst position. Welcome.
On sales promotions, our $99 promotion on Torque products will be ending soon. We haven't locked down a date yet, but it is a limited time promotion. I'd also like to note Torsion and pureLIGHT are also limited time sales. Grab them while they are on sale. Keep your eyes open for Torque 2D. There's going to be a sale on two products later on in the week.
What about Torque products? Here are some in progress updates:
Torque 3D 1.2 - Bug fixes and more upgraded docs with extensive tutorials are in the works.
iTorque 1.5 - We're still trying to hire an iOS programmer; so we are looking at our options as far as features and release date. Progress is definitely being made on development. Improved multi-touch, Gyro and Accelerometer support are featured next in iTorque 2D Preview #2. We expect this to be available next week.
I hope you're staying cool this summer. Questions?
GarageGames is always looking for ways to stay connected to our community. Therefore, the idea of bringing back a GarageGames newsletter makes a lot of sense. Our summer newsletter is here and registered GarageGames customers will see it delivered to their email address by the end of the month. It is called the GarageGames Gazette. We highlight our sale specials, community happenings, our staff and what we have been doing this year. We also catch up with a successful Torque developer for an interview to learn about their development process. If you registered with us and we missed you, our apologies. To be added to our newsletter email list, just send an email to newsletter@garagegames.com with your email address and a note that you would like to be added to the list. Also, you can tell us what you think about our newsletter and even suggest new stories for our upcoming newsletters.
With our new art team, we want to provide professional quality art Torque 3D users can use to enhance their game or show off their code (it always helps to have great art to go with programming). Our first art pack, GarageGames Soldier Pack features 8 skins to put your soldier in jungle, tropical or even arctic environments. It is available now for $19.99. Our second art pack, GarageGames Vehicle Pack, gives the Cheetah from Torque 3D 1.1 radically different looks. It will be available this week for $19.99.
On the hiring front, I’m glad to announce we have three more programmers joining us in sunny Las Vegas. Kyle Miller has been with us a week. He comes from the simulation industry with extensive knowledge of several areas of programming. We did note that he has used Torque 3D extensively in his past job. Dennis Booth is a veteran developer with 10 years at Rainbow Studios/THQ and several software startups. Finally, Masaki Oyata joins us from teaching programming in the classroom to programming in our QA analyst position. Welcome.
On sales promotions, our $99 promotion on Torque products will be ending soon. We haven't locked down a date yet, but it is a limited time promotion. I'd also like to note Torsion and pureLIGHT are also limited time sales. Grab them while they are on sale. Keep your eyes open for Torque 2D. There's going to be a sale on two products later on in the week.
What about Torque products? Here are some in progress updates:
Torque 3D 1.2 - Bug fixes and more upgraded docs with extensive tutorials are in the works.
iTorque 1.5 - We're still trying to hire an iOS programmer; so we are looking at our options as far as features and release date. Progress is definitely being made on development. Improved multi-touch, Gyro and Accelerometer support are featured next in iTorque 2D Preview #2. We expect this to be available next week.
I hope you're staying cool this summer. Questions?
About the author
Designer, Producer and Business Development Manager
#62
Bottom line is, the communication with the community has to improve, because currently we are in surprise mode: a couple of months of silence, and suddenly, "look folks, this is all we did". The obvious answer will be, "Hey, pretty good"... but also would be more professionally useful to know the roadmap of the framework in a more periodic and serious fashion.
And lets be honest, the current argument ("we dont wanna tell because we want to be free") is becoming a bit adolescent, and has to be revisited.
The current approach -at least for me- is starting to work the opposite way. If you dont want to talk, because apparently always "things could change" means that you plainly can't commit to an objective. *Always* with chances to change, isn't any well known software development practice.
As always, please don't get my words too harshly. I love this community, and really like GG, but also like to be direct.
08/11/2011 (1:54 pm)
I agree in general terms with Charlie.Bottom line is, the communication with the community has to improve, because currently we are in surprise mode: a couple of months of silence, and suddenly, "look folks, this is all we did". The obvious answer will be, "Hey, pretty good"... but also would be more professionally useful to know the roadmap of the framework in a more periodic and serious fashion.
And lets be honest, the current argument ("we dont wanna tell because we want to be free") is becoming a bit adolescent, and has to be revisited.
The current approach -at least for me- is starting to work the opposite way. If you dont want to talk, because apparently always "things could change" means that you plainly can't commit to an objective. *Always* with chances to change, isn't any well known software development practice.
As always, please don't get my words too harshly. I love this community, and really like GG, but also like to be direct.
#63
Let me shed some light quickly here in this blog:
-On the Torque 3D side, Derek is going to start doing weekly-ish blogs regarding 1.2 as soon as next week.
-iTorque is doing previews as you suggest. We would like to continue this process into the future. It's been positive.
-Torque 2D will be getting an update after iTorque. We will be moving many of the iTorque fixes into Torque 2D.
"Meanwhile, I for one, am strong enough to handle changes of plans. If I knew that 4 or 5 sprints from now there were plans for X, and Y or Z, and then it didn't pan out, I could handle it!"
It would be a lot easier if everyone had that opinion. But in our past, there were many, many, people who couldn't.
I've always suggested that estimates in the future should be accompanied with a confidence number. So maybe if we posted Feature X Confidence 60%, we could share more without being held to the flames.
08/11/2011 (3:05 pm)
Some of this communication is happening...some of it...as you suggest is not.Let me shed some light quickly here in this blog:
-On the Torque 3D side, Derek is going to start doing weekly-ish blogs regarding 1.2 as soon as next week.
-iTorque is doing previews as you suggest. We would like to continue this process into the future. It's been positive.
-Torque 2D will be getting an update after iTorque. We will be moving many of the iTorque fixes into Torque 2D.
"Meanwhile, I for one, am strong enough to handle changes of plans. If I knew that 4 or 5 sprints from now there were plans for X, and Y or Z, and then it didn't pan out, I could handle it!"
It would be a lot easier if everyone had that opinion. But in our past, there were many, many, people who couldn't.
I've always suggested that estimates in the future should be accompanied with a confidence number. So maybe if we posted Feature X Confidence 60%, we could share more without being held to the flames.
#64
Eric, you guys are constantly determining what features go with that level of determination? Is this for all features? There is something there I dont quite follow.
08/11/2011 (3:12 pm)
OR maybe the problem is that you cant develop software with feature confidence of %60... are you kidding?Eric, you guys are constantly determining what features go with that level of determination? Is this for all features? There is something there I dont quite follow.
#65
i.e. Wetness shader - We thought we were going to have it for release. After it was developed, we determined that it wasn't a practical implementation for the majority of games.
It was a research-like feature that didn't go well.
Other features are much easier to forecast. Managing risk is a huge part of developing code that is a platform for others to use.
08/11/2011 (3:16 pm)
@Novack - Some things are harder to add some things are easy. Sometimes, it's a bit of a research project.i.e. Wetness shader - We thought we were going to have it for release. After it was developed, we determined that it wasn't a practical implementation for the majority of games.
It was a research-like feature that didn't go well.
Other features are much easier to forecast. Managing risk is a huge part of developing code that is a platform for others to use.
#66
However sounds like the development of the engine is an ocean of uncertainty. You guys dont have features that know for sure that want to be on the framework, beyond the difficulty?
I mean, something like a meeting, where you decide what you want, and work in that direction. Thats development, not just features that you investigate for a period of time lokking for the feasible ones.
08/11/2011 (3:21 pm)
Yeah, I got that, its true. Also the Wetness shader case was something that went wrong because was probably super hyped.However sounds like the development of the engine is an ocean of uncertainty. You guys dont have features that know for sure that want to be on the framework, beyond the difficulty?
I mean, something like a meeting, where you decide what you want, and work in that direction. Thats development, not just features that you investigate for a period of time lokking for the feasible ones.
#67
The question was rethoric, I know you guys have that direction.
What we ask is for you to share that direction with us. There is a point where the sum of individual features denotes the direction of the engine development.
Some of that features may change, or fall, but never all, because thats the idea of direction.
We want to know the direction of the engine.
08/11/2011 (3:34 pm)
For the sake of getting to common soil:The question was rethoric, I know you guys have that direction.
What we ask is for you to share that direction with us. There is a point where the sum of individual features denotes the direction of the engine development.
Some of that features may change, or fall, but never all, because thats the idea of direction.
We want to know the direction of the engine.
#68
Listen, I'm not saying you are wrong. You are right.
But it is very complex and some of the reasons it's complex are things I can't share for various reasons.
I promise this...we will get to the point where we can be much more transparent. We will get to the point where releases are incredibly more frequent. When? Maybe in six months or so (80% confidence).
08/11/2011 (3:42 pm)
Yes, you are cutting to the hart of the challenge for us. The direction of our engines is rooted in a lot of research and some herculean efforts by very talented people. We are sharing that research with associates under NDA right now.Listen, I'm not saying you are wrong. You are right.
But it is very complex and some of the reasons it's complex are things I can't share for various reasons.
I promise this...we will get to the point where we can be much more transparent. We will get to the point where releases are incredibly more frequent. When? Maybe in six months or so (80% confidence).
#69
Thanks. But while you are successfully placating those that can't handle the truth, you are leaving the rest of us out! Aw, the Sword of Damacles, or something.
I can't speak for your situation at GG, but I've worked at places where the leaders became paralyzed from the vocal minority. Meanwhile you've got relatively silent people like myself who don't get what they want, like a list of cool features and fixes to look forward to and feel the momentum. Perhaps I'm in a bigger group than is obvious?
That sounds like a good thing to try. I'd suggest that each milestone list be populated with a handful of 96% and one 60%. All research and no definite progress makes customer's antsy!
08/11/2011 (5:15 pm)
@Eric, Hi. Thanks for replying.Quote:
"Meanwhile, I for one, am strong enough to handle changes of plans. If I knew that 4 or 5 sprints from now there were plans for X, and Y or Z, and then it didn't pan out, I could handle it!"
It would be a lot easier if everyone had that opinion. But in our past, there were many, many, people who couldn't.
Thanks. But while you are successfully placating those that can't handle the truth, you are leaving the rest of us out! Aw, the Sword of Damacles, or something.
I can't speak for your situation at GG, but I've worked at places where the leaders became paralyzed from the vocal minority. Meanwhile you've got relatively silent people like myself who don't get what they want, like a list of cool features and fixes to look forward to and feel the momentum. Perhaps I'm in a bigger group than is obvious?
Quote:
I've always suggested that estimates in the future should be accompanied with a confidence number. So maybe if we posted Feature X Confidence 60%, we could share more without being held to the flames.
That sounds like a good thing to try. I'd suggest that each milestone list be populated with a handful of 96% and one 60%. All research and no definite progress makes customer's antsy!
#70
I appreciate your way of doing and expresing things here.
From all the people that has passed by GG, through all the years and promises, I think you are the person I believe thats actually doing what he says. So if you say so, I believe you. Thanks for being here replying, btw.
Edit: I agree with Charlie again, specially on the point of the vocal minority.
08/11/2011 (8:27 pm)
@Eric, lol, badass confidence on that one!I appreciate your way of doing and expresing things here.
From all the people that has passed by GG, through all the years and promises, I think you are the person I believe thats actually doing what he says. So if you say so, I believe you. Thanks for being here replying, btw.
Edit: I agree with Charlie again, specially on the point of the vocal minority.
#71
Around here is feels a bit like we are a rebuilding sports team recovering from a few bad years. To rebuild, you need to take one step back to take two steps forward. We've taken many of those steps back in many ways and there are probably still a few steps back that we need to take.
Going into this year, we knew that our biggest challenge would be hiring. We've had some bumps along the way, but we are building a great team. An ex-TD from THQ started here at the beginning of the month and he commented on how cohesive the team is. That's something I'm particularly proud of. We said in the beginning that we wouldn't compromise on "fit" of any of our hires. I've personally gone over our team values with all our employees ( actually, I'm behind on one right now ).
There is a lot more work going on behind the scenes then you will notice on the surface...at least for the next six months. And while I agree that work behind the scenes makes people nervous I can promise this: our foreseeable plans are to cater to the masses ( we will not release a product with a price that is not indie friendly ) and we will be a more transparent company through faster releases ( monthly is likely ) when the infrastructure is in place for us to really make that happen.
08/12/2011 (7:51 am)
@Novack - Thanks Novack. I really appreciate it. And yes, I agree with the vocal minority issue. We will never make everyone happy.Around here is feels a bit like we are a rebuilding sports team recovering from a few bad years. To rebuild, you need to take one step back to take two steps forward. We've taken many of those steps back in many ways and there are probably still a few steps back that we need to take.
Going into this year, we knew that our biggest challenge would be hiring. We've had some bumps along the way, but we are building a great team. An ex-TD from THQ started here at the beginning of the month and he commented on how cohesive the team is. That's something I'm particularly proud of. We said in the beginning that we wouldn't compromise on "fit" of any of our hires. I've personally gone over our team values with all our employees ( actually, I'm behind on one right now ).
There is a lot more work going on behind the scenes then you will notice on the surface...at least for the next six months. And while I agree that work behind the scenes makes people nervous I can promise this: our foreseeable plans are to cater to the masses ( we will not release a product with a price that is not indie friendly ) and we will be a more transparent company through faster releases ( monthly is likely ) when the infrastructure is in place for us to really make that happen.
#72
We'll have to pass the winter meditating, and working then :)
08/12/2011 (8:06 am)
Sounds like an oak going in through the winter to flourish with all its strenght on the spring. I like that. We'll have to pass the winter meditating, and working then :)
#73
@Eric, I hope you don't mind me asking a question about the future direction in this public forum?
I'm a few months into full-time work on my game, and I'm now hitting an "intermediate level" of feature issue. For instance, I'm having issues pausing games and saving games and especially with behaviors. Intermediate type stuff. My concern is that these areas of the platform are considered feature complete, but I'm running into fairly generic issues, IMO. Can you let me know if these areas are "done done," or if they are known to have a few feature gaps that will be filled as soon as reasonable?
It's fairly hard to divine this answer from the forums. Here is an example of an empty reply to such a concern. In the case of pause, the replies seem to be to do it yourself in scripting which seems unnecessarily onerous.
--------------------
A couple of examples to make the point:
1) Pausing and saving do not consider schedule()'s timers. They keep running during pause and they aren't saved during saveLevel(). This seems like a fairly low-level thing everyone could use. I guess I'm going to add it in C++.
2) Behaviors feel like an experiment that was incomplete. For one, when an instance sceneobject is saved to a file, the behavior's dynamic fields aren't included. The sceneobject is then crippled for loading. Seems fairly straightforward and now that I'm committed I guess I will add this in C++. For two, the behaviors themselves aren't read in with a "persisted" object. So no persist flag for me. Am I missing something? There are other examples of behavior cases, but I'll stop at that.
Thanks,
Charlie
08/12/2011 (10:46 am)
@Eric, I hope you don't mind me asking a question about the future direction in this public forum?
I'm a few months into full-time work on my game, and I'm now hitting an "intermediate level" of feature issue. For instance, I'm having issues pausing games and saving games and especially with behaviors. Intermediate type stuff. My concern is that these areas of the platform are considered feature complete, but I'm running into fairly generic issues, IMO. Can you let me know if these areas are "done done," or if they are known to have a few feature gaps that will be filled as soon as reasonable?
It's fairly hard to divine this answer from the forums. Here is an example of an empty reply to such a concern. In the case of pause, the replies seem to be to do it yourself in scripting which seems unnecessarily onerous.
--------------------
A couple of examples to make the point:
1) Pausing and saving do not consider schedule()'s timers. They keep running during pause and they aren't saved during saveLevel(). This seems like a fairly low-level thing everyone could use. I guess I'm going to add it in C++.
2) Behaviors feel like an experiment that was incomplete. For one, when an instance sceneobject is saved to a file, the behavior's dynamic fields aren't included. The sceneobject is then crippled for loading. Seems fairly straightforward and now that I'm committed I guess I will add this in C++. For two, the behaviors themselves aren't read in with a "persisted" object. So no persist flag for me. Am I missing something? There are other examples of behavior cases, but I'll stop at that.
Thanks,
Charlie
#74
08/12/2011 (12:53 pm)
@Charlie - I'm not intimately familiar with our bug/request log for T2D/iTorque 2D (I've spent way more time in T3D..but I'm also caught up with biz dev and other non tech things). We are working on bugs right now for the 1.5 release and many of those bugs will be ported over to T2D in the Sept time frame....let me ask Mich...sounds like the issue is not in our bug tracker...let me fix that first.
#75
Thanks. I wasn't aware of the lead on T2D stuff. Thanks for looping Mich in. Hi Mich?!
I want to be sure I'm not losing my point with individual examples.
As an engineer trying to really make it in games, I was progressing rapidly for the first few months, but now I seem to be running into issues as I add "intermediate" features like save and pause. I want to make sure that current "modules" will get more complete.
Any more info on this will help me decide to a) spend a month or so in C++, b) wait a month or so for features while continuing my specific game, or c) some other option I shudder to consider as I really like Torque and what it represents.
Sure I would like some newer features (box2d or shader effects or whatever) but I really need the current features to be feature complete in order to release a game quickly. I understand secrecy on experimental new ideas, but I need to know, one professional to the other, what is up with specific bugs or missing features in current modules.
Thanks again for your patient with me!
Charlie
08/12/2011 (1:15 pm)
@Eric,Thanks. I wasn't aware of the lead on T2D stuff. Thanks for looping Mich in. Hi Mich?!
I want to be sure I'm not losing my point with individual examples.
As an engineer trying to really make it in games, I was progressing rapidly for the first few months, but now I seem to be running into issues as I add "intermediate" features like save and pause. I want to make sure that current "modules" will get more complete.
Any more info on this will help me decide to a) spend a month or so in C++, b) wait a month or so for features while continuing my specific game, or c) some other option I shudder to consider as I really like Torque and what it represents.
Sure I would like some newer features (box2d or shader effects or whatever) but I really need the current features to be feature complete in order to release a game quickly. I understand secrecy on experimental new ideas, but I need to know, one professional to the other, what is up with specific bugs or missing features in current modules.
Thanks again for your patient with me!
Charlie
#76
isEventPending
getEventTimeLeft
getScheduleDuration
getTimeSinceStart
This can be handled in script and might be very game specific. The values you get from those functions can be used to save persistent data, then resume based on it. I'd be willing to post a forum thread with an example solution, but I can't guarantee this would be addressed with the next T2D release.
08/12/2011 (1:22 pm)
@Charlie - Howdy. I see what you are saying for the first two examples.Quote:1) Pausing and saving do not consider schedule()'s timers. They keep running during pause and they aren't saved during saveLevel(). This seems like a fairly low-level thing everyone could use. I guess I'm going to add it in C++.I have actually been thinking about this a lot lately. Scheduling is very powerful and I use it a lot in my side projects. My approach would be to create a list of custom script objects that contain all the information I need to halt and resume schedules. This would make use of almost every schedule related function:
isEventPending
getEventTimeLeft
getScheduleDuration
getTimeSinceStart
This can be handled in script and might be very game specific. The values you get from those functions can be used to save persistent data, then resume based on it. I'd be willing to post a forum thread with an example solution, but I can't guarantee this would be addressed with the next T2D release.
Quote:For one, when an instance sceneobject is saved to a file, the behavior's dynamic fields aren't included.Now that's strange, since the level editor manages to do this. I might even consider that a bug. Worth investigating further from our end.
#77
Oh, hi Mich'ael? :)
I have considered something similar but I have maybe 100 schedules to save manually! I don't think that count is unusually high since, for instance, every time a ship fires a salvo of 3 bullets separated by 250ms, I need at least two schedules for that ship: one for the gap between bullets, the other for time until next burst. I have many friendly and enemy units, and I have resources popping up on timers, AI releasing enemies on timers, etc.
Is there a better way?
For saving and pausing, it seems possible for the toolkit to store what objects have what schedules, and then load them back, and this seems very game-agnostic on first blush. I've thought about it a lot lately too. :)
If you mean that the level editor save the behavior with its template parameters, yes that works fine. (But not for persistent objects and maybe not for loading TGB levels into iT2d last time I checked.)
However, in game, each behavior will hold dynamic fields (%this.damage, for instance, not to be confused with %this.owner.damage). These "behavior dynamic fields" do not save.
Again, seems possible to do this in a game-agnostic way in the engine so that it doesn't have to be done per-game with scripts.
08/12/2011 (1:55 pm)
@MichaelOh, hi Mich'ael? :)
Quote:
I have actually been thinking about [schedules] a lot lately. Scheduling is very powerful and I use it a lot in my side projects. My approach would be to create a list of custom script objects that contain all the information I need to halt and resume schedules.
I have considered something similar but I have maybe 100 schedules to save manually! I don't think that count is unusually high since, for instance, every time a ship fires a salvo of 3 bullets separated by 250ms, I need at least two schedules for that ship: one for the gap between bullets, the other for time until next burst. I have many friendly and enemy units, and I have resources popping up on timers, AI releasing enemies on timers, etc.
Is there a better way?
For saving and pausing, it seems possible for the toolkit to store what objects have what schedules, and then load them back, and this seems very game-agnostic on first blush. I've thought about it a lot lately too. :)
Quote:
Quote:For one, when an instance sceneobject is saved to a file, the behavior's dynamic fields aren't included.
Now that's strange, since the level editor manages to do this. I might even consider that a bug. Worth investigating further from our end.
If you mean that the level editor save the behavior with its template parameters, yes that works fine. (But not for persistent objects and maybe not for loading TGB levels into iT2d last time I checked.)
However, in game, each behavior will hold dynamic fields (%this.damage, for instance, not to be confused with %this.owner.damage). These "behavior dynamic fields" do not save.
Again, seems possible to do this in a game-agnostic way in the engine so that it doesn't have to be done per-game with scripts.
Associate Charlie Patterson
Default Studio Name
Maybe one solution would be quicker, shorter tech releases. Some major bug fixes this month, a new type of scene object for box2d next month, a refactoring with no updates but please give it a test the next month, a re-factoring of box2d that was just released and that breaks compatability (hey we said it was a tech realease)...
And finally a release.
Meanwhile, I for one, am strong enough to handle changes of plans. If I knew that 4 or 5 sprints from now there were plans for X, and Y or Z, and then it didn't pan out, I could handle it!
I could probably even use a tech debate on here on the best route, though that may not be something practical in the game platform world. (I'm sure that for N user's there are O(N^2) opinions. :)