• Projects

  • Rabbits vs Marblez- WIP Tower Defense Game Demo for feedback

Sounds like you're getting a lot done! Great Job!

Thanks! Hopefully I didnt lose all today's progress with a editor crash.

@jbskaggs said:

Sounds like you're getting a lot done! Great Job!

Thanks! Hopefully I didnt lose all today's progress with a editor crash.

Nooooooooooooo!

"Fezzik, that is the sound of ultimate suffering."

@OpinionatedGamer said:

@jbskaggs said:

Sounds like you're getting a lot done! Great Job!

Thanks! Hopefully I didnt lose all today's progress with a editor crash.

Nooooooooooooo!

"Fezzik, that is the sound of ultimate suffering."

Thankfully the users on here helped me figure it out and now I am back on board again. :)

Update pic: Was able to overcome yesterday's fiasco and set up the gui on 3D version today.

Do you have their shots fired along a 2d plane straight toward the enemy's last known position or could they potentially shoot down too? Like from a tower or something.

right now firing on 2d plane. it functions the same as the 2d ver though written in 3d.

Error 404 on that link

Hmmm now the html5 buttons on export do not respond. Meh.

What I have accomplished so far -even if my html5 export doesnt run properly.

I now have six concurrent waves running, gold updates, lives updates, pretty much everything from the game map but the venom shooting jelly marble.

One thing different from 2d- as all marbles are created in Godot as meshspheres and material added via script. I dont know if that is a causing my game's low performance.

Issues: performance is nowhere near as smooth or fast as the 2d version. Lots tweaks needed for collisions. The rabbit's rotation is slow and jerky.

So I wonder now how I can improve the performance of the game. I am pleased and frustrated at same time at these problems.

@jbskaggs said: https://jbskaggs.itch.io/html5-3d-rabbits-vs-marbles-prototype-phase?secret=hjh3NQdwwwXaawT52pasziFKw

I repaired the bug so html5 should work now.

Now I need to optimize my game for speed and then I can start building levels.

Good night.

Wooo! Beat all levels! A promising start. Needed to right click on a lot of things for some reason tho. I personally would say don't worry too much about optimizing for html5 unless it's your intended platform. Those browser tabs don't get all that much computing power.

@Erich_L said:

@jbskaggs said: https://jbskaggs.itch.io/html5-3d-rabbits-vs-marbles-prototype-phase?secret=hjh3NQdwwwXaawT52pasziFKw

I repaired the bug so html5 should work now.

Now I need to optimize my game for speed and then I can start building levels.

Good night.

Wooo! Beat all levels! A promising start. Needed to right click on a lot of things for some reason tho. I personally would say don't worry too much about optimizing for html5 unless it's your intended platform. Those browser tabs don't get all that much computing power.

Thanks! Unfortunately its just as slow in the win exe file too.

@jbskaggs Ah, let me amend my previous statement then: A somewhat promising start! =) I wonder if you could speed things up by letting the rabbits “lock on” to a target instead of letting them scan for the closest target all the time. Or you might have done that already.

I hadnt thought of that, sounds good, but Im not sure how much it would help- you would still need to check every half minute or so which is closer.

Does the size of the models matter for speed? I am having to scale some models down to like 0.02 xyz.

Isn't there some sort of profiler that tells you what is using the most processing power in Godot? I feel like there is but I've never used it, so can't tell u where it is.

@jbskaggs said: I hadnt thought of that, sounds good, but Im not sure how much it would help- you would still need to check every half minute or so which is closer.

Perhaps have a queuing system so there's a target acquisition step on every frame but only one unit at a time? That might work to keep the average FPS up and avoid horrible frametime spikes.

@Megalomaniak said:

@jbskaggs said: I hadnt thought of that, sounds good, but Im not sure how much it would help- you would still need to check every half minute or so which is closer.

Perhaps have a queuing system so there's a target acquisition step on every frame but only one unit at a time? That might work to keep the average FPS up and avoid horrible frametime spikes.

current 1. all enemies go in an array. 2. shooters target enemies when they first appear and check all members in array for closest enemy 3. enemy removed at destruction

so the suggested steps would be:

  1. if enemies are within range. -ignoring all other enemies.
  2. put those enemies in array
  3. target closest enemy in array
  4. remove any enemies that are destroyed or leave range from the array

??