What have been your biggest challenges so far?

#61 Probably a good idea, Matt. You've been a madmen, producing tons of cool stuff lately. :) Good idea to take a much deserved break.

#62 ... take a well-earned break!

We'll still be here when you get back. :)

- Melv.

#63 Working this morning I realized a hurdle I'm going to have: re-writing the physics. Not that there is anything wrong with the physics engine in T2D, but the needs of the game are somewhat unique and would only form a small subset of T2D games so there would be no need to put this in the engine.

What are the issues? The game involves vehicles and, even in 2D, this is fairly complex to go beyond kart-style.

For example, center of rotation is either the front axle, rear axle or center of mass (depending on the situation, current conditions, etc). Without this certain things don't work right. A simple example is when ramming a car perpendicular to yourself (think, running a road block) the pivot point of the car being rammed would be the axle farthest from the point of impact. It is further complicated by the force application to break the nearest axle's tires' static friction increases with proximity to that axle.

Then there is tire slip, missing wheels, etc.

What I'm doing is gradually implementing what I need in TorqueScript, but ultimately I will need to do this in the engine. I like doing it this way because I get to see results during development and I suspect development is faster. And the core logic of the physics will be the same regardless.

#64

Quote:On the Getting Started Thread, a few of us found ourselves in a dicusssion about building a repository of standards-based code templates and bare-bones design documents that those of us who are able to contribute can and those who are having problems with T2D can retrieve from, either completely free of charge or for a small fee depending on the costs and the effort involved. It will in all likely-hood be free of charge , hopefully!:) I am currently talking such things over with GG. Hope things work out!:)

Any further ideas?

Not to intentionally toot my horn, but after doingn the fuirst few Hello World tutorials i've found that the simple layout I ended up making works very well. So well in fact that i've been using the base from Hello World #3 in the rewrite of TileIt. Its very simple, clean, and easy to work with :)

Take a look at Hello World #2 and see if you agree.

#65 @Tim: As long as you are aware that the features in T2D as it stands isn't the whole story, there's lots of stuff to come; arbitrary rotations being only a minor one. Also, static friction is already in the engine but currently disabled. It is also possible now to create a custom C++ object that has multiple physics-models e.g. it is an aggregation of these. You can deal with each of these physics models however you like.

What you're describing is a specialised vehicle-class (by the sound of it), not really something too high-level you'd want to construct from individual elements in script anyway.

Good luck, sounds like an interesting project. :)

- Melv.

#66 @Melv: yep, the game is a car-combat type and the will primarily involve arena combats (so I'm calling it Auto Arena ;^) Script development is quicker for me than in C++ so I'm making sure that the code logic is good before implementing in C++.

As I said, I would not expect T2D to provide this kind of functionality. Depending on how the final physics works maybe it would work out. The vehicle components are already just that: components, so if I can make the example car ramming work by mounting the tires appropriately that'd be great.

I started work without spec'ing because I'm having more fun this way, so I'm realizing complexities I hadn't considered. Currently working through why the car doesn't ever move (had to turn off engine damage and cap the engine rpm to keep it from blowing up the motor while I sort this out...)

Lots of fun, and a great way to spend a Sunday (though my wife would like more time with me ;^)

I had a working demo to prove missiles, etc., before I started working on the car components. When I get it back to a functional level I'd be happy to post a demo.

#67 Look forward to seeing some of that stuff Tim. Totally understand on the wife front. ;)

- Melv.

#68 @John: Your HelloWorld frameworks are perfect examples of what I am talking about. Forgot to mention those earlier, sorry John. The basic framework is there for anyone to expand upon; great stuff!:)

#69 I started dating this girl for awhile there. That does wonders for productivity of any sort.

My biggest "problems" are strictly workflow/time management issues.

I'm new to Torque/Torque2D and games programming in general. So I need to spend some time digging in and figuring it out.

I'm also new to creating art. I'm trying to spend time figuring out various 3D programs to produce my game art/look and feel.

I'm also new to creating computer-based music/sound effects for the games.

I've got plenty of tools, just can't figure out where I really want to start. :)

#70 Well if you have any questions feel free to ask Shane :)

The other day found a bug in my Torque DB, lol I had thought I spent enough time testing it to be nearly bug free, but found a pretty major one, even if its a simple one... Just goes to show you that you need to test your code in as many ways as possible. So thats been a recent challenge

You know when things get to you that shouldn't ? Maybe things you deal with on a daily basis that you can normally shrug off and remain posotive, but then for whatever reason you get a day where it just drags you down? Thats been the past couple days for me... things that I normally can shrug off and push beyond have been hitting my very hard... Not much to do but push through those times, am used to it, I usually am pretty perseverant things still can surprise us, I don't think we ever get past the point of being surprised at times.

Also have been struggling a bit to focus on my teams project... I think its because they have been feeling the same and up to this point I have still been able to focus, though with the past couple days dragging me I seem to get distracted a bit more... Need to just sit down and work on things and set some other goals to work on...

On a good note I have been working on adding C++ functionality, when I get what I want working I'll create a tutorial for it... should show how easy it is to extend fxSceneObject2D... in fact it will have to do with an inventory front end, hopefully a system to handle any type of slot drag and drop interfaces... so merchants, inventory , loot... so far I have a good design document and the implementation is going a bit slow but its going :)

well still interested to hear everyone elses challenges... you can even think of this as your Game Development journal lol ;)

#71 My last challenge was figuring out why my model of engine torque wasn't performing in-game the way the spreadsheet predicted. The current model provides a (reasonably) accurate model of engine torque (though I neglect component friction, bad! bad!). It divides rpm into three sections with interpolation of torque in each section. There's still a tendancy to over-rev the motor (with manual transmissions), but that is more a user-interface problem. At least now power falls off like it is supposed to and with an adjustment to the manual transmissions there isn't a ten or twenty mph jump each time you change gears.

I can't say I'm happy with the controls, but they're mostly workable (in other words, sufficient for continued dev with plenty of room for improvement). A hurdle for the future, so to speak.

BTW: even if the final objects are all defined in C++ it will have been well worth it to do first using Bryan Edds' OO Resource. Why? Because I'm designing as I go. A bad development model? Considering it's just me doing all the work I'm not sure it matters. The difference between coming up with a specification before hand and doing it as I go is that this way the specification develops in accordance with the reality of T2D -- if I were already expert in T2D it might be another story, but it is really helping me understand T2D, having results keeps me motivated and the feedback of having something to work with is great.

#72 @Tim Doty:
I'd really like to see your code when you finish. I tried implementing vehicle physics but realized it is way out of my league :( ... for now...

#73 @Matt: Well, a full implementation is a long way off still. I know enough to get it done, eventually... and don't read too much into my statement: it isn't like I'm modeling the engine cycle to get the actual torque in a continuous fashion (although that would be really cool even I realize it is unnecessarily complex). Still, if what I'm doing is interesting I'd probably be willing to do a show-and-tell.

#74 Tim, designing as you go is actually the best way to design. Design up front is only rarely beneficial in the cases you are %100 sure of the design.

My design technique currently involves designing late (after the major implementation) then refactoring to a better design right as soon as I come up with a better design. I call it 'design late, refactor early'. It works well.

Of course, on this project I am not using test-driven development, so that changes my approach a little. I have come to regret my lack of using TDD in this project, but I will certainly use it in my next one.

BTW, I guess it's time to update my resource to T2D 1.0.2 :)

#75 @Bryan: Design documents can be useful, but IMO their utility grows with the size of the project (team members). Its one of the ways to keep a group effort organized. Of course, management has a tendency to turn tools into the end and design documents that have been subverted in this fashion or worthless or less than useless. (I've seen a bit too much of the "for its own sake" management problem.)

But as long as its manageable I think the design-as-you-go really works well. I've rewritten my code twice now (or was that three times ;^) and plan on at least one more (going to C++ objects). I expect some further tweaking (realized that somehow I overlooked the effect of wheelbase on turn radius, doh!). My wife thinks I'm strange ('but it was working yesterday?' "yeah, but it'll work much better now") -- but that was true to begin with.

Oh, yeah, it'll be nice to have an updated resource ;^)

#76 What's design documents have to do with anything? When I talk about design, I don't mean producing artifacts, I mean getting the object structure right in your head, on paper, or anywhere else it goes before you implement it in code (usually by refactoring).

Also, you might want to consider refactoring instead of rewriting. Check out Refactoring to Patterns.

(make sure you understand design patterns and refactoring itself before reading this - there's plenty of books for each topic - I recommend Gof and Martin Fowler's respectively)

I'll update the resource as soon as I can get this T2D update on my computer. Windows keeps refusing to copy the file from the IE cache to the chosen place on the hard drive after the file is downloaded...

Who knows...

EDIT: Fixed link to Amazon - it was broken.

#77 @Bryan: I fear I'm veering off topic for the thread, but design documents have to do with formalizing the design so as to communicate the same structure to multiple people working on a project. When I say rewriting I mean that in the most general sense. And for this I'm not doing much design other than the implementation (code) which is why I made the original comment about best practice.

I do my best structure thinking with pen and paper, although I've had trouble keeping track of pencils at home (my desk has gotten rather cluttered) so I've taken more and more to using my drawing tablet (the pen for it hasn't been lost yet ;^) For tracking numerous objects and relations I usually resort to vector drawing (I often use PageStream for this, for me familiarity with the application has been more important than specialized functionality).

Thanks for the link, but it appears to refer to an area I'm not allowed to see. Refactoring is about improving an application, whereas I'm still in a design stage. As I said, for me and for this hobby project coding up the design as I go works out well -- I'm not saying it is good practice, but it 1) gives me something tangible to keep motivation up, 2) improves my understanding of T2D by seeing how things work rather than assuming, 3) the OO resource allows me to follow OO design principles better than stock T2D and for things that do end up in C++ I will have working code that is fairly easy to translate.

As I improve encapsulation it will become easy to extend the model as well. I'm already thinking of splitting motor components into separate objects. One of the cool things about OO is that, properly implemented, this can be done without touching any code outside of the motor object (well, and allowing selection of those components).

I still can't believe I missed accounting for more than just wheel angle for turn radius -- I just wasn't thinking. One of the pitfalls of single person development. It was talking about the project with a friend that I remembered neglected factors.

#78 A very good design document can help save time coding... at least from my experience :)

I also find it is essential for team based projects

#79 I fixed the link, BTW :)

#80 Well slowly I've been working on a T2D Gui Creator... right now I have basic buttons setup and working well... mouse overs, mouse down, mouse leave actions etc... (all script I'll add :)

I have whole "guis" working, when you add a button/object to the guis it mounts it to it with a correct offset using Melv's wonderful .getLocalPoint function (I think I spelled that wrong lol)... that really saved me a huge headache!

I have it where on mouse over and down states you can have an image display at a certain point... you can also have this image fly in from left, right, bottom, top, or a specified position... left,right,bottom,top can either do it from screen size or from an offset.

I have full fading working, with a couple actions that include safeDeleting on end, disabling on end, activating...

while something is fading in it won't work until its faded :) (very intentional)..

whole guis can fly in , fade in, etc...

I need to get the fly out functionality working as well as button flying in and out...

I've got in engine fading between mouse up and mouse over/down states working (90%)... provides a pretty fancy effect without having to animate anything....

I have blend buttons (so you can reuse the same image and just set blend colors for the states)... image buttons... as well as -animated- buttons...

they all use the same base core functionality too so only modify code in one place :)

Whole guis can save out to file and load in! That was a big plus... you can load this all to a seperate sceneWindow and scengraph that overlay the one your using for you game, so positioning stays the same (much like the Torque GUI)...

this has been a lot of tweaking... though its coming together, still plenty of work/optimization...

I started on the Gui Creator for it! It takes a lot of time to create Guis to create Guis rofl... I'm using the rather robust Torque Gui system to do it... This isn't meant to replace the Torque Gui System, just work with it, this is meant for the more fancy "Flash" style effects :)

Major props to Melv and Josh for the Particle and Tile Editors! I realize how much work it is now... a few hours of work (on the editor, many more spent on the whole system) and I still only have a fraction of it up, and even less functionality lol... but its getting there :)