Ver 0.2 Updates
-More competent AI
-Changed Machine Gun icon
-Changed Machine Gun SFX
-Updated Dual Turret
-Updated stats shown
-New Turrets: Chain, Sniper
-New Damage System
---Damage is final, Health changes depending on chassis. "defense" variable removed
---Damage equalized for weapons
-Fixed some bugs
---AIs bumping into walls (hopefully)
---AIs causing traffic jams
-New bugs
---Parts sometimes do not match visually
---Lag may cause loss of bowel control
---Other stuff, maybe
On the list for 0.3:
-New turf icons (the grid sucks now)
-New icons for main cannon
-Tri Chassis
-Hover Chassis
-Tower Chassis
-Spike Chassis
-Shotgun Turret
-Laser Turret
-New maps: (1 with 6v6,the other 6 teams, 2 on each)
-Scores
-Ammo
-Pickup items (repair/refill ammo)
-Music
-And much much more!
Let me know what you guys and gals think. =)
Jul 27 2011, 11:20 am
|
|
Yusuke13
 |
Absolutely gorgeous
|
Thanks, it means a lot to me. This is probably the first project that I've actually had fun playing and making.
| |
That's what it's all about :D
It shows in your work and your blog posts how passionate you are about this project. | |
It's looking great! Just two things:
1. There's no link to it under the "My games" title on the left side of your blog. 2. Do all projectiles have limited ranges? I'll often see projectiles flying across my screen and I can't see the person who's shooting. Maybe it's because the view size is a little small, but the distance I prefer to be away from enemies is about the same as the view radius. | |
1. I know, it's weird, earlier I only had "My Games" there so I figured I'd go ahead and add "My Demos" in the control panel. For some reason though, after adding it, "My Demos" still doesn't appear. I don't want to make a game hub for it because it's really just a demo for the time being. I'll see if I can figure out what's going on.
2. Only the flames have limited range, the rest of the weapons go on until they hit something. Chances are they're not shooting at you since they only fire if they're targeting you, which is based off their own view range. | |
Whoop, nevermind, I fixed it. I had it set to unlisted by accident.
| |
i wrote a review on your game eariler.
its good game edit: ais with sniper turret are op and so is using sniper yourself | |
You know what's fun, is to have projectiles move multiple times per tick. It would make it a completely different game, though.
@Forum_account's #2: It'd be cool if the view size was increased a lot. Right now it's feeling very claustrophobic, but that may just be because I can only play this on my laptop due to javascript not working on my good computer. | |
Why multiple times per tick? You wouldn't be able to see it since what you seen is only drawn once per tick.
| |
Chances are they're not shooting at you since they only fire if they're targeting you, which is based off their own view range. Yeah, I figured it was just stray shots from another fight. Though knowing this makes it easy to exploit AI - just have a group of players sit in a corner and fire machine guns off into the distance. | |
That's the point, and that's why it'd make it a completely different game. It allows for extremely fast projectiles, but still with precise collision detection. Theoretically, you could move a projectile 1 pixel 8 times per tick to have a pixel-perfect collision between bounding boxes, while the projectile moves visually 8 pixels per tick.
| |
Oh yes, I remember Darkness had that issue, where the projectiles would sometimes cut corners since they never technically moved inside the bounding box of said corner.
You'd have to talk to Forum_Account about that, but seeing as projectiles only use set_pos() to determine their movement then, yes, they should me able to do multiple check per tick. Though I would assume it'd become much slower. Let me try it out and I'll get back to you. | |
Kaiochao wrote:
That's the point, and that's why it'd make it a completely different game. It allows for extremely fast projectiles, but still with precise collision detection. Theoretically, you could move a projectile 1 pixel 8 times per tick to have a pixel-perfect collision between bounding boxes, while the projectile moves visually 8 pixels per tick. And you can support 87.5% fewer mobs. Collisions will be correct (correct enough* at least) as long as the distance of each step is less than the sum of the width of the object and the width of each obstacle (the width in the direction of the projectile's motion). You'll be able to get some cases where bullets can "skip" over the corner of a tank's bounding box, but most of the object's are big enough that this shouldn't be much of an issue. * Think about what "correct collisions" means for a while, then think about how "incorrect" it is because the mob's movements are being handled sequentially, not simultaneously. | |
Yeah, it's super duper slow. I mean, even without it, the mob count regulary hits 100 with all the chaingun bullets and other projectiles, sure they use a simpler code, but they still take time to process. The chaingun used to fire much more quickly but I toned it down due to the increased lag. Making them do more work per tick is essentially making that many more projectiles. Over 1000 in most cases.
| |
If you had very small bullets or very small tanks it might be worth considering. As it is now, tanks are big enough that projectiles will only be able to skip over the corner of the tank. It's not like a direct hit will go through the tank. It's not precise but it's not flawed (you were using imprecise bounding boxes to begin with).
If this ever does become an issue, you won't need to handle moves one pixel at a time. Unless you have 1x1 bullets and 1x1 tanks it'd be overkill. | |
Though, you might be able to do a different check...
For example, in some cases the px of a moving object will appear inside the bounding box of an object, but the py wont, which means that although they do cross paths on the x plane they are separate on the y plane, so there's no collision. If both the px and the py end up within the box then it does in fact collide. The idea is that we also want to check the path between the starting point and the finishing point of the pixel move. There is a way to check for that without checking every single pixel, but it involves trigonometry as you'd have to make a non-rectangular bounding box. You'd basically have to be checking angles to see if it hits, and this, and that, and honestly it's a metric shit-ton of work for an easily overlooked problem. | |
Might it relate to cross products as shown in Hobnob's 3rd vector demo?
http://www.byond.com/members/ DreamMakers?command=view_post&post=77879 Scroll down to "Demo 3 - Spacewar!" His space ships are not rectangular. The red one is an isosceles trapezoid and the blue is an isosceles triangle. Because all the vertices are vectors pointing to the next vertex clockwise and vectors can be rotated, his ships have much more pixel-perfect collision detection at any angle. I think I've mentioned somewhere jokingly but partly seriously (or maybe not, could have been dreaming) that Forum_account should totally take the time to implement some kind of CrossProduct vector math to have non-rectangular, fully-rotational polygon collision. | |
Oh wow, that's actually really cool. With that infused with pixel_movement we'd basically be able to use polygonal collision boxes. I'm concerned as to how the math is going to play out though. With the massive number of calls in pixel_movement I wouldn't be surprised if it caught some lad from this.
Still, if it can be implemented with good result then I'll be fucking ecstatic. It's awesome =P | |
Oh, I remember now. I was going to bring it up in the comments of your first blog post about Tanx. I decided against it for some reason.
I don't know how much slower it would make things. I'm not sure how polygons would collide with old-style bounding boxes, if at all. The boxes would have to be vertexized to collide properly, I assume. From what I understand about Hobnob's Spacewar!, he caches the collision polygon for every possible angle of rotation at start-up. I assume it's those kinds of things that are loaded on world start-up that gave rise to loading bars. I'm sure many more optimizations would have to be made for it to work with a decent result. It's small things like these that wish I wasn't too lazy to learn a different programming language. To me, it just seems that all other programming languages eat this stuff for breakfast. Calculations finish so fast in the games I play (a couple first person shooters and sometimes Minecraft) that the only noticeable choppiness in performance comes from turning up the graphics too much. And that is why every time I play a non-BYOND game I ask myself, "Why, BYOND!?" | |