Do you work on graphics or programming first?

[Simon]

This topic came up in another thread and I'm quite interested to get a read from the userbase. I've seen a lot of evidence both ways, but from things I read and when helping users here I get the impression overall that people work on their Fusion 2.5 projects focussing on the graphics/visual side first and later on develop the engine/code that drives the game. Am I right? Please vote on the poll and discuss, I'm really interested to see what you all think and how you work!

[mightyenigma]

I usually advise people to get the logic working first because a lot can change as you're developing that, and some changes mean that all that hard work you put into the graphics has to cycle through again. Or you never use the graphics because you find out that thing you had planned isnt
going to work out with the rest of the game.

BUT much of the time (and depending on the type of game) you have to have at least the silhouettes of the graphics figured out in order to know how the movement and sizes are going to fit and relate to each other, and working on graphics often generstes vital core gameplay concepts. so it's not all either one or the other.

The reason i lean toward fromt loading the logic work is because i know a lot of kids who spend hours and hours tweaking their pixel art and still have no idea how to get the most basic parts of the game working, which amounts to zero progress after three weeks of it. And they end up discarding half their graphics by the time they do figure it out.


Sent from my iPhone using Tapatalk

[Simon]

I think that's the general advice with programming mightyenigma, the so called "golden rule" of programming (writing too for that matter). I think I personally have a different slant because I most often find myself developing apps rather than games, and most of the time with the apps I develop at least, the interface is king. When I do work on things the other way around, I actually tend to use my knowledge of Fusion to think out the logic and how things will work, whilst working on the graphics/visual side... and then fill in the code afterwards, from memory or paper notes.

[Klownzilla]

I tend to do both almost 50/50 but before doing to much art i make sure I can handle the toughest parts about the coding. When I have that figured out i focus a lot on graphics

[faber]

Usually I work on the code/logic before, using provisional asset templates and placeholders in the meantime. When the programming is almost complete, I begin working on the real graphics, place it in the game and see if everything works well and looks nice. This approach is very useful to production of graphics assets, reducing waste of time and unnecessary reworks.

I noticed, however, that working only with provisional graphics can become boring quite easily, with negative impact on motivation. For this reason I'm considering adopting a mixed approach in the future, or even try starting with real graphics right away. I remember reading here that 'graphics before, code later' was also the approach of Scott Cawthon, maybe another reason for me to give it a try.

[Windlake]

I work on both, when I'm excited to code some events that don't require much of art, I can use placeholders, but I realized that often, especially for the characters, I really need the animations to be completed to code them right (transitions between animations, transitory animations and other things that imply precise animation frames.)

[mobichan]

I usually get basic systems and player control working with boxes before making any art. It helps keep me motivated to see more final assets in game, but I only make truly final art when I am polishing timing or spacing. UI almost always needs sizes worked out first, but, again, I can do that with boxes at first and pretty it up later. Things like enemy AI usually require a code pass to make it work, then an art pass to get the visuals and feel I want. Then another back and forth pass between code and art to cement the thing. Since most of my work is pixel art, I can totally agree that you don't want to waste a lot of time making assets you might end up dumping.

[BartekB]

I draw final graphics (or close to, like only needing few tweaks after) if the particular thing is really easy to implement.
However, if the code is really difficult I don't usually bother with graphics until it's finished (which then I replace placeholders with actual graphics). Example of this is my complicated random level generator.

What I also do is make the main code which lets me create an object with the same "class" (Think an object but different events/functions are executed depending on "Name" alterable string), which then I draw the graphic then copy paste template code and change some bits. I do this for everything from weapons, to items, to enemies to player customisation pieces (hats, shirts, pants, etc).

[mightyenigma]

the best answer is really going to depend on the nature of your app. Some graphics need code first and some code needs graphics first. Knowing the difference is the skill known as project management I think


Sent from my iPhone using Tapatalk

[mightyenigma]

CTF very much encourages a graphics-first approach and you tend to think of the logic and data in terms of the graphics with CTF so that approach may succeed more in CTF than with other devkits.

I have found that I often have to do level design logic where the code depends completely on the shape of the graphics to get it laid out and interacting correctly.


Sent from my iPhone using Tapatalk