This game would be quite easy to do, aside from the graphics artwork (always my weak point) and the internet multiplayer. I'd say the best way to maek this EASY would be have the game output a file to the desktop with all of the positions of the figures on the gameboard and the history of the match, then have the user email it to the opposing player. Not real-time multiplay, but no worries about ports, firewalls, and the stack.
Yep, you and I definitely have different opinions of the ease of doing such a game
One could just have a click indicator for where the desired target on the figure would be - having an indicator moving around a figure might cause all kinds of problems about users feeling like they couldn't hit the right point on a figure. However, for a realistic strike, there would also need to be modeling of precisely what points of the striking surface would be contacting the target, the angles and surfaces on the target that might dissipate or concentrate the energy of the strike,
Also, different strikers have different levels of power in their strikes, varying angles of strike (e.g., Yoda vs. Wicket), and varying abilities to change the angle of the strike (e.g. Wicket vs. farm-boy Skywalker vs. Darth Maul vs. Starter Kenobi). Again, these would need to be modeled.
Again, the angle of incidence of the projectile, the mass and geometry of the projectile, its aerodynamics, and other such factors would need to be modeled to help differentiate a small missile launcher from a Force blast.
Actually, by my reckoning, there'd need to be many more computations than that. At a bare minimum, you'd need to represent the following for realistic gameplay:
1) The velocity of the strike
2) The angle at which the incoming figure is arriving in three dimensions
3) The rotational momentum of the incoming figure
4) The mass of the incoming figure and its distribution throughout the figure, along with that figure's geometry
5) The orientation of the receiving figure and its attendant profile with respect to the incoming figure (i.e., the probability it could be hit at a given spot)
6) The mass, geometry, and orientations of any figures with which a figure might be in formation.
Launcher attacks would have similar considerations.
Also, you're reckoning movement based on "squares", even though Attacktix isn't based on square or hex movement. That could make people feel like the game is "off", and it certainly would reduce its complexity considerably. At the very least, it would make it difficult to treat all sculpts differently (e.g., Beast will occupy more real estate than a Mini-Con).
It's not hard to make an engine, that's true. However, for it to accurately simulate an actual Attacktix game...that's something else
The problems I enumerate are certainly not insurmountable - professional game designers surmount them with ease, nowadays. However, they're professionals with the attendant time, training, and support to program such a thing - I'd be concerned that our amateur attempts would end up being just that. It's the 3D, kinetic aspects of this game that make it much harder to model than something like Star Wars miniatures - the physics end up being a lot more complex than in the simple combat simulators it sounds like you and I have programmed.
Well, that'd limit you to 10 figures, tops, given that's the approximate limit on shop items. However, it'd be an interesting way to choose figs, that's for sure