Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us $3,400 per month for bandwidth bills alone, and since we don't believe in shoving popup ads to our registered users, we try to make the money back through forum registrations.
«46 »
  • Post
  • Reply
Chev
Jul 19, 2010


Switchblade Switcharoo

Ranzear posted:

I could actually make some weird suggestion that, from a pure skillset and resources perspective, procrastination is better than prototyping. It's too easy for temporary solutions to become permanent hobblings. Generalize your work instead: Look at all the concepts you want to make and write the code that enables some small part of as many as possible.
In my professional (technically non-game) software development experience, this isn't a good approach unless you already have tons of experience because you've got no concrete basis for generalizing your work. You don't know what the generalizations are until you actually need to generalize, or you've generalized similar systems before and already know the caveats. What's gonna happen instead is it introduces a lot of unwanted couplings in the code, some of which may actually be hindering you but you won't be able to root out the problematic dependencies before your code is actually functioning. If you build a functional prototype first, it then is a basis on which you can judge what generalizations or optimizations or even cuts work, purely on the criterion of whether it breaks functionality or not, something you cannot accurately judge in a vacuum.

Adbot
ADBOT LOVES YOU

dads friend steve
Dec 24, 2004





Random question from a non-game dev

The new PlayStation is supposed to have something like 5gb/s of io speed through its “pipeline” vs the new Xbox’s 2.4. If you’re making a non-exclusive game that you want to run on both, are you able to actually make good use of that extra speed or do you need to work to the lowest common denominator?

Chev
Jul 19, 2010


Switchblade Switcharoo

In the old days it used to be you could possibly find some strengths inherent to a certain machine that offsets its weaknesses, like if it has more ram and less processing power you can precompute stuff, etc. Fabien Sanglard's series on Another World is a very interesting exploration on how ports could take advantage of specificities of each platform.

Anyway, these days it's more like having graphics settings on a PC game, especially if you're on a middleware engine. You can design the game for the most powerful platform (or even some platonic platform more powerful than all your targets) and tune aspects down for each less powerful version. Like if you're IO limited just throwing away the max mips on each texture is gonna trim your data down significantly, maybe more agressive lod, etc. Obviously this is gonna be profiled and fine tuned for each target platform. One caveat is if your simplifications are gonna directly affect game logic it can be something to watch out for crossplay compatibility.

Aiming for the lowest common denominator's gonna be cheaper though, since you only need the least complex versions of your data.

Triarii
Jun 14, 2003



TooMuchAbstraction posted:

It sounds like you're saying "build the idealized form of the utility you need, that can be adapted to any future requirement." The consensus I'm aware of is the opposite, viz. make the code that solves the problem you have right now, and hopefully on the next project you'll be able to cannibalize the parts from this project that are actually re-usable. The price you pay is that you'll have to rewrite some parts of your code, even in this project, because as the project advanced you realized that the current code didn't meet your current needs. But arguably you'd have to do that anyway with the "ideal" code because correctly anticipating your future needs is borderline impossible. The advantage is that by the time you need to do the rewrite, you have a much better understanding of what your actual needs are, so you'll be able to write code that is much more likely to be correct for the long term.

Put another way, designs never survive contact with reality unaltered. The best way I know of to cope with that is to engage with reality as soon as possible. The longer you spend in ivory-tower land, crafting the perfect jewel, the more likely you are to spend time/resources on stuff you'll never actually use.

Yeah, it's a pet peeve of mine that a lot of programmers I've worked with are in the mindset of "give me a detailed specification of everything The System needs to do, and I will descend into my cave for three months before emerging with it complete and perfect." Then whenever someone wants to try something new that wasn't predicted in the specification (because you can never predict everything you're going to want to do) they get shot down with "no, we can't do that. The System doesn't support it."

Chev
Jul 19, 2010


Switchblade Switcharoo

Especially since the client/user/designer normally won't be able to correctly formulate their needs, only what they think their needs are, so they'll need prototypes and tests to understand which ideas are good or bad ideas. Like the old Ultima Online simulated emergent ecosystem thing that sounded great in pitches and specs but where it turned out the hardware couldn't run it in real time and the players were harvesting resources too fast for the ecosystem to even exist.

Chev fucked around with this message at 22:56 on May 2, 2020

nielsm
Jun 1, 2009




Fallen Rib

A while ago I read some advice to not write reusable code, but rather write replaceable code. If it's easy to rip out any part of the code and replace it with something new, you're also flexible. Also not be afraid of copy-paste for chunks that need partial reuse. Refractor the code later when it's more clear which parts make sense to have shared among modules.

dads friend steve
Dec 24, 2004





nielsm posted:

A while ago I read some advice to not write reusable code, but rather write replaceable code. If it's easy to rip out any part of the code and replace it with something new, you're also flexible. Also not be afraid of copy-paste for chunks that need partial reuse. Refractor the code later when it's more clear which parts make sense to have shared among modules.

I believe that was written by yosposter monocqc

Xarn
Jun 26, 2015


Nap Ghost

tef

Captain Foo
May 11, 2004

we vibin'
we slidin'
we breathin'
we dyin'


Clever Betty

it's tef: https://programmingisterrible.com/p...n-one-thing-and

but mononcqc is also a very good writer

Ranzear
Jul 25, 2013



TooMuchAbstraction posted:

It sounds like you're saying "build the idealized form of the utility you need, that can be adapted to any future requirement."

Nah, the suggestion was more about looking at one's current list of things one might wanna make and figure out what overlap one could write some reusable code for, not even for future application. When one finally gets halfway into one of those ideas and realizes it's kinda poo poo, one can still turn around and repurpose that modular part. It just gets ahead of trying to reuse something not intended to be reused. Still technically procrastinating on most of your projects by avoiding working on any one in particular?

I'm super weird and write netcode first in almost every case, because all of my games are client-server and how one shoves stuff between those dictates almost every data structure. After moving to Rust and basically having a clean sheet, my first major chunks of code have been serialization and barebones netcode just to get most anything off the ground. My fastest way out of a funk is to just write anything, and being non-committal to any particular idea helps. I can agree that this approach might be uncommon.

If it isn't good coding practice, it's at least good coding practice.

Triarii posted:

Yeah, it's a pet peeve of mine that a lot of programmers I've worked with are in the mindset of "give me a detailed specification of everything The System needs to do, and I will descend into my cave for three months before emerging with it complete and perfect." Then whenever someone wants to try something new that wasn't predicted in the specification (because you can never predict everything you're going to want to do) they get shot down with "no, we can't do that. The System doesn't support it."

I have a related but egregious peeve with this which I don't expect is limited to gamedev: On the design side, one might say 'hey, every unit has these six stats'. If the programmer just puts their head down and makes a unit class with six named unsigned integers for those stats, they're a moron. Nobody codes that blindly in reality, I hope, but a lack of coders engaging with the design work and designers not expecting questions or pushback before implementation is a very much experienced nightmare for me. Emphasis on 'expecting' communication back too - if I were purely on design I'd be mondo concerned if anything I gave the programmer was implemented without a word thrown edgewise.

My Hallmark Personalized Version of Hell is the designer wanting content changes scheduled on a weekly basis. Turn that over in your head for how "the week containing Cinco de Mayo" might be handled. How about like Mario levels; Is it 5-1? Or is it 4-4 because this week started last Sunday which was still April, so we're currently scheduling Month 5 holiday content in Week 4-4? By the way there will be a week 5-5 at the end of May. Week 16 of the year? Starting from Jan 1 or the Sunday before again? Which days of 2020 are Week 46, off the top of your head? What week is Easter 2021 in? Now the designer wants stuff to change on the first of the month as well, and that weekly stuff should alter itself to reference the current month at the same time. Take this bat and beat me over the head now, please.

Communication and mutual understanding of both obstacles and goals is hugely important.

nielsm posted:

A while ago I read some advice to not write reusable code, but rather write replaceable code. If it's easy to rip out any part of the code and replace it with something new, you're also flexible. Also not be afraid of copy-paste for chunks that need partial reuse. Refractor the code later when it's more clear which parts make sense to have shared among modules.

I like this a lot. It gets at what I idealize but wasn't phrasing right: Isolation of code.

I said generalizing, but it's 90% to do with isolation. Fast trashy code that is isolated enough to be replaced later is good, it just so happens that if one has a ton of free time and is writing something common to all their backburner projects one probably might as well write it okay-to-good and still well isolated in the first place. Isolation is always good, no matter how perfect the code inside it is perceived to be, because it works as a testing boundary too.

That's my beef with prototyping. I see it as the blind head-down coding spree that produces an exact self-contained solution with no isolation of major structures. I have some horrific monstrosities that came about from 'just prototyping', we're talking 1460 lines of code with nine comments, because everything is just temporary, right? I had to put a prohibition on ever touching that project again, because it's too big to rewrite and too integrated and forgotten to fix. I still play it now and then just to remember the things I learned from it.

On the other hand with all of this: Aphantasia. I am confirmed to be a weirdo, especially in designing with concepts instead of visuals. I also figure Rust is forcing me into a ton of strong isolation patterns too. It will almost automatically kick you in the balls for trying to copy and paste some piece of code into a slightly different place.

Ranzear fucked around with this message at 17:05 on May 3, 2020

PantsBandit
Oct 26, 2007

it is both a monkey and a boombox


edit: oops, clicked on the wrong thread

Tei
Feb 19, 2011



Ranzear posted:

I have a related but egregious peeve with this which I don't expect is limited to gamedev: On the design side, one might say 'hey, every unit has these six stats'. If the programmer just puts their head down and makes a unit class with six named unsigned integers for those stats, they're a moron. Nobody codes that blindly in reality, I hope, but a lack of coders engaging with the design work and designers not expecting questions or pushback before implementation is a very much experienced nightmare for me. Emphasis on 'expecting' communication back too - if I were purely on design I'd be mondo concerned if anything I gave the programmer was implemented without a word thrown edgewise.

Programmers want to make sure what is the something people want to build, because aiming at a moving target generally result in failure, and the life of a programmer is a infinite swamp of failure and error.

Nobody is born with the six sense to know when or where or how to add flexibility to code. Is something you learn from experience. Some people may never learn it.

Communication is a two ways path. If you can't communicate in a understandable way what you want to build, it would be very hard for somebody else to make that dream into a real thing.

Programming is a lot like landing a boing 747 in a road full with traffic, while everyone else in the plane is fighting for the controls: is harder with the autopilot disabled.

Tei fucked around with this message at 15:42 on May 4, 2020

Ranzear
Jul 25, 2013



Maybe you thought I was a designer making that statement, but I'm putting fellow programmers on blast there. Instead of listening to the designer who very exactly said 'land this 747 in Chicago', you could land at the airport nearest Chicago that supports heavy aircraft? I'm just spitballing here, but I fully expect the programmer to know capability better than the designer and take some responsibility for it.

And good communication is making it clear to the designer that one should only land a 747 at an airport. I'm sure they'll get the idea.

One doesn't get to declare all provided design will be inadequate and then hide behind the inadequacy of design for why their code can't accommodate at least some changes in the plan. That's just being a dick and I hope mine and Triarii's peeve examples don't actually exist.

Ranzear fucked around with this message at 16:33 on May 4, 2020

Tricky Ed
Aug 18, 2010

It is important to avoid confusion. This is the one that's okay to lick.




Ramrod XTreme

As a designer with a little bit of programming education, I try to design for extendability and flexibility, but often that's at the expense of usability or performance if no one checks me. The times I've gotten exactly the system I put on paper have generally had worse outcomes than the times the programmers and I worked together to figure out what I actually meant.

That doesn't mean I don't spend a lot of time thinking through my system design first, but we have fundamentally different thought processes and collaboration gets us to a better end result. Usually.

Tei
Feb 19, 2011



Ranzear posted:

Maybe you thought I was a designer making that statement, but I'm putting fellow programmers on blast there. Instead of listening to the designer who very exactly said 'land this 747 in Chicago', you could land at the airport nearest Chicago that supports heavy aircraft? I'm just spitballing here, but I fully expect the programmer to know capability better than the designer and take some responsibility for it.

Programmers with a more square shape head do exist. But then you learn their strenghs and weakness and play their strengths. Is not that communication is about? learning everyone super powers and super weakness. Don't send superman to mine kriptonite.

TooMuchAbstraction
Oct 14, 2012

Hubris

Fun Shoe

Ranzear is quite reasonably expecting developers to have some domain experience and to be able to make basic judgement calls themselves. Nobody's saying "the developer must be a subject matter expert." But at minimum the developer should know the limits of their knowledge and be able to ask "Are we certain that we will only need these six stats in the future?" or "What does it mean to land an airplane?"

In industry work in my experience, the way this would go would be something like: customer delivers requirements to the program manager. Program manager, tech lead (/architect/senior dev), and customer work together to hammer out the requirements, propose easier-to-implement alternatives, and try to get everything nailed down in terms of what the customer actually wants. Tech lead converts the requirements to a design, and the design into work items (tickets, deliverables, whatever you want to call them) which then get handed out to individual devs to implement. The program manager keeps tabs on development fairly directly (i.e. interacting with individual devs), and provides clarifications as they are needed.

I don't know how it works in industry gamedev. I'm guessing it's usually more informal.

Ranzear
Jul 25, 2013



It's especially true on smaller teams where one is likely to take ownership of an entire system. Again hoping these people don't exist, but I figure that 'blind' coding tendency could come from school environments, where every problem presented has an obvious solution and no complications. Treating gamedev work like homework is never gonna cut it.

Hell, I find myself questioning my own design when it involves implementing a bidirectional map for a full graph of distances between objects instead of just putting them on a 2D coordinate, but I want a logical distance between those objects to fit better with moving towards or away from one-another in a turn-based system. I'm gonna keep trying to think of a way to cluster them or something, but the actual memory/network cost isn't prohibitive of the brute force solution because there won't ever be more than twelve or so, which is 78 edges.

Brosnan
Nov 13, 2004

Christ, not this shit again.

Lipstick Apathy

Tricky Ed posted:

That doesn't mean I don't spend a lot of time thinking through my system design first, but we have fundamentally different thought processes and collaboration gets us to a better end result. Usually.

Product designer here and big same. My goal is pretty much to never be "THAT designer" who comes up with completely ignorant concepts that aren't buildable, but to do that effectively, I need close collaboration with a dev who can make good-faith judgments about what seems achievable, without them just being rooted in laziness or fear of complexity. Sometimes the poo poo I assume we can't do because it seems too hard is actually super easy in code (or with the right library), and other things that seem very minor are full of hidden complexity. It's honestly one of the differences I've seen as my career has grown to companies with more talented engineers, that they take a more active interest in enabling the design process.

Tei
Feb 19, 2011



(I am not a actual Game dev, but a dev on other areas and... )

Sometimes something is really easy or very hard or imposible when you try.

Theres something that seems easy that turn to be hard, or things that seems easy that turn to be imposible.

Only when something is not new, you know what to expect.

toiletbrush
May 17, 2010


This is more for mobile games, but what's the thread's opinion on a mobile game having it's own music? Assuming it's a little game, not something with an epic soundtrack, do you generally turn in-game music off and listen to your own? I'm asking because I've actually managed to finish a little iOS game during lockdown and want to get it released, but haven't done the music yet.

leper khan
Dec 28, 2010
Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

toiletbrush posted:

This is more for mobile games, but what's the thread's opinion on a mobile game having it's own music? Assuming it's a little game, not something with an epic soundtrack, do you generally turn in-game music off and listen to your own? I'm asking because I've actually managed to finish a little iOS game during lockdown and want to get it released, but haven't done the music yet.

I wouldn't break the bank on it, but people probably expect it even if they only listen to it twice for 10-20s.

Chernabog
Apr 16, 2007



I make educational games and music is pretty much my lowest priority, a lot of people don't even play with sound on. That said it does really help it stand out. If you are just making a project for fun or with no budget you can manage with royalty free music.

j.peeba
Oct 25, 2010

Almost Human

Nap Ghost

Yeah, I'd say royalty free music would be a fitting solution here. Having just one or two somewhat forgettable tracks seems to be common in mobile. As it happens there's currently a Humble Bundle of music for content creators which seems all right: https://www.humblebundle.com/softwa...eators-software

toiletbrush
May 17, 2010


Thanks for feedback! I'll probably do the music myself tbh as its another hobby, I was just wondering how much time I should put into it!

Adbot
ADBOT LOVES YOU

Brosnan
Nov 13, 2004

Christ, not this shit again.

Lipstick Apathy

I mean if you make a loving bop like Threes it could end up being like half the reason people play your game!

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply
«46 »