Well well, what do you know. Following TDTK, I've been started to rebuild TBTK from ground up too. I've only created the package a little more than a year ago. It is not even that old. But my OCD gets the better of me I guess.
Consider that many user do end up doing modification of their own, I think it's only right I clean up and streamline the old code, which is pretty messy at place. The turn logic is quite dodgy on hind sight. Not to mention there's lot of patch work since I've added stuff like hotseat multiplayer, fog-of-war and cover system, etc. The goal in the new TBTK, is to redesign all those features as an integrated system from the start. I'm quite happy with the result so far. I'm sure another who want to mod this in the future would appreciate that. On that note, if you are trying to mod the current released TBTK, I do apologise...
I've also taken the opportunity to redesign most of the editors to make it more manageable, if not more intuitive. The spawn/deploy area on the grid for instance, now can be painted using mouse in SceneView. Instead of painstaking setup factions information across different component using Inspector, there's now a window to do that with all the information at a glance.
Also the grid system has been overhauled and now it can support a much much bigger grid. See for yourself, the next image is a 80x100 grid. Keep in mind I still haven't test this thoroughly so while the grid generation is not an issue, other aspect of the game might be. We'll see.
It's early days and I still have a long way to go. I barely manage put the key components together at this point. But I do hope you like what you see.
Looks excellent mate.
ReplyDeleteDo you have a rough guesstimate of a release date?
I have been modding the current version a little but it may be worthwhile waiting...
I would be happy to beta it for you as well.
Thanks
Phil
I plan to complete the package in two weeks, hopefully. But this is based on Unity4.6 so I dont think I'm going to release it until the beta ended. However I'm happy to send you an advance copy when it's ready. We'll see.
DeleteHow long did it take for you to do all this scripting?? I just began to learn C# Programming and somehow found your blog. I'm not sure where to start studying, can you help me by giving suggestions? (I'm about to buy TBTK & TDTK toolkit to learn source code inside, but I feel like I can't understand any code ㅠㅠ) sorry for bad grammar.
ReplyDeleteIt takes quite a while to plan out the system, how componentA interact with componentB and how componentC works on top both component A and B. It gets easier once that is sorted. Still, the whole thing could have easily take 2-3 months or more if start from fresh. Keep in mind that this framework has been in on and off development for a long time.
DeleteTo learn, it takes even longer. I start with some prior knowledge about programming and start using Unity almost 4 years ago. I would suggest you to go through a simple tutorial to grasp the basic concept of Unity. Then pick start a learning/challenge project, think about what you want to do, how you can do it, and just simply trial and error through it. Google a lot. Unity forum and the scripting documentation is your friend.
Give it time and practise, you'll get there.
p/s: If your grammer is bad, mine is just as bad as yours.
4 years and many practices, now that's a lot of time you invested. I'll keep your word in mind, Thanks for replies.^^
DeleteSweet, can't wait!
ReplyDelete(don't forget the diagonal movement! * hint hint * haha!)
Damn, I was hoping that no one mention it and I can pretend that I forgot. :)
Delete(Ah darn, it just deleted my reply cos I wasn't logged in! Bah)
DeleteHey Song,
I was just wondering why the limitation of the diagonal system? Without it, it limits any possibly games that aren't Roborally clones, so you have to blame Xcom for setting the expectations :) If I was a programmer I'd probably try and help :P
/D
Not sure what you mean by 'why the limitation'? Is it why I dont put it in? or why it's difficult to implement?
DeleteYou see the code uses using manhattan distance for the range calculation so that the distance from one tile to any other given tile is always in a round figure. This way, the distance can be objectively determined using naked eye. So when you set a unit move/attack distance to a figure, you can always be sure how far it can move, regardless of the tile size or the value itself.
This is simply not possible when you allow direct diagonal movement unless you consider diagonal distance as 1. When you do that every area defined by a radius will simply be square, which doesnt look very natural. And although I never really profile this, but my gut feeling is using diagonal tile in calculation will be more expensive in term of performance.
I admit at the end of the day, it's to some extent a subjective preference of mine. But dont worry, although the calculation doesnt consider adjacent diagonal tile, I've added smoothing algorithm. That is whenever possible, the unit will move in the diagonal manner.
Thanks for the reply. For me specifically, optimization isn't an issue (and can't see how it can be in a turn based game?) - I was thinking something much simpler, like diagonals just cost a bit more (tweakable float like 1.3, as it would depend on the general unit speeds) so you get a more circle-like feeling.
DeleteOf course, like the cool customizeable of the framework, it would be something you could enable if you wanted the optimization.
Again, thanks for making this cool framework :)