|
I'm a freelance 2d artist; My portfolio can be seen here.
Feel free to contact me if you have any questions.
|
| Wednesday, February 27, 2008 |
  Portfolio, Hull Breach, Digital Painting | 
Posted - 2/27/2008 8:57:33 PM | Portfolio
I've been working damn hard on my portfolio, and it's finally coming together in what I hope is a solid enough design that says "I'm worth it!". (And man, I've learned a ton of CSS nonsense in the last few days.) The layout of the page is more or less down, now I have to fill in all the content.
I would appreciate feedback and advice, if anyone wants to share.
Asteroid Factory
As the title suggests, I set up a class that can spit out random asteroids for some good, clean fun all around.
The screenshot suggests an alarming narrative: You're stuck in the middle of an asteroid storm with a massive hull breach and a reactor core leak! ... or something. 'Course, it's all show.
I have a problem with wanting to make finalized graphics while in development, so I get bogged down in getting every detail right (the perfectionist I am) while the code starts to slip: No more! I'm going to be quite intentionally using placeholder graphics from now on, so that's the last pretty screenshot you're going to get for a while. And, as said, I'm concentrating on getting freelance work over my personal coding.
And I'll post a rough design document for Oort soon.
Macroing My Skills
Over time I go from feeling wonderful about my abilities to feeling like I totally suck. It swings back and forth, and I recognize that so I try not to take it too seriously. Still, perhaps something constructive can come out of feeling crappy about my art skillz.
I've resolved to do a little bit of digital painting each day, no matter how horrible it turns out and how bad I feel about it. ... and maybe I'll even post it, no matter how bad. This way I can grind through some levels in digital art and crank my skills. Also been reading lots about doing digital art by people better at it than I.
Here's what I've done from Feb. 23-26 (sometimes I do multiple pictures if I feel like it):
A good percentage of what all artists make is not awesome, and in fact could be called "sucky". It's through screwing up that we learn - maybe that's what artists call "sketches". So I'm going to keep painting and posting whatever it is that comes out of it.
I should probably alter the description of this journal to reflect the shifts in focus, all in good time.
| |
| Wednesday, February 20, 2008 |
| Time and money | |
Posted - 2/20/2008 1:57:57 AM | On the Updating of Blogs
I have heard conflicting wisdom regarding updating:
1: Never update unless you have something good, or else you'll suck.
2: Always update, even if it sucks, or you'll never get good.
In any event, I imagine I'll either be writing less here, or writing more about other things. Perhaps both? Why: Well, all things considered (and maybe it's the tax in the air), I've got to concentrate on making money sooner rather than later. I've got to work harder on freelance jobs and getting into that whole thing and less on my long-term projects which may or may not pay out in any way (and even if they did in the best of cases, it'd be in a years time -- and I can't wait a year to get decent income).
So here's to that! Either this'll work, or I'll have to start making comics about how miserable I'd be in a real job.
I'll write a regular update on Wednesdays, once a week. ... and also whenever I feel like I particularly have something to say.
It's not like I'm stopping, of course. I'm just slowing down personal projects, maybe I can be more thoughtful. It'll be fun. And perhaps I'll talk about freelance work I do, if the clients approve (doubt most would turn down free publicity!).
Oort
For fun, I made some "concept art", which is usually the death knell of a project I do because (long story condensed), I used to make grand plans with 2 friends of mine, and the only thing we'd complete is a pile of concept art because, well, none of knew how to program. We figured we could be "idea guys". Anyway:
And due to a certain someone calling my bluff, I've been writing up (as in, in a document) a gameplay/setting/story overview for Oort. I'll post some bits of it after wringing it out a couple more times.
| |
| Friday, February 15, 2008 |
| Work, what? | |
Posted - 2/15/2008 9:16:08 PM | Oort?
Nothing new to show on Oort. I suppose I sat around and thought about backstory a lot, but no coding got done. I find myself coding more on the weekend than during the week, so I have good updates for Tuesday, but not for Fridays. I'll have to think about this schedule (or make an effort to get more work done at the latter half of the week).
Linx0r
Graphics for Linx0r coming along, and in a cute sort of style that I wouldn't have known I was capable of before doing it. It feels good to be part of a project that is going to be completed. I always bite off more than I can chew; The genius of the fellow making Linx0r is that he's set a modest goal and is achieving it.
I know, he's a madman!
Indie Game Recommendation
On the indie game front, Armageddon Empires is a very well thought out game, impressively so even, which is unfortunately hiding under a horrible UI. No, it's really got problems, perhaps half because it tries to re-create the experience of a tabletop game without abstracting what (in my opinion) should be abstracted, eg. dice rolling, of all things. But then maybe their market is the sort of war gamers who get all mystical about rolling their own dice looking to recreate the tabletop experience, in which case it is a legitimate but perhaps clunky design decision.
So if you're into war games and have great patience, I recommend it. But only if you have those two things. You just have to kinda read between the lines to understand what the hell is going on, because the game ain't telling you upfront. But once you figure it out, the complexity of the game is almost elegant, or so it seems from from what I've played in the demo.
Edit: The guy who made it has a blog here, and talks about the design and success of the game. I'm lightly horrified to hear how it was made (in that it's built on some weird Adobe something or other thing (???) ), but that goes to show it's not being an amazing programmer that hand-codes a brilliant OpenGL engine that wins you success -- it's finishing the project. And designing it well, I imagine.
Important News
The most important thing that has changed is, of course, my user picture which follows that grand internet tradition of portraying a person as looking far cooler than they actually are, at that sort of candid artistically awkward I'm-holding-my-own-camera-toward-myself angle (mirror self-portraits are so passé), with enough Photoshop magic to make it look like the cover of a pulp techno-thriller, or something. Yes; suffer my vanity.
| |
| Wednesday, February 13, 2008 |
| Rocket-propelled Asteroid | |
Posted - 2/13/2008 12:16:59 AM | There were a number of issues, so I talked with Laura about how to organize everything and it seemed best to re-do a number of the major systems. That, and I read up more on Pyglet -- I take back what I said about the documentation being worse than Pygame; it's better, perhaps, but there are less tutorials and secondary information sources (but then so much overlaps with OpenGL itself, so perhaps not). Anyway, it's a recently released project, but I'm finding that is smooths out many of the rough edges of OpenGL very nicely.
Component System
"Actions" and "States" are no longer separate, generally. All actions are now handled through the .update() call attached to States, so for example the State Physics.update() is equivalent to the old Move action. Sprites are now held in a Renderable state so that many sprites can be attached to one object, and the update call handles animation (though animated sprites are not implemented yet). The action queue is still around, and it might be used by special cases, but I'm not sure about that yet.
The rendering was also overhauled to account for all these changes as well.
So have a look.
This:
asteroid = Entity()
asteroid.addStateByName( 'renderable' )
asteroid.getStateByName( 'renderable' ).addSprite( 'testAsteroid03' )
asteroid.addStateByName( 'particleemitter' )
asteroid.getStateByName( 'particleemitter' ).imbue( asteroid )
asteroid.addStateByName( 'physics' )
asteroid.getStateByName( 'physics' ).rotation = 1.0
asteroid.getStateByName( 'physics' ).vectors = (0.5,1.0)
asteroid.getStateByName( 'physics' ).coords = (512.0,512.0 )
self.addEntity( asteroid )
Makes this:
Yeah, I haven't implemented a system to do all the enginepoints on a ship sprite, so the its the asteroid which gets a rocket trail to show off the particle emitter.
And I must admit that the starfield is a bit hackish, but it should take only a little work to get multiple layers working properly and scrolling by at different ratios. It'd be nice to get these changing depending on location, too.
In other news...
It looks like the final push on Besome Games' Linx0r is happening, so I'm going to be doing a bunch of final graphics for that this week. We'll see what I've got time for on Oort, but at least I'm feeling better about its direction.
| |
| Particles, Sprites, and Rendering! | |
Posted - 2/8/2008 10:52:53 PM | I'm more at peace with OpenGL now, no worries. It is just occasionally frustrating.
Particle System
Before it was pretty much a test system, but now I'm working on implementing a system that has variously defined particle Types which can be called by ID. So you say to the particleEngine, add ParticleType 3 at (10,10),( with various possible overrides and additional parameters like velocity, decay, .. color?).
Rendering time is also quite improved; It is indeed faster to not have the thing apparently create a texture for every blit of several hundred particles. Next I'll be implementing dcosborn's suggestions to my last post. That and loading particle definitions from text files.
Did I mention how open to modding this will surely be? Well, it will.
Camera & Viewport
I suppose I mentioned the camera in my last post, didn't I. Did a bit more work on that, and boy it can be finicky. The problem is that my graphics are basically pixel-art with the hard edges that entails, while the OpenGL viewport can wander through coordinates which are stored as floats at it's leisure which makes weird blurring and flickering at edges that are supposed to be pixel-hard.
Perhaps this has to do with my rendering as well, which could use some work I'm sure.
So: I was considering doing everything in vector art rather than pixel art using Inkscape, which I've been playing around with recently. Problem is: I'm not used to vector art because I haven't done it before. On the other hand, pixel art and painting is dead simple and I'm good at it, but ... vector art would be good to learn, and the style might work better. It feels weird though, a little like 3d modeling but rather less a pain.
Well, graphics are far from final anyway, so we'll see how I feel between now and... and infinity!
Sprite Rendering
Working on implementing a very generic yet extendable Sprite State that can somehow be accessed correctly by other things. I mean, it has to be able to handle everything from a simple rock graphic to a spaceship with possibly multiple components and effects.
I'd show a screenshot of what's going on now, but it's basically the same ship as before -- just the rendering isn't a total hack this time, so it does its business semi-properly through the component system. Additionally, the camera flies around, stuff that isn't in the viewport gets ignored, and ... I'm liking it. This could be good.
Backstory and Writing
I've been thinking of the setting and plot of Oort, and I think I have a direction, but I don't particularly want to talk about it. Anyone read anything by Ken Macleod? I'm thinking something like his space opera, with some Charles Stross in there as well. They both don't do the ponderous WW1-navy wanks transposed into space, I'll tell you that much.
And the themes of the story should fit somewhat in with the gameplay, which basically revolves around mining asteroids in deep space. But not really, such a setting probably suggests a Western at its heart, but I want to subvert the tropes one usually gets from such things.
This'll be fun.
Misc.
God, it's a lot of work to get to Milestone #1 in a responsible way. I find myself building many of the huge systems that the game will run on before even starting down the list! It's to be expected, I suppose.
Though if I were working with a larger team, more like a real studio, it'd be necessary to build as much of the game all at the same time as possible. But of course this is only really possible when one has the skeleton, at least, of an engine as well as the experience to plan out the schedule for developing resources.
I seriously am still avoiding the trig., but maybe I'll have to come to face it this weekend and rip off the proper equations from some other programs I've seen -- you can't copyright math! (Unless you can; That'd be depressing.)
| |
| Tuesday, February 5, 2008 |
| Milestones, what milestones? | |
Posted - 2/5/2008 9:19:27 PM | Am I going to post one of those trashy OpenGL particle screenshots?
Yes I am!
Here it is!
Ahh! It's like a flashback of Cosmosis!
I'm finding that I'm spending a lot of time on things that are not directly related to accomplishing milestones. But then the milestones are entirely centered on forwarding gameplay rather than extraneous elements which one can get lost in. The milestones then are encouraging me to "build a game" not "build an engine", and this is a good thing. I just have to pay attention to them. And by this I mean that I've not gotten navigation working -- there may be some terrible errors in my trig, I found today. Terrible errors.
(I'm regretting getting-a-D-in and dropping-out-of that trig class halfway through my junior year of high school. Long story, but I ended up in more or less community college to finish high school and spent my time hating math for the next 5 years until I took a programming class... in art school. I hated grammar for like 4 years too until I took an English class in college. The problem was attitude (and the school institutions, I'd say) -- I was so angry at school and in general throughout high school (because it and other people were awful) that I didn't really learn as much as I should have and now wish I had. But I digress.)
Let me discuss non-milestone things I've worked on.
Camera
There is now a camera class that zips the viewport around to center on wherever was right-clicked. Eventually this should focus on the Player's ship, or better yet on whatever is defined as the target entity (which will contain a Position State with coordinates).
Also, the camera is 'soft' in that it isn't directly latched to the target, rather it moves the center of the view toward the target gradually. I want to make it so that if the target starts getting away from the focus, the camera will speed up so that the target is never far from the center of the screen. For objects which are moving, the camera could focus somewhat ahead and in the direction they are traveling.
Particles and Slowness
As shown, particles do indeed fly around. It gets pretty slow when I have a few hundred particles in there, and this upsets me. Is Python doomed to do OpenGL slowly? (Probably.) Does Pyglet take care of any of these problems or am I kidding myself? (Who knows.) More on this in the last section.
Draw/data rate
There are now set rates for updating the GameState and rendering, and everything that happens should scale it's action properly by the Timer's delta. I do still need to actually add a proper sleep function in here.
OpenGL
The rendering gets slow when I have a few hundred particles flying around and, as I said, this is worrisome.
Maybe I'm just doing things wrong -- but then it's a bit unclear how one is supposed to use Pyglet: the documentation is slightly worse even than Pygame. And Pygame, at least, has been out for some time, and is based on SDL which has documentation itself that mostly carries over. This begs the question of investigating OpenGL documentation, and that I am doing, but damn is it ever difficult itself, and more confusing because I'm not sure exactly what and how Pyglet does things and what I could/should be handling myself. I find myself wondering how anyone could possibly learn this, and how anyone could learn it well enough to do things properly, not just at all! (Answer: Years of experience and a deep understanding of what's going on, surely. I just don't have those things.)
Maybe I'm just overwhelmed. ...and maybe I should be turning my particle graphics into Pyglet's texture class instead of drawing them straight-up from the image class, but that's just a guess because I'm not sure quite what the image class does. If it's creating textures on the fly all the time, that'd be terrible. Perhaps I need to take a look at Pyglet's code.
At least I think I've gotten these transformation things kinda figured out.
It's going to take some time to get really cookin' with OpenGL, but I'm working on it.
| |
| Glow and Greeble | |
Posted - 2/1/2008 10:30:11 PM | Glowy Bits
Yeah, I've been making pretty things rather than getting the navigation to actually work. Navigation doesn't make pretty screenshots! Still, the blending and such could use some adjustment, and I could get far sillier with the glow effects. This is OpenGL, there's no reason not to go completely overboard.
Anyway, instead of just dropping a Sprite state into the ship, I'm now getting the images and position of engineGlows from the components contained in the shiphull (which should perhaps be renamed shipInfo or something because it contains a hull component itself) in the ship. See here:
engTest = {
'thrust':0.5,
'maxSpeed':5.0,
'turnRate':3.0,
'glow':'glowTest01',
'glowColor':(0.5,0.8,1.0,0.9)
}
hullTest = {
'imageName':'ship64_redA',
'enginePoints':[ (11,9),(11,55),(5,27),(5,36) ],
'gunPoints':[ (50,15),(50,48) ],
'rayPoints':[ (35,24),(35,49) ],
'color':(1.0,1.0,1.0,1.0)
}
'Problem is, the renderer doesn't know how to deal with this except as a unique case that I've coded it to take into account, which isn't so good. So I'm thinking there needs to be a RenderHelper state or something that will inform the renderer as to what it needs to do to get from the entity in question all the graphics and coordinates said entity needs to be rendered.
And it'll be really fun to have some particle shooters going linked to the given points to make some nice engine exhaust effects.
So to speak generally, there's a hell of a lot of work to do. I always enjoy the feeling of a blank paper to draw on in front of me, though it is intimidating.
Working on a New Portfolio
This Web 2.0 crap is giving me a hard time so I decided to just go with what I know, and what is unabashedly nerdy. Do tell me if this totally screws up your browser or has performance issues, I'm trying some slightly odd stuff with animated gifs:
Portfolio Layout Test
The inspiration is of course this. Laura called my version "Bluepiter".
| |
|
| S | M | T | W | T | F | S | | | | | | | 2 | 3 | 4 | | 6 | 7 | | 9 | 10 | 11 | | 13 | 14 | | 16 | 17 | 18 | 19 | | 21 | 22 | 23 | 24 | 25 | 26 | | 28 | 29 | |
OPTIONS
Track this Journal
ARCHIVES
October, 2009
July, 2009
June, 2009
May, 2009
April, 2009
March, 2009
January, 2009
December, 2008
November, 2008
October, 2008
September, 2008
August, 2008
July, 2008
June, 2008
May, 2008
April, 2008
March, 2008
February, 2008
January, 2008
December, 2007
November, 2007
|
