Posts Tagged ‘sprites’

Progress has been made!

Posted by
Saturday, December 10th, 2016 9:55 am

A little update about our game for now:

We’ve decided to implement a local-pc multiplayer and I’ll start with it right after posting this post.
Also collision and hitboxes are fully implemented now and work all perfectly.

A little preview of the progress in our room:

The game is going to consist of multiple smaller games in rounds and a player can win points by winning such minigame, while still everyone is in the same room.
The real pain in the *ss is going to be the music, but we’ll look into that later.

Thanks for reading!

Maurice and Jelle

Progress!

Posted by
Saturday, April 18th, 2015 5:35 am
Prepare your hands and fingers to fight using your H.A.N.D.S (Handy Armed'N'Dandy Ship) - the experimental war solution.

Prepare your hands and fingers to fight using your H.A.N.D.S (Handy Armed’N’Dandy Ship) – the experimental war solution.

Front animation done. Phew…

Posted by
Friday, April 25th, 2014 7:37 pm

output_ruh6se

 

This took long enough. Pretty happy with his mushroom hat. :3

I’m in … with animated sprite generator + source!

Posted by
Thursday, April 18th, 2013 10:04 am

I’m in!

This is my second LD.  Last LD I got #42 on innovation and #48 on theme. I did my best to create an original game.  But it had some flaws which made it less fun to play. I only got #137 on fun.  This time I want to try and reach the top 50 in fun, and try a little less hard to be original.

Another thought I’ve been playing with is to create as many (mini) games as possible in 48 hours.  The result will be something like “Lazy Jones”.  This idea was inspired by the following article: Mark Cooke’s “10 games in 10 hours”.  Problem is, how am I going to fit each of these games into a single theme? Maybe I’ll get lucky with a theme that warrants having minigames :-)



One of the tools I’ll be using is my random animated pixel art/sprite generator, see the samples above :-)  There is a new version.  I added a couple more animations to it.  And, you can get the source!

Sprite generator: http://tmtg.net/ludumdare/spritegen/

Source: http://www.xs4all.nl/~borisvs/jgame-3.6.2.zip  (note, code is still messy)

The sprite generator is now part of the JGame package, which it depends on.  JGame will also be my base code library as usual, possibly with JBox2d.

The sprite generator is found in examples/tools/spritegen/

To compile it, install JDK and Ant, and use the following commands from the JGame base directory:

ant base
ant tools

You’ll find the jar in jars/.

Other tools I will use:

  • sfxr, audacity for sound
  • evolvotron (another handy graphics generator), gimp, inkscape for graphics

Spritely – Autogenerating Sprites From The Web (Free Tool!)

Posted by
Tuesday, April 16th, 2013 10:23 am

Just in time for Ludum Dare #26, I’m releasing a beta of Spritely, a tool I made for autogenerating placeholder art. We have lots of tools for automatically making music (like Autotracker) or sound effects (like cfxr) – these tools are great for adding in temporary content when you’re rapidly developing a game, or for generating content that you can’t make yourself just yet (I have no musical sense, so Autotracker often comes in handy for this). Why don’t we have one for art?

spritelyexamples

Spritely is my attempt to make one! It uses image sources like Google Images, OpenClipArt and Wikimedia Commons to generate sprite-sized art automatically. It comes in three flavours – an easy-to-use GUI (which is really ugly), a command-line interface (in case you want to automate things) and a Java library (for building right into your game). Best of all, the code is public domain so you can hack it and extend it to your heart’s content.

Download links for the UI, command line, and the source code in the README on GitHub

What can you use Spritely for? Well, it’s handy for generating art to fill gaps when you’re prototyping – you don’t have to stare at coloured rectangles any more. I’m hoping lots of you will find that useful when you’re coding like crazy in a couple of weeks. But why not think more experimental?

Screen Shot 2013-04-13 at 16.56.09

WALRUS!

For the #7DRL competition this year I tried to make a roguelike generate itself. One of the things I added was enemies, player icons, items and skills that had their graphics generated on-the-fly by Spritely. The player said they wanted to be a dog… or a walrus… or a trumpet… and Spritely made a picture to match. If you reduce Spritely to just searching for one or two images at a time it can do it quite quickly (not quick enough for realtime, but I’m sure you’ll find a creative way around it – in my roguelike I just searched in the background and added the icons in when they were ready).

If you use Spritely for anything, from placeholders to a new genre of games, let me know! You don’t have to, of course, but it will put a smile on my face and also let me justify spending time on making it. I want to create more tools like this that spin off from my day job (where I research techniques for automatic game design). If I get lots of feedback I can show this off to people next time the funding nightmare comes back.

Good luck in Ludum Dare 26! If you have any questions please leave them below. I’ll do my best to update Spritely when I can, but no promises – feel free to make your own extensions and fixes, the code is free!

Aqualution (Ludum Dare Jam) by AvibeGames Postmortem

Posted by (twitter: @Zonepony)
Tuesday, August 28th, 2012 9:13 am

Our comp entry is here: http://www.ludumdare.com/compo/ludum-dare-24/?action=preview&uid=5234 Also embarrassingly, apparently Aqualution is a soap brand name so that’s probably not going to stick.

Evolution is actually one of my favorite game mechanics, but I was completely at a loss for what could be implemented in only a few days. That was the biggest hurdle.

A lot of game mechanics fell by the wayside and the idea of evolving powers turned into just growing into a bigger newt and surviving a hostile environment. I got most of the art done that I wanted to, but Alex of AvibeGames didn’t have enough time to code everything in and make it functional so we worked with what we have ready in the framework. Jack did the music and got it to us very quickly for the few songs we needed for gentle ambiance. It was a pleasure to work with my team and friends, I learned a lot about how to make pixelart and it’s likely this project will roll into a bigger post-Dare game or another one.

Things we succeeded at:

  • Making a nice atmospheric sidescrolling game
  • Simple and varied enemies
  • A health and EXP system
  • Smooth water floating and dashing physics

Other things that got the chopping block:

  • Icebergs
  • Key/Door unlock mechanic
  • Longer bosses and levels
  • Moray eel and giant octopus

I always look forward to Ludum Dare, succeed or fail, as motivation and a learning experience every time. Even if you don’t finish, I think it’s important to post your work—you’ll get valuable feedback for later from your peers.

The secret to my success this time was remembering to take breaks, but not too many. Sleeping, cranking the music up full blast and getting shit done. And sometimes I didn’t, so I’d rush to make up for it, but I’m proud of what we have to show already.

Graduating from Programmer Art

Posted by
Saturday, July 7th, 2012 2:00 pm

As I discussed in my previous post, my largest perceived weakness going into an event such as Ludum Dare was my graphic-making abilities. This past weekend, I took my first step toward exercising that particular skill. Prior to this weekend, I had never created a sprite in my life (that wasn’t entirely one color). Heck, I never even doodled in my notebook in middle school.

Where to Start?

At first, I really didn’t know how I would go about improving myself. Isn’t the designing of sprites just art? Isn’t visual artistic ability just something you’re born with? My brain is so imbalanced to the left hemisphere that I’m constantly falling into traffic. What kind of fool’s errand am I going on here? However, throwing doubt to the wind, I set out to build a sprite.

The first task I gave myself was to pick a graphics tool. I tried some of the ones list in the Ludum Dare Tools section, but didn’t see anything that struck my fancy. At one point I was on Chapter Two of a PyGTK Tutorial in the hopes to build my own tool. Luckily I shut down that bit of insanity. Eventually, I decided to just work with good ole’ Gimp, which worked better than expected.

Next, I went scrounging for tutorials. I didn’t think I’d actually find anything worthwhile, but I was badly mistaken. If you’re a programmer looking to get started with Pixel Art, you MUST read Derek Yu’s Pixel Art Tutorial. It breaks things down step-by-step, which is extremely helpful. Don’t be afraid by Derek’s amazing looking image, the ideas transplanted just as easily into my practice images.

I started very simple: following the tutorial to create a dead-simple picture (a machete). It wasn’t too shabby, but it was also a pretty simple image to begin with. So I decided to go with something a little more advanced to really test myself. I already had some sprites pulled from the NES Game “1942” to use for graphics in a game I’m screwing around with, but maybe I could replace them with some sprites of my own. So, I would use the tutorial’s lessons to create my own sprite of a fighter plane.

Step One: Draw a Concept

Some Clip Art I found to use as inspiration

For me, step one was to get an idea of what I wanted to draw. For Derek, this is Part Three (yeah, I’ve purposefully renumbered the steps to make things confusing for you). First, I googled for a top-down view of a plane, and found something to use as a concept. Next, I tried to draw with pencil and paper a likeness of this plane. I’m not really sure why I decided to do this (after all, I already have some concept art in front of me) but it just felt right. Later I decided that this worked pretty well, as the image I drew was something that I knew I could at the very least draw, which gave me a boost of confidence. It also allowed me to customize the image a bit more to what I wanted. Now to be sure, my drawing abilities are very sub-par (and fortunately for you, I didn’t scan the image I drew), but by studying the original image part by part, I was able to get something decent.

Step Two: Pixel an Outline

I created a new 64×64 pixel image in Gimp, and prepared to embarrass myself. Finally, I ended up with the following:

Some things to note about this:

  • Although you don’t see it in the screenshot above, when working in Gimp I made sure to enable the grids so I had lines separating pixels.
  • There are some jagged lines. While I did heed the tutorial’s warning, I felt that there wasn’t much I could do about some of the jaggedness, particularly near the back of the wings. I hoped that they would come out later in the process.
  • Learning how to use the various Gimp tools to draw/erase/etc in a straight line is pretty helpful. Particularly, it is faster to use this method to draw a line rather than placing every pixel with the pencil tool. Even lines that are drawn at strange angles will give you pixels to start with, and you can just fine tune the resulting line with either the pencil or erase tool
  • Speaking of the erase tool, you’re obviously going to need to set it to “Hard Edge”.
  • One tip is to have a second view open to see what the image looks like in it’s actual size. After you’ve opened your Gimp window and have zoomed in on the image so you can work with the pixels, click “View -> New View”, and Gimp will give you another window that you can set to a different zoom (which is probably best to keep at the default zoom)

Step Three: Add Color

The next step was to add color. I bucket-filled the areas. This was actually pretty nice, since I have always been under the impression that if you bucket-fill a sprite it’s going to look terrible, and the only way to get something decent is to color each pixel individually. You’ll also see that I decided to add a propeller blade to the front for no particular reason.

These are just three colors that I randomly picked. Some day I might actually learn about color theory and all that, but I’ll save that lesson for some other day. Already, I’m pretty darn impressed. I would be happy with this! However, there is more that can be done.

Step Four: Shading/Lighting

The next part is what really makes the image “pop”.

I’m not sure if I got it “right”, but I did get… something. Notes on this step:

  • The basic idea, as explained in the tutorial, is to pretend that there is a source of light, choose the direction it’s coming from, and draw where the shadows should go. Also, lighten where the light hits directly. I sort of changed my mind up half-way through where the light was, so I might be kind of all over the place. Especially on the right side of the tail section. However, it should be pretty clear that the light is above the plane’s vertical axis, and to the left.
  • Here, the dodge/burn tool is your friend. The dodge will lighten, and the burn will darken the pixel you click. Remember to set the tool to “Hard Edge” or else it will affect multiple pixels!
  • Although it might be obvious to some, this wasn’t to me: if you have the default color for the pixel and you dodge (lighten) it, then decide you’d rather keep it at where it was, doing a burn (darken) will NOT get you back to your original color. You’ll need to undo, or just redraw the pixel
  • I reread the tutorial after I was done, and one tip was to do the shadows (darken) first. You’ll end up drawing more shadows this way, which sounds like a good thing. Think about it: with a single point of light, you will have more areas with less light (shadows) than you will being directly hit by the light. I’ll have to keep this in mind next time.

Step Five: Selective Outlining

As you can see, the pixels that I drew for the outline back in Step Two have been dulled down to the colors that are surrounding them. This makes the image less “hard” (or using Derek’s words, “less cartoony”).

  • I made use of the “Smudge” tool. As with the other tools, I made sure to set the “Hard Edge” option so that I would be affecting one pixel at a time. The way the “Smudge” tool works is you click and hold your mouse button on one area (i.e., a blueish pixel in the cockpit window ADJACENT to a black “outline” pixel in the cockpit window), and then drag the cursor INTO the black “outline” pixel. You can think of it as smudging your finger across the page, pushing some of the blue onto the black. Really, what this means is that you get some blend between the dark black and the light blue, without needing to manually pick the dark blue color. The cockpit glass is where it’s most noticeable, but I did it for the majority of the outline pixels.
  • Unlike the other tools, the Smudge tool requires a bit more finesse, since you have to “drag” color from the correct source pixel into the correct destination pixel. Obviously, this can be a pretty long process for all of the outline pixels. If I knew that there would be a large group of pixels in a row that would all have the same smudge source color, then I would smudge one of them. After, I would use the Color Picker tool to select the new color that was created, and use the pencil tool to draw that color onto other pixels that would do the same thing. This was especially effective for those long, straight lines of outline pixels.
  • One thing I could have concentrated on more was to do the selective outlining a bit lighter on the very outside edges of the sprite, as suggested. I played around a bit with the smudge settings, but could have gone even further by using the dodge tool to lighten up these pixels even more.

I Survived!

It’s by no means worthy of the video game hall of fame, but it’s better than stick figures. Some final thoughts on this entire process:

  • In total, it probably took me a bit over an hour for this one sprite. I imagine I can cut this time down by knowing the keyboard shorcuts for gimp, which I was only partially familiar with. Another was the fact that I did this using the trackpad on my laptop. A mouse on a desktop would probably be faster.
  • While Gimp has great toolage for messing around with a single image, I can imagine creating animated sprites would be difficult. On the one hand, Gimp has nothing built in to animate the sprite as you’re creating it. On the other hand, it would not be too hard to write a program that simply animates the sprite for you that you can stick into one corner of the screen while Gimp is open.

Comments/criticism welcome!

Presenting VDZ’s Basic XNA Sprite Engine

Posted by
Sunday, April 15th, 2012 3:06 pm

Since I didn’t want to rewrite a whole bunch of code next weekend, I decided to tidy up and release this bunch of code.
It’s some helpful code that allows for easy sprite handling in XNA 4.0.

Features
-Easy sprite creation (just CreateSprite(name, position) and it’ll automatically render it from that point on)
-Changing position, scaling, rotation is also easy
-Depth system where deeper sprites are always rendered behind less deep sprites
-Automatically loads the Content/Graphics folder for you so you can just refer to the images by name
-Basic layered sprite support (multiple sprites combining to make one sprite, for example a base body with armor and a weapon overlaid on it)
-Basic animation support
-Licensed under Creative Commons Attribution 3.0 Unported, so you’re free to modify it or use it commercially

Code includes a simple example project.

DLL download link (MediaFire, 7.43 KB)
Source download link with example (MediaFire, 92.74 KB) (Microsoft Visual Studio 2010 solution)

Basic documentation

How it works
-Create a folder ‘Graphics’ with at least 1 image in it in your Content folder. The folder or any of its subfolders must not contain any non-graphic files.
-Put a SpriteFont in your Content folder with the name ‘Default’. It will be used as font for GTexts and the log.
-Call SpriteEngine.Initialize in the constructor of your XNA game class (note that it MUST be in the constructor, NOT in Game.Initialize()), after setting Content.RootDirectory.
-Call SpriteEngine.LoadContent in the LoadContent method of your XNA game class.
-That’s all the initialization it needs. Call SpriteEngine.Draw in your Draw method to actually have it do something. Note that it does not clear the screen for you; keep GraphicsDevice.Clear in there.
-If you want to use animations or ‘camera scrolling’, call SpriteEngine.Update in your Update method.
-From now on you can use SpriteEngine.CreateSprite to create sprites in your game. It returns a sprite object, which you can use to change its position, rotation, image, etc. Use SpriteEngine.EraseGObject to erase a sprite, or SpriteEngine.Nuke to erase everything.

Classes
SpriteEngine – Main class. Most of the functions you need will be in here.
GObject – Base class for displayable objects (Sprites and GTexts). Contains basic information like position, scale and depth.
GText – A displayed string that can be moved around and has a depth, much like a sprite.
Sprite – Class representing a sprite, containing basic information such as its position, images, rotation, scale, etc.
LayeredSprite – A sprite composed of multiple sprites. Uses a simple layer system where when the sprite is drawn, all of its sub-sprites are drawn at its location instead.

Details on what each property and method does can be found in comments in the code, I’m too lazy to type them all out.

License
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
You are free:
* to Share — to copy, distribute and transmit the work
* to Remix — to adapt the work
* to make commercial use of the work
Under the following conditions:
* Attribution — You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).

Have fun, and good luck with your games.

Progress on art

Posted by
Friday, December 17th, 2010 10:21 pm

So I decided to be stupid and make some nice sprites first. Here are the results so far:


I’m thinking it will be a platformer in which the balls change your color if you are a different color from them and kill you if you aren’t a different color from them. Also, which color you are determines which spaces you can go through.

What does this have to do with discovery? Absolutely nothing. And I don’t care one bit, ’cause I have some hot balls. (Maybe if I have some time I’ll add a storyline involving a space shuttle)

Better Programmer Art

Posted by (twitter: @joeld42)
Monday, December 29th, 2008 2:13 pm

Woot! My article got featured on gamedev.net:

Better Programmer Art: Or how to fake it as a game artist.

I use a lot of examples from past LD48 games (mine and others), and most of this is stuff I’ve learned through doing these contests. Ironically, in the most recent contest I didn’t have time to replace the placeholder art so it pretty much ignores all of these tips. 

Hope this is helpful to the community. Enjoy!

Jovoc

Porkchop Express – mini-LD #2

Posted by
Sunday, July 6th, 2008 3:30 pm

Big Trouble intro screen

Finished I guess. The minions didn’t make it in. They are so close to being ready but oh well It’s already late. I had a unicorn with a horn-stab move all ready too. ah well.

What it needs is gamepad input. And some scrolling, and the minions!

Windows EXE with C source

Big Trouble In Little China

Posted by
Saturday, July 5th, 2008 10:53 pm

Mini LD 2
Big Trouble In Little China
Jack Burton fighting Lo Pan and Thunder, Lightning, and Rain.

Porkchop Express

Tales from a Cavern

Posted by
Monday, May 19th, 2008 2:11 am

Maybe this is what I should have been doing for the last LD… It took me two days to make and it’s based on the code of my LD11 entry (I didn’t even miss Felicity!)

Download over herely

Making “just a game” was kind of enlightening, since I didn’t have any real technical challenges to overcome and could just get on with content and putting in simple control logic to make it all come together. It’s pretty much an unthinkable project viewed in terms of what I’ve been doing the last few years, but since both development and result were enjoyable it’s a pretty clear hint that I should be doing it more often.

However, I ruin that immediately by having a natural impulse to make some kind of convenient editor/engine which would reduce the need to write copious amounts of replicated-but-slightly-modified code for instance when I want new enemy types etc. I have made these before, and each time I end up spending weeks or months working on it and then never really use it because I get increasingly unhappy with how it’s built. Still, I couldn’t possibly make a game of say 10x the complexity/scope of this one without using more structured code at the very least. And defining animations, scripted events, enemy patterns etc would quickly get tiresome and repetitive to do in code+Photoshop if you have more than one or two types to deal with. The grunt of this game (discounting image loading and input code) is a 1500-line C file, where almost all logic is directly in the main loop – wonderfully spontaneous way to work but of course breaks down with increased program size due to convoluted value/flow dependencies, loss of overview and the need to repeat code.

The fact that I did manage to create this in just two days though, and that I didn’t run into any major hickups along the way, probably says something about suitable code vs application complexity. If I had gone and made “a perfect design” with fancy classes and streamlined algorithms for everything, I would most likely not be done yet. More importantly, I probably wouldn’t even have started since such a small project doesn’t really justify that kind of work. Not without the prospect of a larger product coming out of it, and if there was one I would probably be too intimidated by the thought of that and keep trying to out-think myself in terms of what stuff I’d need to make that “great big thing” work eventually.

I think Derek Yu recently said something about coders being able to “doodle” games like artists sketch with pencil and paper, and that’s probably an important thing. A sketch is never meant to be used for anything substantial, it’s just playing around with the tools of your trade to make something spontaneous and fun. If it turns out nice then you could potentially do it again from scratch but “do it right” and expand on it if you wish – but you should definitely not be doing it the roundabout way to begin with since that would destroy the spontaneity and make it a laborious task instead of a free-minded sketch. When sketching you can only use whatever skills and processes that come natural to you, without considerable planning or conscious mental effort. Of course, with increased experience this set grows larger and some people could probably do advanced class hierarchies without thinking too much about it. All the more power to them.

Since I made this thing in such a short timespan, I have a pretty good overview of all the techniques I used and the bare-bones code needed to make them work. This could provide some extra value when designing larger game systems as I might be able to target my efforts more carefully, and not get overly general or implement pointless things. For trying out pure game ideas though, I still feel that it would be sensible for me to “sketch” in a more streamlined tool… a kind of game maker for sure, but definitely not Game Maker (for the simple reason that I’m incapable of using any tool that is close enough to what I could potentially build myself, which is a most unfortunate condition in terms of productivity… but creating a tool to fill some (possibly imagined) need of my own is just so very rewarding)

Tremble in your boots!

Posted by
Sunday, April 20th, 2008 12:44 pm

Yes. See how far I’ve come. You all don’t stand a chance. Maybe, before time is up, I’ll even manage to make my sprites flip without glitching out in oldfashioned tilemapped glory… but who really wants that anyway? Tilemapped glitches are the best.

screen1.gif

[cache: storing page]