Platform tutorials

#41 I would like to add a little perspective from the GarageGames viewpoint. I hope this does not come off as defensive because it is not written as such.

A game engine cannot do everything. It can be a great starting point, but it can't do everything. TGB is designed to be a good starting point for 2D games or games that have 3D objects used in a 2D manner. It was designed to be easier to get into than 3D, and I believe we have hit that goal. In the future, we will continue to make it easier to use, more powerful, and have a lot more tutorials, documentation, and examples. We feel there is already a bunch of this kind of material, but we want more, more, more.

TGB can make a great scroller in a couple of hours. The scrolling space game that ships with the product proves that. It can make card games, top down racing games, bubble poppers, and an infinite number of other products without touching the C++ source code. To make a Mario clone, you will probably need to touch the C++ code. I don't see how that can be a problem. It is still a huge boost to making that game.

As Dan indicated, there is a HUGE amount of design, programming, and game play tweaking to make Mario jump. Where do we stop with the built in functionality? Saying one way platforms should be in the core engine could be countered by another developer that says all 2D card games require deck shuffling, and it should be included in the core engine so we have a "Torque" way of shuffling cards. Again, I ask, where would we stop? What amount of coding should you have to do to make your game?

If we had not provided the source code as an option for serious developers I could see how this would be a problem. But, unlike modding the Unreal or Source engines, TGB allows you to have access to the source code so you do not have to lobby the developers to change the core engine.

Imagine if we supported every single game type out of the box. Then the comments would be that the engine is too large and complex, and is weighted down with extra code. I think a much better method is the RTS Starter Kit or the way that Sickhead Games helped us add the adventure game/RPG functionality, i.e. an additional cost code pack. That way, you can decide if the additional features are worth your time to code or worth your money to purchase.

Thomas is working on a framework for platormer games. Initially, it will probably be added to TDN as a free resource, but I cannot promise it will be free forever.

From my perspective of being a professional developer, I cannot imagine a game that I would release that would not have at least some touching of the C++ code. But, there is nothing wrong with that. That is why it is there. Many game engines are nothing but C++ code. TGB has a lot of rapid development features, but remember that C++ code used to be considered high level.

As a community, we can work together to bring these products to market, squish the bugs, and even add functionality to the engine, but at some point, as a game developer, you need to decide when you efforts are best aimed at writing some C++ code and moving on with your game.

-Jeff Tunnell, GG

edit: sp

#42 Do anyone have work player.cs from miniplatformer on TDN. No matter what I do I get a paser error on line 131 in function t2dSceneGraph::onUpdateScene(). I have read the Tutorial mant time and redid the player.cs many time but nothing work. Thanks!
My player.cs is on this thread http://www.garagegames.com/mg/forums/result.thread.php?qt=50748

#43 That said, I've been impressed with the amount of functionality and gameplay you can achieve with a pure script solution. I would even go as far as saying you could make a good platformer with pure script. It might not be amazing with sonic style loop-the-loop's and gish style pysics based platforms etc. But something along the lines of bud redhead seems within the real of possibility. Certianly superstar chefs...


Both of which were good selling games would be possible or nearly possible with torque script. There would be a lot of script to write, but such is the nature of making games. TGB is not a game maker, it's an engine with good content tools and a customizeable architecutre that makes it really easy to get content into your game and gives you a lot of core/basic functionality for free.

#44 Jeff -- Thanks for the reply. It does help clear up some things in my mind. Chiefly:

- Torque won't provide everything I need
- I should modify the C++ source to add what I need

Good to know. I think I was under the impression before that Torque wanted to support pretty much anything you could dream up, from script only, and obviously this isn't the case.

I personally won't be working on a platformer until mid-2007 at the earliest, so I will wait and see what Thomas comes up with in terms of a framework for platform games. (I don't suppose we'd be able to request features we'd hope to see in it, such as "moving platforms" or "conveyor belts"?) I would happily pay whatever amount you would set for such a framework... no need to release it for free. But that's up to you of course. I'm sure other folks on here would love to have it free. ;-)

#45 @Vern: We certainly are open to input, especially for broad solutions that are game genre agnostic--which is part of the problem of coding/optimizing for a specific genre in the binary.

That being said, quality functionality requests (the more detail the better assuming it makes sense!) are always appreciated!

#46 One thing that consistantly throws me off is the misconception among some of the community members in regards to just how many people are working on any given thing at GG. It reminds me of a while ago when someone posted on the forum to congratulate someone for 'beating the GG system'. A few of us just looked at each other slyly and said 'we have a system?'

The truth is that there is a whole lot going on here and not a whole lot of people. The platformer template started as a sort of side project between two of us just for fun that we would work on after-hours... long after everyone left the office. It became fairly robust just from us adding functionality while being mindfull that we might use the code base for other things. It was at a nice solid point after about two weeks of working on it off and on and I had every intention of finishing it, but my internship was up and I wound up going back home to Florida.

Now, a month later, I'm back at GG (this time as an employee) and the platformer template is still swimming through my head. I work with the code every day because I'm using the template to remake Mighty Fist at the moment, but it just keeps growing. As I said a while ago, the best way to make sure it's flexible is to use it to make a couple things and expose its weak points. MF has done just that and a whole lot of stuff has been added that had never even crossed my mind (for example, a field on the actor to specify which frame of the jump animation to actually begin the upward motion, and countless other things).

That said, Mighty Fist is still in the works and once it's done I hope to be able to revisit the template and merge all the relevant functionality into it. On top of that, I have been reading the forums (literally every day), and I have been mulling over certain things that are on my wishlist for the template and when I see them mentioned on the forums it only reinforces my desire to add them. So don't be shy with the suggestions, because if you don't mention them they are infinitely less likely to make it into the template.

At it's current state, the platformer template includes the following features: three seperate camera types (track target, show all players, and auto-scroll), solid and one-way platforms, automated physics-based/state-based animation management, built-in pickup/collectible system, full horizontal parallax using both scrollers and normal objects, very simple combat, easily implemented state-based AI, easily customizeable actor control, and a few other things.

Just from this list it should be obvious the number of problems that could arise making a system like this work for any and all platformers, and because of that you can bet that it won't be released until it is fully tested on several projects. That fact, combined with the fact that there is nobody directly working on the template itself right now due to the fact that we are all spread fairly thin across a bajillion different projects, means that it might be a little while before you see anything released. It's not that nobody at GG cares about releasing a platformer template, it really jus boils down to manpower. The team can either fix bugs in the engine and update functionality to make TGB better as a whole, or work on specific demos - right now we are trying our best to do both. I would personally like to get it out to you guys soon because I would love to see some nifty platformers popping up made on TGB, but it can't be done until it's done, and I personally don't feel that it's ready to be released.

For that, I'm truly sorry. I almost feel as though it was a mistake to mention it in the first place because it kinda seems like a lot of people are just sitting around waiting for it, and when it doesnt drop they blame GG. There are a lot of questions that developing a platformer raises and there is no one final answer to any of them. There are many different ways to resolve a lot of the issues you face when develpling any game, but I've been trying to chime in when appropriate to offer some advice and helpful hints as to how we tackled some of those problems when developing the template. Unfortunately, right now that's the only thing I can promise. And also that the platformer template will be released once it's worthy of the GG community.

-Thomas

#47 Thomas, why cant you just release the current content as you described

"At it's current state, the platformer template includes the following features: three seperate camera types (track target, show all players, and auto-scroll), solid and one-way platforms, automated physics-based/state-based animation management, built-in pickup/collectible system, full horizontal parallax using both scrollers and normal objects, very simple combat, easily implemented state-based AI, easily customizeable actor control, and a few other things."

As a WIP. We can sneak peak into it and use the great stuff until you find more time to complete the framework? ROME wasnt build in one day but all the things you have mentioned whould help me and my hobby project ALOT!
I even would give you some bucks for it. But currently at the moment, iam forcest to sit and wait. Since iam not a experienced C++ coder like most of you. Iam more from a creative corner and iam working on a charity game that hopefully will help down here.

#48 As the guy who is directing and managing the teams creating this stuff, I will give a hopefully clear response to this.

We will release the frameworks when we feel that they are good enough for people to builld upon. Right now, they are getting close, and we have more than just the Platformer framework in production.

What we are doing internally is working on a great number of small example demos that people can build off of. When we find common generic fucntionality, we take the functionality and create a framework out of it. During this process, we are also banging on the tools and editors and finding out what works and what needs to be streamlined.

We are aware that people want more sooner, and we are working as fast as we can. We are moving pretty fast on the demos we have in production, and to release something too soon means that we released something half finished and we get complaints and discussions happening which the developers need to address.

This mini platformer tutorial is a great example of this. Dan wrote it and intended it to be a ' how to get something working in under 15 minutes' tutorial, and not the end all-be all for platformers. When we release the platformer framework, it will be better than nothing at all, but I am sure that it will not include some 'necessary' (according to some opinions) functionality.

The frameworks that we release will not be the end all and be all of anything. They will be launching pads that give the basic functionlity (and perhaps some more advanced functionality) that will help get you from zero to sixty faster, but they are not going to get you to the finish line. At some point, all examples, tutorials, and frameworks will not give the developer everything they need in order to finish the game.

We do plan to do more tutorials (especially the mini tutorials), more demos and examples, and provide it to the community as building blocks.

When I talk to my teams, I give them some conceptual examples, which I will share with you here so that you understand how I concpetualize what we are trying to acheive.

example #1 : what we are providing are tools. When you walk into Home Depot, what you see are aisles and aisles of shelves of tools and building materials. There are also books and brochures or how to paint, how to pound a nail, and even how to build a house. There are helpful people there who will show you all the power drills and skill saws and nail guns. We make these nail guns and drills. We do not sell pre fabriacted housing. If you want a house that was designed and built by someone else, you can go to a housing development and get a cardboard cookie cutter house. We make the tools and supply the materials to build the house. The creation of the house is up to the person building the house. Our goal is to help the person build the house that they want to build. If they want to see how a house it built, they can look at the house we made and take what they think would work in their house.

example #2: Lego. Lego is a building block. We provide the bricks, and some instructions on how to assemble them. If we see the need for a new specilized brick, or assembly of a subsystem of bricks, we will do so, but our goal is to provide 'bricks' for our end users to assemble into their creations. We can assemble some of these bricks in interesting combinations to show people how to assemble the bricks, but at the end of the day, the way an end user assembles the bricks is up to them.

These examples are visual descriptions of my goals. My goal is to provide you, the end user, with everything you need to build a game. My secondary goal is to not take away from you what is yours, which is building something that belongs to you.

In house building, the purist would say that unless you cut down the tree with a saw you made yourself, you are cheating. That person is not me. Most houses can be built with 2x4s.. so we will make the 2x4. Most house use nails to assemble the 2x4s.. so we will make the nails, and the hammer. We will write a little pamphlet about how to nail 2x4s together to make a wall. When we start making pre assembled walls, we have gone too far, as then we get people screaming at us telling us that the wall we made was not the wall they wanted, as it is not the right size, and oh yeah, it does not have a window and wiring for speakers and .

We are working on tools and instructions on how to use tools. As part of the instruction we will provide examples of things we built with the tools, and we will use the tools that we are selling to actually build the things that we are using as an example. If we discover a new tool is needed, or one needs to be improved, we will build that tool or improve an old one. We will let you come into the house we built, rip apart the walls and see how we made them, look at how we put the plumbing in, and how we routed the heating ducts.

If someone wants to take our house and modiffy the design for their house, more power to them. If the plumbing for the house that we built breaks down in the house the person is trying to build, we are not going to come in and fix their plumbing. We will show them where to get pipe and point them to a resource where they can learn about how to plumb a house, and hopefully they will figure out how to get their water flowing.

If someone wants to take a 'house' that we build and use it as an airplane hanger, more power too them. If they come back to us and complain that the house was not designed to accomodate the wings, we will respond, and probably be maligned for saying, well.. don't use a house as an airplane hanger.

As for letting everyone in on WIPs.. we will when we can, and there is a delicate balance between releasing something that is going to help people and slowing development on a project as the developer has to assist people on the use of the thing we release. There is a lot going on, and a lot that will be coming down the pipe. TankBuster is but one of many projects we have underway that show off both what can be done and how to do it.

Like Jeff stated above, I cannot imagine a game where the C++ code is not touched, but we are working to make it so we can build an game that is graphically and functionally on par with any game you would find on the casual game portals, and we are doing it with the binary version of the engine. If we find something we feel needs to be added to the engine, we will add it. This takes time to do right.

hopefully this helps people to understand what we are trying to do here. As for specific needs, let me know about the areas of the engine where we need better tools or better tutorials on how to use the ones we have and I will do my best to address the issues.

#49 @Andre - Honestly if you are really just sitting and waiting for it, it most likely won't do you a whole lot of good. Like Joe just said, it's just another tool for you to build with, it's not a 'make my game' button. Also, you don't need to know C++ at all - the template is written entirely in script.

-Thomas

P.S. I realize the above might sound a little cold, but it's not meant to be. All I'm getting at is that making a game takes work and dedication. If I'm working on a project and I don't know how to do something that's required to make the project work, I'll figure it out. I'll ask around and bang my head against it until it does what I want, and that's kinda the attitude you have to have. You can't ever believe that there is something that you just can't do, or you will prove yourself right.

#50 Well. Than GG should rename TGB. Since its have nothing in commen with a "Game Builder" when I cant build anything.

I dont want a "make game" button nor I want a game that I can modify. But the current tutorials (the one I need are outdated and pre TGB (focussed on T2D) which is not useful in the current state.

#51 "Well. Than GG should rename TGB. Since its have nothing in commen with a "Game Builder" when I cant build anything."

You have the right to your own opinion though I know many would disagree with that statement. In fact take a look at the snapshot of TankBuster.


"But the current tutorials (the one I need are outdated and pre TGB (focussed on T2D) which is not useful in the current state."

In game dev there isn't always someone to get you a step by step instruction on making your game. We're doing our best to give you a reference to most of the game types you can think of though. We try to uphold a high quality in what we release and in the end it hurts you more if we give you something unfinished and then something finished that has some sections completely different.

#52 From the perspective of someone who spent 4 years (high school) making games writing directly to OpenGL from C++, I feel that TGB really is a "Game Builder". The simple fact that if I want to make a platformer I can sit down, throw some art together, make a level using drag and drop, and the first scripting I have to do is worrying about how to make a character jump tells me that TGB is a huge help. I don't have to worry about a huge class hierarchy, managing collision, image loading, etc. TGB lets you build games instead of building an engine and tools first. Games are hard to make and TGB makes it much, much easier. That's my sense of the matter ;)

#53

Quote:Than GG should rename TGB. Since its have nothing in commen with a "Game Builder" when I cant build anything.

(emphasis mine)

You do realize that your complaint about the tutorials being dated is precisely the reason that a sneak peek of the framework is not available. There is nothing stopping you from updating the tutorials to work with the current version and your specific game, especially since there are a number of topics on the forums about doing just that or finding the right places to look. You also do not have to be a C++ programmer to find the right places to do it for most of them.

Initially, I was skeptical about the name Game Builder because T2D itself seemed more like a framework than a "building application". With the different toolset releases, the level builder being the biggie, it looks, acts, and feels like a game builder. It won't make your game for you, but it makes it significantly faster to make your game, which is the purpose of a good tool.

#54 Thomas Buscaglia wrote:

Quote:So don't be shy with the suggestions, because if you don't mention them they are infinitely less likely to make it into the template.

Hehe. Okay. Here's my "dream wishlist" for a 2D platformer:

1) Tiles *and* moving sprites that act as "platforms" -- you only collide with them when you're falling from above. But otherwise you can run/jump right through them.

When it comes to moving sprites, this is even more tricky, because you must "ride" on the platform as it moves. Including platforms that go left/right as well as up/down.

2) Non-rectangular tiles - both with straight slants, and curves, to the player can do things like slide down hills (Mario 3), run up hills/slopes, etc. a.k.a Sonic the Hedgehog, or Bud Redhead.

3) The ability to easily determine the type of *all* tiles you're standing on at the moment. That way, you can implement things such as:

- Conveyor belts (these are animated tiles that move the player left/right as he's standing on them)
- Mud (slower walking movement)
- Ice (little friction)
- You get the idea

I'm not saying you need to implement conveyor belts, ice, or mud. Just give the developer the ablity to get a list of *all* tiles he's standing on, so he can add anything he wants.

Hmmm, I think that's about it. Everything else the developer should be able to add pretty easily.

Note that all of the above would apply to the player *and* any ground-based enemies. So ground-based enemies should be able to ride on moving platforms, walk on slanted tiles, etc. Not hard if the player can.

#55 Those are all good ideas. As for ground-based enemies, they inherit from the same class as the player (the Actor class) so all the core movement and world-interaction functionality is exactly the same. In addition, there are a lot of fields on the actor class that you can define for different character/enemy types to customize their basic mobility.

#56 Well, you all gave me valid points but I fear that the moment "Torque X" is going live, the current work on TGB will be stopped, especially the tutorials and frameworks. I guess everybody will focus on Torque X which sounds like a extended, enhanced TGB Version to create X360 games. And that is in many eyes, the future of game development.

#57 Andre: Your statement could not be further from the truth. We will continue to work on TGB native code just as we are.

#58 Allright Jeff, good to hear. Sorry for my statement. I had the descriped experience with a other engine company and I feared to see this might happen here aswell. But now I will sit and read all the tutorials to hopefully get enough knowledge to start with my game until the framework is released :)

#59 @Andre, if while reading the tutorials you feel you are translating from T2D to TGB or even 1.1.0 to 1.1.1 ... please, feel free to add your two cents and update the tutorials to reflect the 'new' methods, or best practices (if you come about any).

@GG Staff, you guys are doing great, and TGB really is a game builder, I did some work with the Allegro library when it was still in WIP status, I've also done some work with SDL (via Python, C# and C++) -- not having to worry about half the stuff I had to worry about with those libraries, and having the drag and drop level builder and animation tools, is a blessing ... I also feel the community, and the support it provides is outstanding and I'm glad I made the decision to go with Torque technologies and plan to extend my Torque tools greatly in the future.

#60 Will do David :) Great Community btw!