Pixelation
General => General Discussion => Topic started by: Ryumaru on May 04, 2012, 10:29:25 pm
-
What was your workflow like? or rather, how did you prioritize the creation of game assets? I'm asking for insight on how to go about work on my current project: Entropy ( and deadbird when I can get around to it) so those who have done projects single handedly, your opinion is especially valuable, but I'm open to anybody's thoughts really.
I figure that if I actually want this to be made, there should be at least some order to how I go about these things.
Also any tips and tricks you guys have found to speed up your process, either technical or conceptual, or any other miscellaneous bits of wisdom you may have are welcome! As this project has been my biggest foray into animation I fear that by the time I'm done animating everything, I may feel the first animations are sub par to the latest ( this will inevitably be true if the likes of pixel piledriver keeps dropping wisdom bombs on my thread)
-
Split your design document into chunks, make todo lists. Physical ones with notes. First chunk should probably have the main character and basic world tiles. Maybe first enemy.
Alternate between a chunk of assets, and coding. Don't switch between the two all the time. A day of art and a day of coding is good. You'll lose a lot of efficiency and just not really be in the right frame of mind to produce your best work if you keep switching too often. When coding and you find you need a new asset, or some modification to the artwork, just keep your lists up to date.
Plan for multiple passes. If it's paid work, you'll probably get some revisions, but if not you have to look over your own work with a fresh pair of eyes to see where you can make improvements, so make sure you leave some time between finishing and looking over again. This is for best quality, if you're going for efficiency instead for a tight deadline or something, you might not be able to afford the luxury. Try and plan tile variations or assets based off other assets to be done AFTER the source assets have been through this process. :)
If you're not sure about how something will work, consider using prototype graphics (ie. a green square). Some people like to prototype everything, but most things can be tweaked till they're fun; you should probably be able to work out what is less tested and more at risk of being scrapped. I do this when I don't know how to code something too, just incase I have to give up and do something different. Not just stuff I'm not sure will be fun. But I'm not a great coder.
Hope that's useful! :)
-
Bite-sized chunks for everything is good. It's so easy to feel overwhelmed and procrastinate when you're working all by your lonesome. It's probably best to work out a clear (and reasonable) limit on the scope of your game beforehand and then split your plan down into manageable milestones. This way it's easier to avoid losing motivation and "feature-creep".
Try to make a solid prototype with the most important elements first (player movement/interactions, common enemies etc) and then, when you have the core mechanics down, create assets and expand gameplay as needed.
-
Thank you guys! Both posts have been very helpful.
rikfuzz: luckily I'm not the one programming! Currently the main character stuff is mostly done ( for the first pass anyway) which originally left me up in the air as to where to go next.
ErekT: I find the lonesome part most difficult; since my programmer is taking a break, it's hard to get that satisfaction of seeing your work implemented. I'm usually a fine lonely painter, but when it comes to collaborative efforts It's always motivating to, y'know, be collaborating x]
Any more advice is of course welcome, I wouldn't mind a thread of general game asset creation tips+ tricks
-
As a fellow inverterate personal-project flake (I only ever seem to finish stuff when I don't have creative control/am being paid to :lol:) I'm perhaps not in position to advise, but to echo Rik, Erek & Helm (from your entropy thread); set targets and stick to them, knock up a skeletal playable build asap then improve upon it rather than falling into that moving goalposts molasses. Are you having problems with something in particular?
My 2 cents; animations are really not essential for playability, and started too early on aren't conductive to general progress. My priorities might be:
1. Static character sprite / game theme & mechanics
2. Basic enviroments tiles / level design
3. Enemy & object sprites / obstacles & puzzles
4. Animations (rough placeholders) / set pieces & bosses
5. Titles & Menus / dialogue etc
6. Polishing up that son' bitch 'till you can see your face in it :P.
-
I'd say have a regular sprint with your coder. Have a basic readup on Agile Development if you're not familiar with it. Get an overall aim for the week, not finish game, but something tangible, and do it. In a basic summary, if you are in the 'how long is a piece of string' part of a project, go measure some string, and work out how much string you can afford to use.
First time you do it will be a mess, but what you guys need to do is generate some meaningful metrics.
- how long do you think something will take to do / how long did it take
- what is the most important thing you are going to try do / was it the critical step or did it even work.
I would say if you guys are remote, work out a week's worth of work into 4hr chunks, and be open about when you can or can't work. Follow that tip from above of when you find a problem, work on generating a list, and not stopping to fix every problem.
So say on Monday have a plan of what is the main overall thing you want to achieve that week, and make it something both of you can get done in that time. Talk each morning for 5min about what is working, what is not working. If you see it's definately not going to work, dont be afraid of stopping to restart with better planning and then go again. It's better to go through some prototype loops and disasters for 10% of your project time, just so your remaining 90% have a chance of working okay, before you get into your real nuts-and-bolts prototyping.
When you are at Wednesday afternoon, stop where you are, play what you have, look over what you have. Compare it to where you wanted to be or what you wanted to be like. You'll find sometimes you're ahead, sometimes behind - but it's important to be looking at how long things are actually taking, how many loops each thing takes to get right, how buggy it is, how much stuff is piling up in your Todo list, and sometimes even if what you are doing is a good use of time.
Friday afternoon is all about going over your finished week's work, taking the time to talk openly about what is working, what's not working. What got done, what was aweome on paper that sucked on screen etc. Compare where you are as a % to complete and get ready for the next week.
I'd say the most important variable to learn is your own. When you quote someone 4hrs to do a task and it takes 2d, that can be bad. When you quote 4hrs and it takes 1hr, sometimes that can actually be a bigger cost to the project. I always think don't speed up or slow down to hit the time you quoted, work out your variance.
If you can now work out what your variance is, you'll do a lot to get a good relationship going with your coder. The sooner you can think 4hrs, and know to tell him 2ds, the easier it is for him to plan what he is going to do to. Back-to-back that lets both of you plan more effectively what's possible and what's crazy talk for the week.
The other last quick one I will throw in is do a vertical slice. The industry guys are now moaning at me being a producer 101 guy, but you guys have to step through every part of your pipeline and have it work at least once before you go into any real form of asset production.
-
The person that is paying you is always right.
-
The person that is paying you is always right.
Unrelated and also wrong! If you're being paid for your expertise it's absolutely your responsibility to speak up when something is worse than it could be, you're an artist not a robot.
-
Facet: I too have always found it difficult to complete projects, having never really done so ever! but Project entropy has probably gone the farthest so far, so that must be a good sign
Yes, I think I'll settle down with the animations, at least till summer when I get a new computer. Tiles i can easily do in photoshop and I like them more anyway :] Good advice!
DonMeadows: Thank you very much for your post! My programmer has been in hibernation lately, but once I get some more assets in, it'd be nice to keep a steady, relaxed pace with things. I may come to you with some questions once things get into the later stages of development!
yaomon17: What to do if you're not getting paid at all? Eventually it would be nice to get the game published in various forms, but for now it's for the love of art and the pixel. :]
rikfuzz: Both sides seem to hold some weight. I remember times working with clients where their vision just honestly led to bad assets, but they can be attached to their own ideas; and if the project isn't of your own concept than it's usually easier to just do it their way and get $$$. But at the same time they really should be hiring you based on your vision and value your opinion!
-
There's already a lot of good info here so I'll try not to re-iterate too much.
I use Google Docs to keep track of pretty much everything these days.
Spread sheets are the most useful format for how I like to lay out information.
It's cool because everyone on the project has access from any computer.
When we want to figure stuff out we do a Skype call to communicate faster. (we work offsite)
It's what me and my team mate like to call "Multiplayer SpreadSheeting".
It can be surprising how simple and fast it is to make something like this with 2 dudes typing stuff in at the same time.
And extremely useful.
Some example images for you.
I've censored out the sensitive information with black bars.
Measure your game with different scales of time.
Make a Milestone timeline that prioritizes what is important at each stage of the project:
(http://4.bp.blogspot.com/-HfLxpjkwFa8/T6j5T2WYtAI/AAAAAAAABU0/E5koRBRQfLk/s1600/MileStoneTimeline.png)
We send this to our publisher at the end of each week.
Theres also a Next Week list below not shown:
It helps us keep track of what we did and need to do next, and it keeps them happy.
(http://3.bp.blogspot.com/-O37Ecz-A-W0/T6mn9g9nz9I/AAAAAAAABVg/Hu7yDIsl1hY/s1600/WeeklyReport.png)
Make an asset list with simple notes about function.
(http://3.bp.blogspot.com/-u-qmQTRrB-Q/T6kYqP5YNmI/AAAAAAAABVU/YNSuop-OrJ4/s1600/ArtListandPurpose.PNG)
Everything in a game has purpose.
Purpose can be incredibly important such as "Allows player to open locked door".
But it can also be as simple as "Ambiance".
With purpose clearly defined creating assets is much more fluid.
If the assets purpose is unclear, work on something else that is more defined.
If the purpose continues to remain undefined, then there is no need for it.
I try to boil almost everything I design down to a single keyword.
Types, Classes, Actions, etc.
It makes it easier to define the objects in your game and talk about it with your team mates:
"So how about that Suicide Robot?"
"Yah we should balance his speed and damage radius"
They will also become the words you use to teach players how to play the game:
"Fire defeats Undead, and Hammers defeat Robots"
"The Gold Door is locked, you'll need to find a Gold Key"
I may feel the first animations are sub par to the latest ( this will inevitably be true if the likes of pixel piledriver keeps dropping wisdom bombs on my thread)
Sorry!
My advice is somewhat out of context.
I'm explaining pure animation technique in isolation, not in relation to production time or how to finish a project.
It's not my intention to be pushing you to redo the same animation over and over.
There is definitely a balance that must be struck between time, speed, quality, education, and experimentation during a project.
With practice you'll be able to use animation techniques in bite sizes.
It's not important (or time effective) to force EVERY principle into EVERY animation.
It's a bit like trying to use EVERY composition technique in a single piece of art.
Doing passes over multiple assets is good practice.
Even if your latest stuff is out of sync with older stuff, that's normal.
Just find simple ways to improve the stuff you aren't satisfied with.
It's almost always better to error on the side of "That's probably good enough".
I mentioned this somewhere else but, a couple projects ago we did an ASCII game.
We were able to get away with 0 animations for the player.
Instead he would flash colors, make sound, and spit out particles.
Under time constraints simple solutions can be very effective.
Your first complete game on your own can be really hard.
Creating a personal project is a privilege but also a curse.
There's no pressure to meet deadlines.
You have complete creative control.
These are good things of course, but can easily lead to the project stretching out unlimited.
All the stuff everyone else said.
Simplify, organize, communicate, prototype etc.
There's plenty of other things to consider.
But I don't want to suffocate you.
Game projects are a lot of work.
-
The person that is paying you is always right.
Unrelated and also wrong! If you're being paid for your expertise it's absolutely your responsibility to speak up when something is worse than it could be, you're an artist not a robot.
Most definitely. I'm not that experienced in this area, but I have spoken up many times with my client about changes I think should be made and they have almost always obliged and often agreed later that it was for the better. Clients ARE always right, they are paying you to make what they want, however they may not always know what they actually want and if it's even feasible. The point is to COMMUNICATE. They will lay down the final say, but don't let them do so without giving them your opinion. Remember, programmers and artists tend to have a totally different thought process and they may not see things the same way you do.
-
The person that is paying you is always right.
Unrelated and also wrong! If you're being paid for your expertise it's absolutely your responsibility to speak up when something is worse than it could be, you're an artist not a robot.
Hey, I have to make a living somehow. The last thing I want to do is irritate the client. If my opinions conflict with his/her's, I am the employee at the end of the day and I have to agree with my boss. Whether something is "worse" or not is not up to my decision, it is the designer's.
If you are not getting paid then my best advice is stay organized. Even when you are rushed, do not save files to obscure locations or randomly pull out flash drives. It is better to be 5 minutes late than to lose 60 minutes of work.
-
For each item in your big list of stuff, track not only status/completion, but where it is at in the process. Things making it through the process get broken down into requirements small enough to be verifiable or testable. So in addition to the big list of milestones and tasks like Pixelpiledriver posted, track a separate 'process' field for each item, something like this:
(http://www.4freeimagehost.com/uploads/f2c6f2816c33.gif)
New wacky ideas are added with status scratchpad and get a few days for the newness to wear off .
The order in items get scheduled depends on the major milestone requirements and any prerequisites. Some items may sit at 'feature firm' and 'design firm' for a while, depending on how much work you can do each week.
Keep the rejected and deferred items in the list, usually filtered from view. If you get stuck at some point, you can go back and see if you had considered a different approach.
If you keep a steady flow of work from week to week then you can balance creative parts (design) with focused grunt work (implementation, testing) with a little slack time (planning).
Tourist