TIGSource Forums

I've done a little c++ and gotten a text based dice/gambling game to work(you play vs. the computer).  So far that's my only finished program--about 800 lines. My ambition is to make a Final Fantasy Tactics-like TRPG.  How do I get there from here?

Well, I would definitely recommend something in the way of a game engine. At the very least, you would want some manner of graphical/input framework.

Starting off developing a text-based dice game is a good start. It gives you some of the programming basics without overwhelming you. A game like Final Fantasy Tactics is going to be a much larger project. Something like that is going to be WAY more than 800 lines.

I would use an existing game engine, preferably 3D-based, and create an orthographic camera centered on the middle of your play area. From there you define the basic interactions for the various characters and classes.

This.

Figure out if you want to go 2D or 3D, then find a game engine that supports your vision for the game.  For example, Unity has decent 3D, and I bet there are some extensions and scripts you can get online for making grid-based tactics games.

It's much easier to learn a new game engine than to write your own.

Are you people seriously suggesting that he starts with 3D programming after he just got his feet wet with console programming?

Here is my advice OP:

Don't be too ambitious. If your most advanced program so far is a text based gambling game, then I would suggest that you start developing some simple graphical games - Snake, Minesweeper, Pacman, Asteroids, Tetris, and so on. After you are well familiar with graphical programming, you can take it from there and ever so slightly increase the complexity of your projects.

I'm writing this to warn you not to have too ambitious ideas at first, as you will very soon find out that realizing a complex idea is not a walk in the park. It requires a fair amount of skill and dedication. A lot of novice programmers erroneously believe that simple games with simple rules are also simple to code. Think again. You need to code every part of your game. And what's worse, things have the tendency not to work according to plans.

Understand that nearly all indie projects never get finished. Those that do are actually an exception to the rule. This is almost always because the developer underestimated the amount of work required to make his or her brilliant idea a reality. It all sounds very nice when you write your concept down on a piece of paper, but do you have the dedication required to proceed even after half of your project crumbles down because of some design mistakes you made early on? Or after a nasty bug haunts you for a whole month and it drains every last drop of confidence from you? This is the major pitfall I am talking about. My point is, you need to have iron will to go forth with complex ideas. And you only get that by practising a lot.

Actually, I was thinking something more along the lines of Unity or Unreal SDK. (or Source, if he wants to stick to C++) Something that already has a camera system.

Programming a 2D isometric engine with rotatable playfields would be a massive pain. Doing the same thing in 3D with an orthographic camera is child's play. You can stil have sprite-based characters in a 3D engine if you want them, but the 3D would make the playfield much easier to produce and view.

Oh hell yes.

If he wants to make something, THAT is the ultimate incentive.  It's way easier to learn Unity (which is, let's all be honest, not that hard!) and make a game you care about than to make Snake or Breakout for the 8,000,000th time.  I've seen dozens of people with no programming experience learn how to make games through Flashpunk, Flixel, Unity and UDK tutorials, I know it can be done and I think that's how you start making the games you love.

Making shitty games may be a better way to learn programming, but it's not what I call game design, and it's not what I got into this field to do.  I'll never tell someone to do something so bland.

I mentioned that he should choose if he wants to go 2D or 3D, and that's still  a big topic to consider.  If I were making a FFT-style game, I'd do it in 2D.  I think it'd be easier, and it's how I prefer to make games.  But there are totally viable ways to make it in 3D, if he wanted to try that.

The thing is, if you truly want to perfect something, you need solid foundation. That's not something you gain overnight. It has to do with rigorous practice. You can use an engine that encompasses everything you need, but do it without a solid foundation and you will step right into many pitfalls that wait for you on the way. For example, if you have no knowledge of graph theory when you begin programming your fancy 3D game, how on earth are you going to deal with problems that require spatial partitioning? If you don't know what computational complexity means, how are you to devise efficient algorithms for your game? Sure you can use a fancy engine where everything works "out of the box", but do you really expect someone to design a good game without even knowing how his engine works? Every craftsman knows tools are essential, and knowing how to use them is what makes someone good or bad at what he (or she) does.

The bottom line is this: you can go half-way through and end up with bad games, or you can go the right way, learn from ground up and end up with awesome games instead. There's no need to rush. Learning should be an enjoyable experience.

Man I have no idea about graph theory and I seem to do okay at 3D games.  I know there's a lot I can't do - but there's also a lot I can do!  And I think I could probably make a FFT game just fine without it.

Nobody's saying he's going to make the world's best game with either approach, but I'd rather if new game devs were able to make games they loved, not games they totally understood.

The point is steady learning. I don't see how it makes sense for someone to jump from console programming straight to 3D programming. Surely it's far easier to play around with 2D triangles and squares at first, then move on to 3D when you're confident to do so.

Or maybe times have changed and engines really did get easy enough for anyone to use. I keep hearing Unity is easy. I'm kind of terrified by that. :ninja:

I think the reason I disagree is that you keep throwing around "3d programming".

You're right - 3D programming is hella hard.  But you don't actually have to know anything about 3D programming to make a 3D game.

I find this paradoxical. How do you make a game without programming it?

Using tools someone else programmed, of course!

Edit:  Of course this isn't the solution to every problem, but unless you have very elaborate or very specific needs, I think the engines that are commonly available tend to make graphics very simple.

Well, you got me there, I guess. :shrug2:

But, again, there are many pitfalls. It doesn't really matter if it's 3D or 2D. Actually I lost track of what I'm arguing here. All I really wanted to say is that one shouldn't have too great expectations when first entering the game development waters. Because 1 finished project is a lot better than 50 unfinished.

Being cautious, and keeping your expectations realistic, are certainly worthy goals. Cautioning beginners not to reach for the stars right off the bat is decent advice.

The thing is, the original poster in this thread has already managed to program a rudimentary text-based game using C++. As far as I'm concerned, he has covered most of the bases that a beginner/novice would need to. Anyone who can code a functioning game in C++ is probably ready to step up to a more robust game development solution.

And he was asking for a general roadmap. He didn't expect everything to just be handed to him. This showed some fairly realistic expectations in my mind.

While a Final Fantasy Tactics style Tactical RPG is certainly more ambitious than a text-based dice game, it is far less ambitious than most other ideas I hear from rookies. Japanese-styled Tactical RPGS are grid-based games that feature turn-based mechanics, and involve a lot of dice-rolling behind the scenes. While not exactly "easy" they are much more manageable. I could probably cook up a basic prototype for one in Unity over a weekend.

this thread makes me  :facepalm:

OP.

The secret is taking modest steps towards your goal, picking subgoals along the way that interest you.

There are a lot of things you are going to have to learn, and it will most definitely surprise you which parts are easy and which parts are hard, or time consuming. So scoping a goal is going to be extremely difficult, and if you get that wrong you'll be discouraged.

So your first step is to pick a goal that is slightly larger than your last that you can reach. It is also a good idea if this goal sets you up to pick a successor goal immediately after that carries you in the direction that you want.

Do not start with FFT. That is too hard. However, if you're obsessed with tactics, and maybe you are, a possible goal plan could be like this:
  1. Program a game that has battles with tactical decisions.
       -> have only 1 character type
       -> have only 3 characters on the field per team
       -> have only 3 actions
       -> have only 1 terrain type (w/ trivial graphics)
       -> have simple graphics for each, sound fx for each action, and maybe a music track (maybe not)
       -> no animations!

   This is already a pretty big goal!

  2. Add animations for the character sprite for each action
  3. Add more actions
  4. Add more terrain
  5. Add items.
  6. Improve the sound.
  7. Add "effect" animations, like explosions and spells.

What you really want to do is pick a point far away, like FFT, then clearly define the next best 3 steps to get there. Each step should build on the last.

Then you clearly define all the things needed to complete the first step. Then you try to do all those things. Then you get feedback, from us, your parents, your friends, the internet, yourself.

The single hardest part is writing out that plan. It doesn't take a lot of writing, but it takes a lot of asking, "what do I care about?"

Now here's the secret. At any point in the process you can revise your plan. Pick a new long-term goal, or just refine the 3 steps, or split the first step into 2 because it's really hard.

protip: Pick small goals. Always go smaller than bigger.

The only rule: always make the plan first. Show that each step leads to the next, and how they help build to your final goal. Then when you change it you'll know why you're changing it.

Post that shit here, then try to reach your first goal, and see what happens.

When you have a specific goal and a specific problem reaching it then we can be way more helpful in telling you what you need to do, because many of us have had to face similar problems.

Well, if you REALLY wanted to create a more scaled-back version of Final Fantasy Tactics, you could just take the multi-tiered aspect out of the play field, and construct the game as a basic square grid from a top-down perspective. This would simplify the rendering requirements drastically, while still allowing you to play around with some of the core mechanics. With a top-down 2D perspective, you would no longer need to worry about movement over multi-layered terrain, and you would never need to rotate the playfield so that you can view it from different angles.

The core elements of a game like Final Fantasy Tactics are the playfield, selecting and directing characters on the playfield, and the actual turns themselves. Any grid-based playfield is going to be much easier to deal with, grids lend themselves well to numerical operations. The most advanced and troublesome aspect of a game like this would be developing the enemy AI.

If i get it correctly this final fantasies tactics is a sort of chess right ?
but with more classes, many different moves per class and abunch of actions per class and general ones.

I'd concentrate on that part before you go all jingle bells and whistles in Unity3d.

So I would prolly make a top down 2d checkerboard and concentrate on the gameplay/mechanics first.

still pretty bare metal, and still not too far from console programming.

I get the sentiment in this thread as in : "Yo dawg Yo don't need to understand what you make, use high level tools, Unity is the best thing" but i don't really agree personally

I would have suggested first trying something like SFML, then learning about drawing 3D using OpenGL or Direct X.

From then only there is enough good knowledge about basic game code structure to understand choices made by engines. It's too early for a full engine.

I would suggest trying to do it in 3D. Making half-decent 3D models is a lot easier than making half decent sprite art.

What if he concentrate on coding first and just use geometric shapes first, see with art later?

I would rather suggest him something like shining force or Fire Emblem
http://www.youtube.com/watch?v=hqSPdGobHR4

While 2D is fine for learning to program, you will learn jack squat about actual graphics. When you use SFML or something like that, essential concepts such as shaders, buffers, and projection matricies are abstracted away. If you use SFML, the extent of your graphics programming will be moving square sprites around, or maybe even applying a post-processing effect. Very little of what you learn from programming in 2D can be applied to other fields or 3D.

Here's what I think would be the best way to really learn ::graphics::

-Use some kind of open source framework that wraps around either opengl or direct3d. XNA(monogame) is my personal fav.
-Use said framework to make a simple game using the default shader. Through this you'll learn about buffers and a bit about how matricies are used.
-Now that you're familiar with using the framework, crack open the source and take a look at how the interface actually interacts with direct3d or whatever. If you're using XNA, the monogame source is an excellent tool.
-Look at how the framework sets up your shaders, basic fields like VertexPositionNormalTexture, and even the shaders themselves to get a good idea of how it all works and interacts with your code.
-Using your knowledge of the framework, you can modify certain pieces of it for special behavior that you might require, such as setting up the vertex declaration for a custom struct input for your shaders.

That's probably the best way to learn 3D. If you jump in head-first into raw opengl or direct3d, you'll likely be overwhelmed by all of the vertex buffer crap and hopelessly bad documentation. When I tried to go heads first, my main problem was that the examples never encompassed the kinds of "special behavior" that my program might require because it wouldn't fit into the general case.

By learning off of a framework first, you don't need to worry about whether or not you're implementing the correct version of glmapbuffers or interleaved arrays or anything like that. After your code is working you can pop up the hood and inspect the internals of how the framework actually handles all that fancy stuff, and then use that knowledge to write your own framework custom if you really want to, or you could add onto said framework for your future requirements.

@OP

My advice to the OP is to use SFML and make your game in 2D, using rectangles (and eventually sprites) that you click on to select units etc. Game programming is very tricky, and using 3D when 2D will be just as good will just make the job a lot more difficult.

Also if you want to develop your c++ knowledge (a great thing for any programmer to master) then stick with it and don't use a framework that doesn't support it. Using a c++ 3D engine like Ogre will be very tricky, so stick with SFML for now. You can still do some awesome looking 2D games, with shaders, layering, and other effects.


What are you talking about zalzane? .. you need to know GLSL to write a shader in SFML. Also, many concepts in 2D apply directly to 3D: geometry, transformations, linear algebra, compositing, fragment shaders, etc.

I'm not familiar with SFML. I was under the impression that it's OOP SDL.

AAAAAh!

Just do whatever. The most important thing is that whatever you pick gets done, and sets you up to do the next thing.