Looking For An Artist Or Another Mr. Driller Clone

[bienmexicano]

Hi, i was reading about your project and i kinda got an idea about D-Man so i did this ,i hope it helps.
cheers!

well the idea was to made an sprite but i made it 64x64 and is so damn small, i just have to resize it:

damn well this is a larger one, but so damn blur, well anyway this is the general idea:

 

[hackroid]

well the idea was to made an sprite but i made it 64x64 and is so damn small, i just have to resize it:

I love your character design, Ima bit jealous too I think the sprite proportions are a bit smaller than your dimensions at 45x45px with a bit of overhang for the drill, but this is up to dsh to finalize, great character design though. I made my character and air animation 45x45px. Im just working on the brick tile animations at the momment. Great for you to join in

 

[bienmexicano]

well the idea was to made an sprite but i made it 64x64 and is so damn small, i just have to resize it:

I love your character design, Ima bit jealous too I think the sprite proportions are a bit smaller than your dimensions at 45x45px with a bit of overhang for the drill, but this is up to dsh to finalize, great character design though. I made my character and air animation 45x45px. Im just working on the brick tile animations at the momment. Great for you to join in

well i'm glad you like it, if is 45x45 then i think i can work it out.

 

[dsh]

@bienmexicano: I like your sprite very much and I appreciate the work you put into this.

However, atombat is already on the sprites. I thought it was pretty clear. I suspect he is already working on the player. Firstly, It would be a shame to discard his hard work. Secondly, we have to maintain consistency as it comes to style, coloring, etc. I don't want to be rude or sound arbitrary, but we can't have multiple people duplicating each other's work.

I would be happy to have more people on the project, but we can't do this without communication. If you want to work together (meaning atombat and bienmexicano) I have no objections. Just split the work so it is clear as to who is doing which part and sort out a common style so we have consistency (I can create a wiki user for bienmexicano, if you want). To sum up, It's entirely up to atombat to decide if he wants bienmexicano's help.

Again, every input is appreciated but, obviously it's impossible to include every piece of work somebody's done. If anybody wants to join the project then it would be wise to ask what is needed to be done before starting any work on your own.

I'm open to any suggestions, though.

 

[hackroid]

Right the only problems I can see that I think dsh pointed out is in keeping an overall coherent look and feel of the Design, It may be great to have a selection of characters with differing abilities to choose from, like Street Fighter, Soul calibur etc... but will this be harder on dsh's coding? The Character styling would have to fit in with each other, I've not come up with a final design myself yet, just some main character tests. If bienmexicano can work to dsh's specifications, and dsh likes the idea of several main characters with differing abilities, then all we need to do is come up with an overall design plan to keep to.

 

[dsh]

So as far as the coding is concerned - I can code anything for this game, it is just a matter of time. But take into account that making a playable game (in terms of gameplay design) is very hard even without all the additional features. It requires playtesting and a lot of effort to finetune the mechanics. It's not like saying, we add feature X and Y and do it right away along with all the graphics. We have to test first if it is playable.

I think that the best approach would be to make the BASIC thing playable (one player, one gamemode, no powerups), then add features. What if you make the graphics beforehand and then it turns out that we can't include it? All hard work for nothing?

I like all the features you're all talking about and I would like to include them, but one step at a time.

Right now the coding progresses very slowly cause I'm quite ill (cold) and have other things going. Probably from the next month I will have a lot less time to code this. Of course I want to finish this project. And I won't give up for any (non-life threatening) reason. But It probably won't be ready so fast.

If you have the time and don't mind that your work might not be useful in the end then you can do it. I promise that I'll consider including it at proper stage of development. Right now, I just can't say anything for sure.


I really like the incremental development process approach. I think it really fits the opensource/non-commercial projects (because we don't have deadlines, we're unpaid, and motivation varies from person to person, from time to time). This way, at each major stage, we should have something that is playable.

 

[hackroid]

This is perfectly understandable, simplicity first, so as not to overcomplicate matters/game mechanics, then all the other game elements can be added when a working playable version is created. So if you want to continue with the characters that are already created then when the game is playable you can add bienmexicano's characters, this is simpler, if it's clear for bienmexicano, that we are just working with the first basic characters created, for now, then add his characters when the time is right, then this is cool by me. Back to creating those blocks

 

[dsh]

Okay so I nearly (each level will have different background and a "starting" image) completed level advancing. Other than that - I've squished a lot of bugs and done a lot of refactoring so the level changing is possible. The code was made cleaner, etc.
This was one of the hardest unfinished parts so now it can get only easier (I hope).

Here's the video. Check out how the bricks from the passed level are discarded and the chain reaction destroying the interconnecting area.

 

[bienmexicano]

well i'm cool if you don't need to use it, i thinkk that the game sounds awesome, the truth is that i don't know much of pixel art myself.
I'm ready to help if you guys want it, i'll be in touch if you require ideas for diferent looks and styles for the game.

 

[dsh]

Small progress report:

• 
  - Fixed and improved some code here and there.
  - Fixed player animations (they weren't changing correctly) - it was a feature rather than a bug
  - I added a 150ms delay after hitting drill key and before the brick being destroyed - this was a must for a couple of reasons.
  • 
    * This allows the drilling animation to finish before it is changed to something else.
    * Adds difficulty to gameplay - without this you could just drill down lightning fast.
    * 100-150ms lag is barely noticeable if you're not aware it's there, and rather adds naturality to gameplay than cripples it (believe me - I studied the behaviour in the original series)
    * So now the drilling animations shouldn't be longer than 150ms with reverse! (reverse means that the animation is played forwards and backwards one time [drill moves here and back])
  - Background now changes with each level (we can and should discuss this because we would need more artwork).
  - Before each level there is a "starting picture".
  - I rewrote the core of level generation algorithm (it took a few tries before I came up with a better one). The previous one was crap.

How's the work going, atombat?
If you came up with a colour design then you could post a basic "colour sheet" (or however it is called) so somebody else (maybe even me) could get started on the bitmap fonts (possibly, I could just improve some existing mono-coloured).
Or do you want to make them?

 

[dsh]

I've tried to compile it on my second machine but a strange thing happens (it was working here before).
Compiler complains:

input.c:9: error: ‘SDLK_LAST’ undeclared here (not in a function)

I've got everything included:

#include "input.h"

#include <SDL/SDL.h>
#include <SDL/SDL_keyboard.h>
#include <SDL/SDL_keysym.h>

#define MAX_KEYS SDLK_LAST

static bool keyState[MAX_KEYS];
static bool quit;

I checked SDL_keysym.h and nothing's changed - SDLK_LAST is still declared there as it was so what's wrong?

 

[hackroid]

Hello, trying to get the blocks to work with each other, tried a couple of different layouts so the middle blocks will fit with any end blocks, just trying to get them finished now, shouldn't be too long now before I'm done. I don't know if you'll like the block colours I'm using, and whether you'll want to change those colours so I can't really layout a colour guide yet, Dark purples, Golden yellows and dark pink/reds and turquoise/light blue seem to be the area it's going in for Main character, Background and fonts, warmer colours at the front/foreground, if that is any help?

 

[dsh]

Okay, I'll just wait till you have the blocks ready

 

[hackroid]

Hello, just giving you a status report. After trying different block layouts with differing degrees of success I'm going to finish off what I've done and post the results, I don't think it's the best I can achieve but I've never done blocks before, and matching up the corners can be troublesome, so in the next day I'll just post what I've been working on for your feedback and critiques. Cheers.

 

[dsh]

Hello, just giving you a status report. After trying different block layouts with differing degrees of success I'm going to finish off what I've done and post the results, I don't think it's the best I can achieve but I've never done blocks before, and matching up the corners can be troublesome, so in the next day I'll just post what I've been working on for your feedback and critiques. Cheers.

I'm really looking forward to that.

I wasn't able to do much work for some time cause I had to fix some things with my uni. I have been also finishing a small commercial enterprise which will hopefully allow me to get my hands on the pandora.

Nevertheless I've made a small progress since the last post. Among others, I moved the font rendering code from gfx backend to sprite engine. I rewrote it completely so now it uses LUTs and is way faster. Now multiline font tilesets (a lot of them can be found on the net, for ex. they come from amiga demos so the authors will likely give us rigts to use them) can be used.
I decided NOT to go with different aspect ratios and gfx automatically fitting them. Instead the default resolution will be 800x480 and if aspect of your display is smaller then you will have those well-known black borders. Of course you can freely
change the resolution. The graphics will be automatically upscaled/downscaled. If you choose a resolution greater than nominal then, probably things won't look any prettier (it's all raster after all) but you certainly get smoother movement (if your comp cope that is)!

Next, I decided to add support (not done yet) for individually paletted PNGs. I found out that OGL can draw/store paletted textures so we can save a lot of memory and bandwidth. It's great because we have to preload all game mode graphics when loading the game screen. I don't want them to be loaded dynamically because this could cause a serious lag on some systems (presumably even pandora [read here about this tx swizzling done by CPU]). The only drawback is that palletted textures need a mask and 2 calls with different alpha settings to draw. But I think that it's still worth it.
UPDATE: I'm reading stuff and it occurred to me that paletted textures in OpenGL are a legacy of old times and I doubt that new chips are optimized for them. Obviously they require different texture processing and one additional mem lookup for each pixel so in an unomptimized chip they probably could seriously degrade the performance. And the memory gain isn't as big, because we have to store the mask, and if bitmasks are not possible then each mask pixel takes a byte. Then we gain "only" 50% compared to RGBA (not counting the palette data). Still, I've done some calculations with the new sprite sizings and we probably won't need more than 30megs (rough estimate) of vram for the game screen sprites. This quite sounds acceptable, doesn't it?
These are just some educated guesses so I reserve the right to be wrong. I don't feel like diving into the details.

What do you say about common, shared internet leaderboard and stuff?
The only problem is with validating sent-in results. It is impossible to make sure they aren't forged. But we can make it hard enough that an average script kiddie will find it not worth enough to exploit. I thought that maybe everybody who wanted to setup his own leaderboard server should distribute a binary which has some gpg keys hard coded. And the game could send a screenshot so the submissions could be checked "organoleptically".

Wonder, how does World of Goo do it... Probably hardcoded keys. Or do you have a better solution?

Of course the code will be under GPL. But the source won't have the keys for specific servers. You want net competition... You use binaries provided by 3rd party.

 

[dsh]

I haven't done much recently but decided to give you a peek at what I have:
video featuring main menu and in-game hud concept + some improvements.

 

[hackroid]

Holy crap that in game menu is freakin' amazing, seriously Also, Ima nearly finished.

 

[BackAssward]

Looks great! Two things: 1. I assume him being crushed is in future plans? 2. Ok, sorry, but pastels?

 

[dsh]

Looks great! Two things: 1. I assume him being crushed is in future plans? 2. Ok, sorry, but pastels?

Yes of course he's being crushed, but God Mode is better for debugging, don't you think?

All of the graphics in the videos are placeholders, atombat is working on the final ones.
The second set of bricks is just the first one but inverted colours.