[WIP] Archon II - Adept

[hardwarebob]

You have to delete that second version of "mouse_event" because it overwrites the first one.

Thanks for the assistance , yes, that would explain my issues with it! I now have the main part of the valid movement path highlight and not allowing illegal moves working. A few more tweaks for some more specific cases.

The majority of the rules are UI are in place now, another major part of the battleboard to do with randomly generating terrain and implementing the effect each has on movement and projectiles. Once these are in place, I can start working on some more specifics of each gamePiece type in battle.

So yes, getting close, but all of these little bits here and there I can see taking a bit to get sorted!

After all this is sorted, I will also want to revisit the way I have coded certain things, but for now I will leave it as is and just continue with the functionality, otherwise I am continuously refactoring and not progressing!

Thanks for the update with the online documentation, I will have to reference this when investigating topics.

[hardwarebob]

Hi Ivan,

I have taken another look at the implementation of the battle board and what needs to occur here.
1. elements placed on battle board which have different effects on movement and projectiles
Water - slows objects
Air - deflects objects
Earth - stops objects
Fire - causes damage
2. different characteristics for projectiles for different game pieces

I was reading up on your tutorials with Box 2d and this looks like the way to go (these look really great by the way! ). In particular I liked the feel of the movement in the physics2.lua code.

I will be looking at getting this area of the game rewritten for this, including the collision model (which I knew had to be updated). If you have any hints for this approach, please let me know!

[Ivan]

Hi. I think that Box2D might be overkill in this particular case but it should work especially if you don't want to roll out your own collision system.

particular I liked the feel of the movement in the physics2.lua code.

Since Box2D is a physics library, one of the trickiest things is achieving super-precise movement (think oldschool 2D games like Mario). It's a bit easier with overhead games (like Archon and Zelda), but you'll have to tweak the body's properties A LOT and it probably still won't feel 'perfect'. For example, bodies' lineardamping usually has to be high (to hide the effects of inertia) and its shapes have to be pretty small. Otherwise the controls would feel floaty like in the tutorial.
Other than that, you can achieve some pretty sweet effects using Box2D.

The other route is to make your own collision system - this way you can design the player controls anyway you like. I wrote a super-simple collision lib a while ago which might give you some inspiration. The basic technique is: 1.test if two shapes intersect 2.find the shortest 'separation' vector, 3.move one of the shapes so they are no longer intersecting and 4.adjust the velocities of both shapes. Turns out this method works fairly well as long as you don't have stacks of objects piled on top of each other.

[hardwarebob]

I wrote a super-simple collision lib a while ago

Yes, I had been eyeing off your fizz library. I might take a look at this and see how it goes. I will play around with it in a separate piece of code to get the hang of it and go from there.

I think that Box2D might be overkill in this particular case

Yes, I was suspicious of this, it does look quite extensive! I might play around with it at a later stage.

you can achieve some pretty sweet effects using Box2D

Yes, I liked the circle drop in tutorial 1!

[hardwarebob]

I have spent some more time on the weekend and have managed to integrate your fizz library into the gameboard.

Thanks to your example (even though you don't think it's very good ) I was able to get it figured out. It's a cool little example and also has a good feel around the movement. Not much code required in your exmple.lua file either!

You were certainly correct in that using Box2d would have been overkill as your lib has what I require. I would like to clean up my integration with the lib a bit, but it's not too bad for now.

The main integration points are BattleBoardG.redraw, BattleBoardG.checkPlayerMovement, GamePieceG.setProjectile, GamePieceG.redraw, ProjectileG:setShape, ProjectileG.redraw.

I have implemented my projectiles with a kinematics object, the gamepiece movement using the dynamic object and the random element tiles as statics.

I did modify the fizz.lua lib a bit (included on bitbucket) with the way I used the kinematics object, so I modified update() fn so that the kinematics now resolves projectile collisions with statics.

[Ivan]

Hey, thanks for trying the lib. It's still not very polished but it works OK for old-school types of games.

You were certainly correct in that using Box2d would have been overkill as your lib has what I require. I would like to clean up my integration with the lib a bit, but it's not too bad for now.

I tested the version you had on BitBucket and it plays fine so far, so cheers.

I did modify the fizz.lua lib a bit (included on bitbucket) with the way I used the kinematics object, so I modified update() fn so that the kinematics now resolves projectile collisions with statics.

Yep, that should work. Since there's no gravity in Archon, you could have used dynamic objects for the bullets as well.

Code: Select all

-- returns shape index and its list
function findShape(s)
  local t = s.list
  -- 'if statement' added by BH, error due to collision, need to figure out why this is occurring
  if t then

This may happen when you delete a shape during the onCollide callback (Box2D has the same limitation). It's a slightly simpler problem in Fizz - objects are iterated from a table during the collision, so when you destroy a shape it throws off the indexes of the table. One simple solution is to iterate the tables in reverse (for i = #objects, 1, -1) but that won't work if you delete a shape that is not involved in the collision (a shape whose index is < i). A better solution might be to store the shapes as a 'linked list' so that they don't have indexes at all.
Another limitation of Fizz is that as the number of moving dynamic objects increases the number of collision checks grows exponentially. There's no workaround to this except keeping your dynamics low or writing some form of grouping/filtering system or perhaps even partitioning/spatial hashing. I might try this since I'm using Fizz for a prototype game that I can show you if you'd like.

[hardwarebob]

Hey Ivan,

Thanks for the tips in your last post. Just thought I had better post an update, since I had gone quiet again!

I have been so flat out with work that I haven't had time to commit to this lately.

I will get back into this again, but not sure when that will be for now, hopefully soon!

As a break from the coding, I had a look around for ideas for graphics on tiles, to see how things might look. I have also gotten one of my friends who draws to come up with some ideas for the characters, it will be interesting to see what he comes up with.

[Ivan]

Sounds cool.
Will keep an eye out on your BitBucket repo.

[hardwarebob]

OK, a few more updates done.

Movement paths now correct for game pieces on game board, rules are as follows:
adepts can move anywhere (costs to change elements)
summoned pieces can go anywhere within adepts element
once you attempt to move a summoned piece the next turn, they can't move past other units and only within their element, except, they can move to a new element if it is an adjacent cell.

I made use of a recursive function inside gameboard to assist with this (checkBlockedPaths), it seems to work correctly.

Movement paths now animated using alpha values, so it is easy to see valid moves (only applies to summoned units, as adepts can move anywhere). Got this working thanks to your animation and timer tutorials!

To summon a unit, select an adept, click the same adept again, the word 'summon' appears, hit space-bar to select 'summon' spell (you can use 'O' and 'P' to scroll spells), then select an 'icon' (summonable gamepiece) from the characters displayed. The valid game board tiles will flash.

Not sure if you have figured that part out before!

Oh I forgot to mention the tile textures that I found at the following website: http://darkwood67.deviantart.com/gallery/11280947. Not sure if I will keep these, but they are a lot better on the eyes than my previous place holders! I found the website through this forum: http://opengameart.org/content/dirty-tiles

[Ivan]

Hey, nice work! I love the look of the new tiles, it makes the game look WAY better.

To summon a unit, select an adept, click the same adept again, the word 'summon' appears, hit space-bar to select 'summon' spell (you can use 'O' and 'P' to scroll spells), then select an 'icon' (summonable gamepiece) from the characters displayed. The valid game board tiles will flash.

Pretty cool effect, although I have a minor suggestion - why not show the summon menu as soon as you select a unit, I think this would make the UI a lot easier to use.

If you're looking for animated unit sprites, I would recommend the Civ 3 Mods forum:
http://forums.civfanatics.com/forumdisplay.php?f=60
They have a some nice looking unit sprites (animated in 8 directions) that I've used in a few prototypes.
Unfortunately, they're all in PCX format so you have to manually convert those to PNG tilesheets.
There's a couple of free tools for this: Flc2Gif and Avi4Bmp but it's still a bit of a hassle.

But anyways, the game looks great so far!