Do you work on graphics or programming first?

[Volnaiskra]

Building a skeleton first, and muscles second, is surely best in most cases. Though there are times when the other way around is best. For example when you dream up a very interesting enemy, design it without any limits imposed yet, and then try and think of a unique mechanic that will organically flow from the creature you've just conjured up. In this case, you're likely to get a more imaginative end result than if just you built a mechanic for a 100x150px box and then skinned it.

Though in other cases, the reverse is true again I spent the first month or so making my game with just blocks, and it quickly became apparent that the most fun shape for my protaganist was a small 50x50px square - this better enabled zippy, bouncy movement in all directions, and naturally lent itself to Spryke's ceiling-hugging mechanic. That 50x50px block is the main reason Spryke ended up in ball-shaped as she now is. Had I started with graphics first, I probably would have gone for something more rectangular and/or humanoid, and I probably would have made the character bigger, to ensure I could fit more graphical detail in...and I would have ended up with a less fun game because of it.

Also, I'm sure I'm not the only one who sometimes tends to take a 'ping-pong' approach: code-graphics-code-graphics-etc. I'll do code with rough placeholders first. When that's working well, I'll add nice graphic stills. Once the graphics are in, weaknesses of the mechanics tend to show more clearly - like where they seem too clunky and don't match the form of the graphics, for example. So I'll polish up the code again until the mechanics feel the way the graphics look. Next, I'll do animation. That tends to dramatically change the feel of movement and mechanics, which calls for another pass at the code.....and so on.

Spryke's core movement mechanics have probably been through 7 or so such iterations so far. Every time I add another piece of the puzzle - a smoother camera, some code optimisations, some particle effects - it sheds light on another area where the movement can be improved. This sort of approach is too time-expensive to use everywhere in your game, of course, but for the core aspects, you'll likely end up with a superior result than if you had just gone the route of code-->graphics-->finished.

[BrashMonkey]

I'm an artist first and foremost BUT it's a massive mistake for ANYONE to focus on graphics before they get the game mechanics working and actually FUN.. You inevitibly end up spinning your wheels creating art that needs to be drastically altered, totally changed, or which becomes totally useless to the finished game... which is a MASSIVE waste of time.

Get the game working and fun with place-holder art you can make super-fast.. only once its all working well and the game won't change drastically, THEN should you start really making final, perfected art and animations to replace the place-holder art.

[piscesdreams]

I tend to make a lot of art assets first, or at least what is necessary for the core engine and main mechanics. I'd say it's 75% art first, 25% coding. I like to see how my art assets work in the live game and adjust those first to make sure everything jives right.

[nivram]

50 - 50 on art and coding.

Marv

[Janette5]

I plan the game out in extreme detail on an excel spreadsheet - including every value I'll need in alphabetical order, every background, every sprite.

Then draw the layout in graphics software to get the scale and to determine where the menu / hud should go so that it's not accidentally pressed i.e. you should not reach over it if playing on a cell phone.

Then I code and create a template with everything in it and temporary graphics and test it which then requires me to adjust a lot of things / add things / take things out - and this process always messes up my alphabetical list of values since I generally have to add some in.

Then I create the final graphics and insert them into the template and make sure everything works.

After that I create all the levels and start playing the game which inevitably results in some sounds annoying me, which I then replace, noticing some missing features and adjusting the game in general if the levels start becoming monotonous / boring to make it "fun" - finding bugs that despite testing the template level to death I did not encounter before - mostly this is a sequence of events that never happened before and and I didn't provide for them ... which messes up everything and at this stage I have to copy / paste the changes to every single level ... I'd really like to one day have enough knowledge and experience to get the game 100% at the template level ... but alas ...

And then when I work with someone there's an extra step - giving them a beta version to play for the first time and they come back with 10 changes that would make the game so much better ... but would cause me to redesign most of it from scratch ... that was fun ;-)

[1Ombra1]

I'm just learning to use Fusion2.5 now, and graphics is not my best skill (the worst one to be honest).
So I always use free graphics from third parts, at the moment I am focused on learning the functions of the various object types and the events.

[mobichan]

@salamanderpants: In what way is an "opinion" wrong? No one here is saying there is one way to approach making something in F2.5. I think most of us have found through experience that trying to minimize waste works best. Yes, there might be outliers who have found success going in a different direction, but they don't represent the majority here. There are also different goals that lean more heavily on logic over visuals, which need a slightly different approach. I find it interesting to see how people work through this thread, but in no way do I think anybody is right or wrong.

[chrisperry1983]

Ooooh, what a fun topic! For me, it's always been a little more on the code side with a balance of graphics. Generally what happens with me, is I have to define what the game will ultimately look like, which is kinda basically 100% graphics, but then following that with the code to fit that "look". Basically, I need to know what the main grid size will be (8x8, 16x16, 24x24, etc?) and then comes the code to wrap around how those will work. The next thing for me, is the coding/drawing, because things get pretty dry if I spend 100% of the time on coding blank boxes to do things.

It also helps to code and draw simultaneously, because I've run into issues where I'm coding run/jump/shoot/whatever, but I don't have any of those graphics built into the active objects. Then I have to go back later and add that in, but what I've found is that adding code or graphics in later creates conflicts and bugs with other code. If I had just done it back when I was working on those pieces anyway, it's way more likely I would've avoided the issues altogether.

Anyway...cool poll and conversation starter! I love reading through how everyone else does it.

[chrisperry1983]

I plan the game out in extreme detail on an excel spreadsheet - including every value I'll need in alphabetical order, every background, every sprite.

This is something I love to do as well. It'll usually change, but I love having the list of defined values listed, named, assigned, etc. I also use this step to build a general understanding of the main character and its abilities, how it interacts with the world, etc. This sheet also kinda describes the world and how it works with the player. This is all mainly bulleted lists with larger cells of information.

I also kinda document how the whole thing will be roughly setup. For example, the game I'm currently working on will have a level editor and ultimately/hopefully will have 100 levels. It will be a one-frame engine where I've built a level editor that saves the level data, and then gets loaded into the engine frame, rather than copy/pasting 100 level frames in the MFA.

[Volnaiskra]

Nice to see this poll because Simon was completely wrong. It just goes to show you cannot rely on personal experience for an accurate representation of reality.

@salamanderpants: In what way is an "opinion" wrong? No one here is saying there is one way to approach making something in F2.5. I think most of us have found through experience that trying to minimize waste works best. Yes, there might be outliers who have found success going in a different direction, but they don't represent the majority here. There are also different goals that lean more heavily on logic over visuals, which need a slightly different approach. I find it interesting to see how people work through this thread, but in no way do I think anybody is right or wrong.

I think salamanderpants was just referring to what Simon wrote in the first post (quoted below), though I think that the way salamanderpants phrased it made it sound more combatitive than perhaps it was intended.

From Simon:

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?

So, Simon was just saying that he'd made an assumption based on his impression gathered on the forum, but he wasn't sure if that assumption was accurate. Hence he made a poll to find out. And according to the poll, it turns out that the assumption wasn't accurate, which just shows that Simon acted wisely by making the poll, rather than just blindly stay with his assumption, which would have been the automatic temptation for most people. (I suppose it turns out that the most visible members on a forum won't necessarily accurately represent all the lurkers, etc.) I think that's probably all that salamanderpants meant.