C2 is capable of making a turn-based strategy game, but it's one of the most difficult types of games to make. As far as I know, there are no tutorials for how to make one because of that fact. You should probably start with something simpler to learn how to use construct 2 well before attempting to make something so complex.Arima2013-04-08 22:42:31

Allow me to disagree about the difficulty of a turn based game. The state of who's turn it is can be represented in a variable. Then use the variable compare condition in events to control when things happen. That is pretty much the main aspect that makes it turn based.

After that you can tackle each other aspect individually. The computer AI will be the most difficult but is doable.

I'm inclined to agree with R0J0hound on the ease of developing a turn based game... for someone who knows how to work with Construct. It can definitely be done, but I would agree with Arima in that you would be better off starting with something similar before tackling something big like that, at least to learn the ropes and get really familiar with Construct.TL222013-04-09 04:49:54

[QUOTE=R0J0hound] Allow me to disagree about the difficulty of a turn based game. The state of who's turn it is can be represented in a variable. Then use the variable compare condition in events to control when things happen. That is pretty much the main aspect that makes it turn based.

After that you can tackle each other aspect individually. The computer AI will be the most difficult but is doable.[/QUOTE]

Oh, the basics are simple. I had a basic version of the battle system of loot pursuit running very quickly when I first started on it years ago when I didn't know what I was doing that seemed to work just fine at the time. It's all the extra layers of the rest of the stuff that's not basic working with all the other tons of systems together smoothly that becomes a very complex problem if you don't know what you're doing from the start, one that I would not recommend for someone starting out with construct (though it did end up being quite an effective learning experience for learning how to use construct for me). RPG's in particular at first seem simple to make, but are extremely deceptive with how complex they end up being.

Also, you are one of the top level programmers around here, so what's easy for you, as I'm sure you're aware, might not be easy for someone else. :)

[QUOTE=TL22] I'm inclined to agree with R0J0hound on the ease of developing a turn based game... for someone who knows how to work with Construct.[/QUOTE]

I still maintain that even with experience, anything past the most basic of RPGs is going to be a much more complex task than it seems. I feel confident stating this objectively as I have read many other people agreeing to the same thing who have attempted making RPGs.Arima2013-04-09 05:54:48

[QUOTE=Arima] [QUOTE=R0J0hound] Allow me to disagree about the difficulty of a turn based game. The state of who's turn it is can be represented in a variable. Then use the variable compare condition in events to control when things happen. That is pretty much the main aspect that makes it turn based.

After that you can tackle each other aspect individually. The computer AI will be the most difficult but is doable.[/QUOTE]

Oh, the basics are simple. I had a basic version of the battle system of loot pursuit running very quickly when I first started on it years ago when I didn't know what I was doing that seemed to work just fine at the time. It's all the extra layers of the rest of the stuff that's not basic working with all the other tons of systems together smoothly that becomes a very complex problem if you don't know what you're doing from the start, one that I would not recommend for someone starting out with construct (though it did end up being quite an effective learning experience for learning how to use construct for me). RPG's in particular at first seem simple to make, but are extremely deceptive with how complex they end up being.

Also, you are one of the top level programmers around here, so what's easy for you, as I'm sure you're aware, might not be easy for someone else. :)

[QUOTE=TL22] I'm inclined to agree with R0J0hound on the ease of developing a turn based game... for someone who knows how to work with Construct.[/QUOTE]

I still maintain that even with experience, anything past the most basic of RPGs is going to be a much more complex task than it seems. I feel confident stating this objectively as I have read many other people agreeing to the same thing who have attempted making RPGs.[/QUOTE]

I know I'm bumping an old thread but does anyone have any proper sources behind the logic of a generic rpg like final fantasy? I'd imagine factoring in spells, element types, strengths and weakness's would be rather tough. Same goes for creating instance variables for each character such as attack,defence,speed, etc..I'd also imagine character progression would be hard as well for the stat points of your character.

@ArimaAlthough I'm not making one yet, its something I'd like to work in the future, and after seeing loot pursuit it seems that your probably one of the most experienced with making RPGS. Do you think you could discuss how you layed out the battle system? As in the the turn based function not so much the other flashy stuff? Because it looks really amazing

Sure. First I want to mention though - this is not the only way to make RPGs! This is merely the best way I've come up with for the games I want to make. It allows me the flexibility and control to make super mario rpg type battles as well as simpler old school final fantasy type stuff.

All hero and enemy sprites are put in a family called units. I then create and pair a 'base' sprite instance to each unit instance by storing uids of both as variables for picking purposes. The base sprite does all of the controlling of the units through variables that define the unit's behavior and abilities, such as base.type, base.team and base.command. In a way, the base acts like a family for all units. I don't just code for the units family for various reasons such as I find it simpler to code the movement of the base object itself moving on the x and virtual z planes, and using a variable for the y (the height the unit is off the ground/the y distance between the unit and its shadow). Technically this could be done anyway coding the unit rather than the base, but since there are times where I can code the base to do stuff without needing to pick the unit at all, I prefer it this way.

By using this method, I can have any unit act like any other unit simply by setting a variable on the base sprite. It's also easy to make different units use each other's abilities if I want, as long as that unit has the requirements (like animations) for the code to use the ability.

I isolate code as much as possible in a 'code tree' to minimize code interfering with other code. Extremely oversimplified example:

If global mode = paused, store all menu code as subevents hereIf global mode = battle - if var battlemode = intro, store code for characters running on screen at the start of battle here - if var battlemode = advance turn, advance turn markers, pick a base/unit when it's their turn, set base.turn to 1, set battlemode to action - if var battlemode = action - - if base.turn = 1 - - - if base.type = Renae - - - - if base.command = "attack" - - - - - if base.step = 0 (the step var is not necessary in this example, but used quite often in many of the abilities to keep segments of the abilities and cinemas from interfering with each other), run forward, upon reaching target position, play attack anim - - - - - - if anim attack playing and Renae's animation frame is above or equal to 5, run function 'hit' with perameter base.targetuid, create damage numbers, hit fx, etc - - - - - - - on attack anim completed, run back, on reached target position, set base.turn to 0, set var battlemode to advance turn, set turnmarker.x to left side of screen - if var battlemode = victoryIf var mode = cinema - If var scene = first battle - - if step = 0, walk in from screen left

Firstly, as @arima mentions it is a tricky thing to approach for your first game due to the lack of tutorials, and also the lack of Board Game style Behaviours etc (though there are some useful third party plug ins, I opted to do everything myself so I would learn more). Since Board Horde is my first ever game and I've only been using C2 since December, it is doable if you're patient enough.

Things I'd advise getting to grips with are: Variables (which you will use for a lot of the commands within the game), Families (useful for grouping units together when the same conditions apply to all of the units), functions (I didn't discover these until several months into my project, and could've halved the amount of events I was using and the time it took to make the game if I'd been using them from the offset) and Groups (I also use arrays to create my boards, and store direction changes for when the heroes hit the corners, though this isn't essential).

Using groups is very handy for a turn based game, as it allows you to disable events you're not using and organise everything methodically (basically, as you open one door, you close another behind you) So for example, in my game once Player Ones turn has ended it opens the group Player Two and closes the group Player One behind it. Then it opens the group 'Dice Roll'. Once the dice has been rolled, it opens the group 'Collision Detection Movement' and closes 'Dice Roll'. Once the Collision Detection Movement orders have been carried out it opens the group 'Collision Detection Consequences' whilst closing the previous group...and this continues up until the End Turn group, when the next players group is opened.

With regards to a.i., how tricky this is to pull off with depend on the complexity of your board game. For mine it mostly involved replacing touch commands with variables. So instead of waiting for a touch command to roll the dice, it would check to see if the a.i. Boolean= true, and then roll the dice. When it comes to the a.i.s intelligence, to start with I created a V.I routine (as it operates with all the intelligence and reasoning of a Village Idiot) which basically operated like this: if more than one a.i. piece is on the board, randomly choose one and move them. You can see this in action on the Newgrounds Touchjam version of the game here: http://www.newgrounds.com/portal/view/616297

As you'll notice in the comments, the main gripe people had with it was the easy ai (as it blunders around the board, and dies lots). The updated a.i. Which can be viewed in action in the link on my c2 forum entry works a lot better, as I created a routine that runs in order of importance. Eg, is hero stood on the Entrance square? If so, move (as its a dangerous place to be). Next: if hero moves will he land on an opponent? If so, move. Next: is hero further ahead than all others on his team, and if he moves will he land in a free space? If so move. Etc, etc. When the a.i. has selected something that meets the highest priority condition, it changes a variable to Hero Selected=1, and all other a.i. checks that come after are ignored.

Anyway, I'm probably taking up about 18 billion pages with my waffle so I'll stop now. If you have questions about any element of my board game then just ask (though bare in mind I'm learning as I go, so the way that I'm doing things is not necessarily the best way).