Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Airmash – Multiplayer Missile Warfare HTML5 Game

airma.sh

Post reply on HN
Print view View original

161–170 of 316 posts

Re: Show HN: Airmash – Multiplayer Missile Warfare HTML5 Game

#162

Post by chickenfries »

rev_bird wrote: post #139
chickenfries wrote: post #83

Earlier quoted context omitted.

I mean this is nice but it's really not a lesson for web developers. The fact that this is 2.8mb doesn't really teach a web developer any lessons, unless you think that large website payloads exist because developers are literally too lazy or don't know how asset optimization works. Instead, having worked in web development, I know that website payload size is often driven by having to include vendored javascript for…

>unless you think that large website payloads exist because developers are literally too lazy or don't know how asset optimization works. For what it's worth, I do think this. It's easy to just drag another JS library into your code without thinking of how long it's going to take to load.

I don't know what to tell you if you're convinced that's the problem. I know and work with many web developers who do care about performance. I follow the blogs of many web developers who write about performance.

I don't doubt that there are junior web developers who don't know much better. But I don't really meet anyone who says that they just don't care about performance.

Re: Show HN: Airmash – Multiplayer Missile Warfare HTML5 Game

#165

Post by spydum »

b0rsuk wrote: post #156

Gameplay feedback: Mohawk (helicopter) and Prowler (stealthy) don't seem worth it. The helicopter dies from a single stray rocket, random spam and attacks from behind. Alt+arrow for strafe worked in DooM because field of view always pointed away from the player. Here, strafing is hard to get used to. Since there are already 2 keys for ability, why not make one of them "strafe left" and the other "strafe right" ? Also…

while I agree about the prowler, i was holding #1 for a solid hour or two in the mohawk. It takes some strategy (mostly about orienting yourself north frequently), but it still is useful. I agree, if POV could be toggled to follow, it would be really solid. also, leveling up defense makes it suck less.

Re: Show HN: Airmash – Multiplayer Missile Warfare HTML5 Game

#166

Post by wesamco »

wesamco wrote: post #154

dammit this is addictive, even to me! please add a "auto lock" feature, that you can find in military aircrafts since the 80s, like a "god mode".

damn you too for making me waste more than half an hour! ;) I actually don't play video games.

Re: Show HN: Airmash – Multiplayer Missile Warfare HTML5 Game

#169

Post by debaserab2 »

chickenfries wrote: post #162
rev_bird wrote: post #139

Earlier quoted context omitted.

>unless you think that large website payloads exist because developers are literally too lazy or don't know how asset optimization works. For what it's worth, I do think this. It's easy to just drag another JS library into your code without thinking of how long it's going to take to load.

I don't know what to tell you if you're convinced that's the problem. I know and work with many web developers who do care about performance. I follow the blogs of many web developers who write about performance. I don't doubt that there are junior web developers who don't know much better. But I don't really meet anyone who says that they just don't care about performance.

Caring about performance means weighing the decision carefully when choosing vendor libraries that fill up your payload. You can consciously care about performance but still be negligent to the things that affect it.

I see competent devs reach for libraries all the time when a simple solution already exists within the language. It's easy to feel like you're doing the right thing by not reinventing the wheel.

Areas I see this happening a lot in are anything dealing with file systems, HTTP request/responses, database connections, DOM/string manipulation/parsing/validation. The common theme among all these things is usually a lack of understanding of what the library/package does well enough to implement the specific use case needed.

Post reply on HN