I love the rainbow vomit. If the game is all about that it will rock.

655 needs a gold coin by it to show that this is the upgrade cost to get to lvl 2, likewise the unit purchase price at the top.

The Knight balls - this is where my patience ran out lol, I will add the swishes (and oil, and fireballs effects) for the next version

Boiling oil should work, even on the bottom rank of arches - even though it is less useful there. It will just hit one row of passing enemies.

Playtesting is the best way I know to polish a game - so thanks for the feedback!

A couple of days after reading the AS3 Avoider Game Tutorial I put my new found AS3 skills into action in this Tower Defence game.

Play -> Slice: Fortress Defence

I used Curvy 3D 2.0 to draw all graphics.



The hardest part was getting a good difficulty curve - at the moment around level 60 it feels like the game suddenly starts pouring on extra punishment. There are a few exponential curves governing enemy strength and cash rewards, but in the end I guess it just comes down to loads of playtesting to get it right!

I feel there are lots of graphical effects and a couple of UI improvements I could make - perhaps for a sequel...

AS3 & FlashDevelop were a pleasure to use & Free :D I have long put off Flash dev just because I didn't want to buy the IDE and endless upgrades when I would barely use them, most of a game is AS anyway. I only discovered after learning AS3 that it is the same as JavaScript - so apparently I have just learnt the JavaScript syntax accidentally

Art is very sweet, now please change the font

Changed it to La Bamba (The font above was a placeholder)

Finished Game:
Slice: Fortress Defence

[AS3 + FlashDevelop + Curvy3D]

My first AS3 + FlashDevelop + Curvy3D project - a Fortress Defence Game. Art is all sketched based modelling from Curvy 3D

Thanks for the link - I did do some searching back and forth to find the best place for it - It's 3D trying to do the job of pixel art Will huddle up with the the 3D guys in future

I was doing some class-like things and using several LuaBind created classes that mirrored my own classes. But a lack of decent programming environment (for me at the time) hurt the most. I think I have been spoiled by MSVC and Visual Assist - makes coding so much easier!

Thanks for the link fix! You can feel the power in the bounding horse, and the footfalls of the walk seem to give a bit of a kick to the head.

I don't want to make the motion too complicated on the horses back so I can easily sit a rider and their aim/shoot/sword/lance anims without having to worry about the phase of the horse's gait. Perhaps these horses are specially trained to allow their riders a clear shot

I dare say the gallop will still be 100x better than the death anim... there is no way I am putting a ragdoll physics horse into this game!

Mogget - Much as I liked "Level Up" there was no horsey reference in that link.

ArchMonitor - Saddles are a good plan. I'm going to make a couple of variants of the horse and rider, mainly to add a desert bandit, but also camels - which I hope move in a similar way.

With all the horse gaits out there I am hoping to make do with an idle, a walk, and a gallop, then do some procedural animation on top of the gait to make them bank into turns and bend round corners a bit.

Here is a

I got bored with how slow lo-poly modelling gets - so I slammed together some volumetrics and crunched it to lo-poly in MeshLab, seems to work fine - even for animation.

He looks like a shape shifter - how about being a shape-swapper. Press a key to swap either top half or bottom half of body with an enemy. Then make enemies like toad/grasshopper/fly to get swap different abilities with.

I've been making horses, not as tricky as I thought they would be - although I know the anatomy freaks will hate them.

In a turnaround on my normal modelling work-flow I modelled from hi to lo poly on this one rather than carefully handcrafting the polies one by one to make the lo-poly mesh from scratch.

I needed to add a couple of extra polies around the leg joints but other than that the automatic mesh reduction from MeshLab did the job well.

I love seeing comparisons of the same algorithm in different languages (As on Project Euler) so that list is great. It is clear when you sort by code size that languages like Python/Ruby win for that - but with a massive speed penalty.

I am more interested in speed of writing the code than of execution, so code length is a good indicator that these languages are compact - but what would be really interesting would be to know how long the different programs took to write!

For me the fun often starts when the game starts fighting back and is tricky to beat, when it has grown up from a pile of mechanics and a graphics demo into a challenging game.

Then again - I've just added combat to the game and seeing lots of little soldiers being hot down in a haze of blood and bullets is pretty fun too!

I tried writing a game in lua with only render calls delegated to C++, it was fast to get a prototype up but after a point the amount of code got out of control and the debug support was not as easy for me to use.

Now this might be due to lack of experience in Lua - but as I know how to organise 100kloc programs in C++ I decided to move my main gameplay code back to C++ for other projects. Also I didn't get the hang of serialisation in Lua.

I understand trying to mirror all the C++ in Lua and visa versa is unhelpful, and it is best to keep the most of the gameplay on one side.

My main reason to use Lua is so I can release an exe and let other people write scenarios and missions for the game. I am currently thinking I would be better off making a simple data format for this instead of allowing full scripting - as exposing all the gameplay mechanics across the C++/Lua boundary would be too painful + complex for the time I have available.

To follow up on my OP, I took the advice to get a rough prototype up and running as a priority - focusing on a single element of the gameplay. So I have that running now as a game with a simple "make the biggest profit in 5 years from trading" objective.

With this done I am realising all sorts of ways I can improve my original designs: the trade screen map and navigation dynamics, and come up with all kinds of variations I can try on the GUI side too. So I can reaffirm the view that you don't know a design will work until you make it, play it, tweak it, remake it/restart it iteratively, early prototypes are much more important than endless design documents (although having both does not hurt).

Thanks for the tips guys

Thanks, I think I was edging towards reproducing C++ in lua rather than creating a simple and specialised lua environment to help out where my other data structures were lacking.

I will probably go back to using C++ and csv exclusively until I am more advanced with the project and can separate out the scripted parts neatly.

The enum trick looks sensible, I guess a similar thing could work with localised text strings. I could even pre-process the lua file to replace enums and strings with int identifiers as they are loaded in.

I am having battles over Lua again. In my heart I hope it will simplify my codebase and give me a clean way to add mission and story elements to my game - but in my head it is adding endless layers of indirection and complexity to straightforward tasks.

Has anyone who has written both pure c++ games and c++/lua games got experience of which is faster to develop?

In particular I am have a problem with identifiers, in c++ I would use enums for switches, types & ids - is there a simple way to use the same enums in Lua. (I have in mind some nasty #include and #define fakery to reuse the same file as Lua and c++ header... but there might be a better way!)