81–90 of 170 posts
Earlier quoted context omitted.
As opposed to an 'o game', which is output only, i.e., just a movie.
Or an 'i game', a game that takes only input and provides no feedback. Like waving your hands in the air and pretending you are playing a VR game; or a Karate kata.
Earlier quoted context omitted.
Once when I was working at a game publisher I thought it would be fun to help an indie game project anonymously. At that point I had designed or produced many games, but the job was going through a dull phase. So I picked out a project on sourceforge (this was a long time ago) and offered to help out. Pretty much all they were doing was recreating all the UI widgets in any OS (buttons, pull down menus, etc.). Everyth…
On the one hand that's sort of mindblowing, on the other not that surprising, and reading the original article just underscores my (thankfully brief) experience of working in a large enterprise: the one thing you can absolutely trust is that when it comes to product development a senior enterprise developer or architect will always focus on the wrong problem. I find their approach to software development in general,…
You need to have a goal and adapt your software writing to that goal. If your goal is to make the next Flappy Bird and pull in $100K revenue per day, you probably don't want to be spending your time figuring out why "the time between ticks increased to 20-30 ms and then it dropped again." Your time would be better spent slapping together version 0.01 of about 40 games and shipping them, hoping one of them takes off.
Needing to optimize and rearchitect something is a problem you have after you get U$ER$.
Earlier quoted context omitted.
Yeah, I'm at the part where he's implementing lag compensation before even building a fun prototype for the game. Seems very backwards. (This problem may very well be addressed later in the post, still working my way through it. It's an interesting article.)
He also says that Carmack re-wrote the quake network engine which is true, but links to and focuses on Valve's lag-compensation which went far further than what quakeworld did. The quake re-write was Quakeworld[1], which didn't have valve's lag compensation for shooting. The crucial thing that quakeworld did was de-couple client and server for movement. The result was that when you fired you would see your shot local…
Something lots of people in the tech community get really hung up on is focusing on tech and technique rather than what the technology is doing for the user. There are writeups on here fairly frequently that talk about successful companies being successful despite their product being built on barrels of spaghetti code. This is because those companies are focusing on accomplishing something for the user, not trying to…
> ...anything else is distraction Is it? I was under the impression that many game shops do several releases based on the same code. It seems it would be valuable to limit the incremental cost for extra episodes, DLC, Madden YYYY+1, etc.
This is pretty likely to share code.
> Madden YYYY+1
This may or may not.
Just to keep up with the Joneses, so to speak, may require adopting new graphical techniques and occasionally rewriting your pipeline to better align with the current generation of graphics hardware and APIs. A triple-A studio isn't likely to target the Xbox One or PS4 with an aging d3d9 forward renderer - for one thing, d3d9 isn't even an option for either, and for two it'd look quite dated. Oh sure, you can reuse a little vector math when overhauling to, say, a PBR-oriented d3d11 hdr-supporting deferred renderer, but you've rewritten a huge amount - and what hasn't been rewritten may be a bit awkward and ill-fitting.
And of course graphics APIs aren't the only thing changing between console generations. Even the basics like multithreading primitives, basic I/O, gamepad input, user profiles, etc. change wildly. You can build abstractions, but those don't always age well on either the design or the performance front.
It's also not uncommon to prototype e.g. your core gameplay loop in an entirely different engine (likely something lightweight that focuses on speed of iteration) than your actual implementation of the idea as a final game (which may focus more on efficiency, high fidelity graphics and animation, etc.) The internal overhauls of a long lived MMORPG may also leave the codebase bearing little resemblance to the earliest released versions. Ports - especially if outsourced - are often developed as very divergent forks, rather than variations on the same shared codebase. So in a very real sense you may have multiple unrelated or barely related sets of code for the same release.
If you're less successful, you may be able to stay in the game by reusing your existing codebases more to be a bit more efficient. If you're even less successful, the most efficiently reused codebase in the world won't keep you in business.
Sad but true.
Earlier quoted context omitted.
Once when I was working at a game publisher I thought it would be fun to help an indie game project anonymously. At that point I had designed or produced many games, but the job was going through a dull phase. So I picked out a project on sourceforge (this was a long time ago) and offered to help out. Pretty much all they were doing was recreating all the UI widgets in any OS (buttons, pull down menus, etc.). Everyth…
On the one hand that's sort of mindblowing, on the other not that surprising, and reading the original article just underscores my (thankfully brief) experience of working in a large enterprise: the one thing you can absolutely trust is that when it comes to product development a senior enterprise developer or architect will always focus on the wrong problem. I find their approach to software development in general,…
This seems like a case study in premature optimization
Not really. If you're doing a multiplayer shooter, solving the lag problem is basic. Otherwise the thing is too annoying to play. The question is whether you can come up with something more fun than a top-down multiplayer shooter. It's not like there's a shortage of those. For some reason, the latest fad in indy browser games seems to be parking games. Truck parking. Tank parking. Airplane parking. Crane parking. Man…
Please, don't use the term 'an io game'. It really makes no sense.
I'm the guy that made Agar.io, and I personally hate that term, but I don't think we'll ever win the war of getting people to stop calling those browser MMO games "io games"
Earlier quoted context omitted.
> how could you justify not resolving it prior to release? I'm not objecting to him addressing the lag, I'm objecting to him resolving it first . Until you've built something people want to play, addressing lag (and similar tertiary problems) is solving a hypothetical problem for a hypothetical player. And it may well be wasted effort, if you never nail the core product. But if you approach it from the other directio…
I don't think you can separate the core mechanic from the lag. If it's a multiplayer game where the internet is the medium of communication, then any gameplay mechanic has to be tolerant of the lag. If it isn't, you don't have a game. Dealing with the lag is part of the MVP, not polish.
Earlier quoted context omitted.
I'm the guy that made Agar.io, and I personally hate that term, but I don't think we'll ever win the war of getting people to stop calling those browser MMO games "io games"
Have you written any development posts like this? I'm sure everyone on HN would be really interested to hear your thoughts about this post, and how it compares to the development of agar.io. Did you sort of just get lucky with the game mechanic, or was it something that you put a lot of thought into? Was agar.io originally supposed to be a different game?
I just make what feels fun. For a perspective on development cycle: the initial version of Agar.io took 1 week, while Diep.io took less than a month too (it was released a lot more polished than agar.io). Of course, they continued receiving updates for months, but the initial version was already fun.
While the initial version for both games was coded fairly quick, there were months of thinking about them before I even started coding, and from beginning of development to first version the gameplay plans didn't change.