Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - dkh
Pages: 1 [2] 3 4 ... 6

11
General Discussion / Re: The Art of Dying - Platformer made in AGS
« on: October 26, 2013, 03:30:03 pm »
Thanks Cyangmou! Here's the second video talking about how attacking works in the game:



Take a look and let me know what you think! It's getting a bit more interesting now! The next video will introduce the various enemies in the game!

12
General Discussion / Re: The Art of Dying - Platformer made in AGS
« on: October 26, 2013, 11:28:17 am »
surt: AGS supports rendering images to the screen, that's pretty much it, that's all you need! ;) You could just draw one large level background or - and this is what I am doing - write your own tilemap code to render a grid of little tiles! I went for tiles because a.) I love tiles, b.) they are more memory-efficient and c.) it allows me to have that build-in level editor in the game in which people can put together their own levels and challenges if they want to, and share them as well.

13
General Discussion / Re: The Art of Dying - Platformer made in AGS
« on: October 26, 2013, 09:47:11 am »
Helm, long time no see! I'm happy that you enjoy the project. It uses a version of Arne's 16 color palette indeed, good catch. When I make that first mock-up in Pro Motion, I generally start with Arne's palette - and then I just never see any reason to change anything about it :D

14
General Discussion / Re: The Art of Dying - Platformer made in AGS
« on: October 25, 2013, 06:34:38 pm »
Argh, I'm super sorry. It's fixed now. Looks like pixelation doesn't allow embedded youtube videos nor image links (the video thumbnail was supposed to be clickable and link to the video since direct embedding doesn't seem to work).

15
Hey there!

Long time no see, Pixelation! I wanted to share my new project "The Art of Dying". It's made with a software called "Adventure Game Studio" that I've been using and abusing for non-adventure game for ten years now. This is a solo project, meaning I'm programming the entire thing, I'm drawing all the art and animation and design the game. The music in the video is used with permission and is by the amazing Tom Woxom - found on the equally wonderful freemusicarchive.org!

The way I want to present the game is with short video segments: each one focuses on one particular aspect of the game. This first installment talks about the most important game play mechanic in any platformer: movement! Please take a look:









In the video I demonstrate the way I implemented movement, acceleration/deceleration on different surfaces (solid and slippery), jumping, double-jumping and ducking.

Let me expand a little on two of the points made in the video:

- Featuring smooth movement (with acceleration and deceleration) as opposed to hard fixed-pixel movement is very important. The former gives a much more modern feel to your game, the latter is more precise and exact. I went for very subtle smooth movement and put a lot of effort into finding 'correct' values so that you would just barely notice that there is smooth movement in the game but still keep the controls as tight as possible.

- Jump systems are a second, fundamentally important aspect of platformers. There are several different styles that you can follow: There's the simple way. You hit the jump button and it results in the same exact jump every time no matter what. Then there's the Mario way: the jump starts when you push the jump button and gets an upward boost for a limited amount of time if you hold the jump button. That gives the gameplay much more complexity as you can now have jumps that players need to be careful not to overshoot (down-facing spikes over gaps anyone?) and you need to master the regulation of the jump. And then there's the double-jump system that I went for. It's like the first-mentioned primitive jumping system except that you can, well, double-jump. I went for this latter approach because it allows the player to regulate the jumps and makes the gameplay more complex and, at the same time, it looks really cool to double-jump all over the place. Don't ever underestimate how important it is for core gameplay mechanics to just be straight-up dumb fun (and complete unrealistic from a physics point of view)!

I will be releasing a second video very shortly from now which will focus on the various attacks in the game! Please let me know what you think of my project, the ideas I talked about in the video and in this post and ask any questions you might have!

16
Devlogs & Projects / Re: Wings of Saint Nazaire (Large Images!)
« on: October 25, 2013, 05:43:49 pm »
Hey, dkh here, the Programmer working alongside Howie (and Daniel, our composer). Thank you for your support everybody, it means a lot to me. We're definitely considering a kickstarter/indiegogo crowdfunding campaign - we'll see!

And I agree, free-roaming would be amazing for a Wings of Saint Nazaire 2 or something! :)

Also, we now have a complete website with forums where you can reach us more easily. You can also follow the game on twitter @WingsOfNazaire for regular updates!

17
2D & 3D / Re: Bitten by the sidescroller bug...
« on: June 22, 2010, 09:47:05 pm »
It's pretty much fine here, especially when I put it in fullscreen mode.

Looks very nice as always, Howard. Two things:

- I don't like that one big cross star that's in the sky three times. It sticks out too much and looks cheap IMHO. The smaller ones are all fine.
- I don't like how the bright green spots are actually brighter than the stars. Looks weird and artificial to me. I would increase the brightness of the stars to make them pop more and reduce it slightly on those plants (?).

18
2D & 3D / Re: Tutorials?
« on: June 28, 2009, 07:02:30 pm »
I've been trying to read on it online, but everything's so technical or vague or both that I can't wrap my head around the concept/s: what, in layman's terms are diffuse maps, specular maps, bump maps, etc? And what are the differences? how are they different from texture maps?

I'm a programmer so I'll tackle this from a technical point of view yet still try to be clear...

Let's begin with diffuse maps. These are your normal textures that 3d game engines have used ever since they've been around. Each pixel in the texture (often referred to as a texture pixel or texel) lets the engine know what the diffuse color of the object the texture is mapped to is. Imagine a model that is just a wall, a diffuse map would probably contain red bricks etc. If the game engine then draws the model, it will select that texture and apply that to the wall and you'll get your textured wall. Games soon wanted better lighting effects so up to games such as Half-Life and the same generation, artists would "bake" lighting details, shadows, reflections etc. into the diffuse texture, meaning they would probably add shadows to that red-brick-wall-texture to simulate a light etc. This works but with programmable graphics pipeline (via shaders), newer games now want to calculate all the lighting and shading dynamically so that, if for example a light moves, the shadows in the texture map move as well. If you bake those details into a diffuse map, it wouldn't work, the lighting would have to be static or look fake.

The other types of maps are usually telling the engine things it needs to know in order to calculate details on the fly. There are different names and methods around but let me try to cover the grounds here:

Normal maps (often called bump maps too) are these blue-purpleish textures you might have come across before (google image search otherwise). They contain information as to what the normal at a specific spot looks like. If you don't know what a normal is, educate yourself somewhere. Anyways, the normal vectors x, y and z components are stored in the image as the r, g and b channel. As you know, the r, g and b values can range from 0-255, so a normal vector pointing straight up for a flat surface would be 0,0,1 in vector components and 127,127,255 in rgb values. That's why these are so purple, because most normals there point up more or less. The engine then knows for each texel (definition above) what the normal would look like and thus it can fake shadows and lighting.

Specular maps just let the engine know how shiny a certain part of the texture is. Often these are grayscale and a brightness of 0 means that this texel isn't shiny at all, 255 means it's as shiny as can be. So you could have a wood door with a metal handle in one diffuse map and then draw a specular map where all the parts of the wood are almost black and the metal parts are white, like a mask, and, in-game, the wood wouldn't reflect specular light, the door handle would.

Hope this makes it clearer, ask again if you still have questions, I have some additional links and images I could prepare.


19
Pixel Art / Re: [WIP] Cruise ship ... not quite iso
« on: May 26, 2009, 04:33:34 pm »
Maybe this thread can help you. I asked a somewhat similar question - I tried to draw it all in perfect perspective and, in the end, gave up and went for a straight down one instead of the isometric angle.

20
General Discussion / Re: Firefox 3 blurring pixel art question
« on: March 10, 2009, 08:09:21 pm »
It's still blurring the pixels. Haven't found a cure yet either.

Pages: 1 [2] 3 4 ... 6