Looking For An Artist Or Another Mr. Driller Clone


atombat said:
@atombat - I like the idea that player has 2 drills but then it would seem that he can destroy two bricks at a time when stading over their adjacent borders. It's very easily doable in the code but It could cripple the gameplay.

I was thinking of the character being able to morph his robotic hand into a drill, both hands would be too much for the play area. but some scenarios may call for it. Imagine his 1 out-stretched drillarm facing down as his whole body spins like a superman style tornado downwards, coming to a halt, arm raised to the side as he whacks out a horizontal block, it could be a fully charged power-up.

It's good idea for a powerup, but I wouldn't implement any until I have basic gameplay working. Tuning all the variables so It's playable is a lot of work and probably we'll be needing some other gamers for testing. When we have that we can start enhancing the gameplay. But powerups are the way to go.

atombat said:
What do you think about the videos?

I like the 1st one of the in game mechanics. The splash/menu screen is too basic at the moment for me to give a fair comment.

The menu screen was just to show that the bitmap font texts can be handled as any onther sprites.

atombat said:
If you want 47 brick/block types I'll to do as many as looks good in the game, if it is overkill then we can cut back later.

It's not an overkill for the engine but if it's overkill for you, you can do it other way that you think looks good.

atombat said:
I'm interested in making the characters look as vibrant and well animated, if it works in 20fps then I will go with that, if it is 24 like normal animation, then we may compromise?

It can be 24fps, I don't mind, neither does the engine. What suits you best.

atombat said:
Your coding this game just tell me your resolutions that you want and I'll make the characters to your specifications. It doesn't have to be a Techno robot design, this style usually suits pixelart though.

I'm really fine with the techno robot design. I gave general specs in the previous post. I'll sum it up in a while and if you agree (and have time) then you can start working.

atombat said:
I'll add your email so we can chat through gmail?

Write me a blank one so I can add you too. I can send you mr.driller gba rom so you can see how it is done there. If you use linux/windows I can supply you with binaries when I'm done with current bugs and few other things. That way you will be able to test your graphics immediately and play with the framerates (just by editing some text files).
 
Last edited by a moderator:
Hi.
don't know if this of any use to you but I started sketching and it goy out of hand. I ended up with a story in my head obout a monkey in the year 4009 almost gets hit by a meteorite. The thing turns out to be a monolith like i 2001:A Space Odysee and suddenly he realizes that he has to take over the world. To do this he needs some ancient artefacts located around the world. This could be like the "Pants of Power" (in reality it's just a diaper) and other junk. He has to dig through the centuries of disaster to get down to our time where he can find his stuff. Gone Bananas would be an apropriate name.
I did a sketch for a lvl. (it's crude and not nearly finished)
newyorkq.png


Have Fun
Bagera
 
New video available featuring multi-layered parallax scrolling background (just some placeholders) and nearly completed basic game mechanics.
Action still lacking:

  • - Some minor cosmetic changes (talking about mechanics).
    - Destroying crates.
    - Taking air.
    - HUD: gathering points, air gauge.
    - Getting smashed by falling bricks.
    - Serious code refactoring, probably wouldn't be needed if I went with C++...
    - It becomes evident that some optimization will be inevitable because my crappy algorithm are starting to eat cpu. It's < 15% of one core of Core (1) Duo 1,6 but it was half of that... And opengl is doing all the graphics heavy lifting.
    - Particle engine !

Bagera said:
Hi.
don't know if this of any use to you but I started sketching and it goy out of hand. I ended up with a story in my head obout a monkey in the year 4009 almost gets hit by a meteorite. The thing turns out to be a monolith like i 2001:A Space Odysee and suddenly he realizes that he has to take over the world. To do this he needs some ancient artefacts located around the world. This could be like the "Pants of Power" (in reality it's just a diaper) and other junk. He has to dig through the centuries of disaster to get down to our time where he can find his stuff. Gone Bananas would be an apropriate name.
I did a sketch for a lvl. (it's crude and not nearly finished)
newyorkq.png


Have Fun
Bagera

It's great, except that I already decided to go with pixelart. I want to add theming support when the game is finished so this would make a great alternative theme ;) .

@atombat, I made more detailed specs for you and an image with brick shape guidelines so you can start working in your spare time.

Brick specs:

- I use png for all the sprites. Transparency achieved with alpha channel.
- Size: 45px by 45px
- Each can be in a separate file with shape number appended to filename or it can be in a single file in rows (ordered from left-right, top-down). If you choose the single file approach DO NOT draw the grid as I did in the spec file! That way I will be able to slice it easily.
- The image shows how the shapes and their numbering shall be done. It is only an indication of the shapes. Don't treat it as a template or anything. The borders do not fill the whole square only because I wanted the image to be clear. You can do it the way you think is the best.
- Recoloring done with hue rotation. Need four colours.
- Need destroy animation. (can be based on the "whole" brick, shape nr 9)
- A crate brick (without multiple shapes for now) with destroy animation. The crate brick should also have 4 additional states as it cracks. Player has to hit it 5 times to destroy it and after each hit it gets more cracked.
- Air container. Can be animated. Can be a glass container with liquid flowing inside or something like that. Suit yourself.

Main character specs:
- As I written before player's "collision area" must be not wider than 45px. Player can be a bit higher than the bricks. The "collision area's" width should be constant. Everything that sticks out (like the drill when drilling) of this area can and should be overlayed on the bricks if player gets close enough.

- When drilling up or down drill's center should be at the center of player's body horizontally.
- States [animations]:

  • * walking left and right (about 4 - 7 frames, just a suggestion)
    * drilling in all 4 directions (something like 2-4 frames each anim)
    * standing still (this can be one frame, without animation) with his drill pointing in all 4 directions
    * falling
    * being smashed by bricks
    * dying because of lack of oxygen

Background specs:
- There are three layers but we can make it any number cause I made the whole thing flexible.
- Okay, so each layer can have different width and different height. Make the height large enough for it too look good but not too large to save some memory. Only the topmost layer should be 495px wide so it fits the game portion of the screen. The rest of the layers should be wide enough so the image borders are covered by the layer on top of it (each layer is centered horizontally).

I think that's all for now.
 
Last edited by a moderator:
Added new video: Particle engine -exploding bricks + welding+like effect

I haven't heard from atombat recently. I am wondering if he still wants to do this...
Also, I am curious if anybody is interested in this game, because there is no feedback stating if people would/wouldn't like to play this kind of game. Maybe people don't know and I should write about it in some other section?

As for the performance, I tuned things here and there but It became apparent that the code isn't so slow. When I removed the frame limiter (10ms pause after every frame) and added a frame counter it runs at 350fps on my Athlon X2 1,8Ghz.

I am writing a reply and not editing my previous post on purpose. Editing last post doesn't seem to change topic's last activity time so nobody knows anything changed.
 
Last edited by a moderator:
dsh said:
Also, I am curious if anybody is interested in this game, because there is no feedback stating if people would/wouldn't like to play this kind of game. Maybe people don't know and I should write about it in some other section?
I'm following the thread with interest. 1600+ views tells me others are too. :)

Latest video looks great!
 
Last edited by a moderator:
I'm keeping up with the thread too. I've never played Mr. Driller, though, so this is all the more interesting to me. :D (I love good, proper arcade and arcade-style games. Just ask my undying addiction to the likes of Mappy and Puzzle Bobble 2... :p)
 
Still, I haven't heard from atombat, so If he doesn't state whether he wants to participate or not I will be forced to look for another artist. Status "atombat is dead" isn't reassuring (to be true I found it to be quite disturbing when I saw it at first). I am even ready to give up the pixelart and the whole "robotic badass" concept.

New video featuring:

- Code optimization/cleanup.
- Crates can be destroyed.
- Air can be taken - "leave trail" particle engine effect in use.
- If player destroys a brick beneath him and doesn't fall because he's standing on an adjacent brick then he slips (slides towards the empty space) off this brick. Not sure I've actually shown it in the video.
- Bricks which are about to be destroyed because they've fallen blink.

It's very hard to reproduce bugs in this kind of game. I recently (probably due to my recent changes) experienced two SEGFAULTs in a row but I couldn't reproduce it no matter how many times I tried. I managed to get a stack trace the second time but it didn't tell me much as lot of things are done in a somewhat "deferred" manner. It's even hard to notice in what situations the bug occurs because a lot of things are happening on the screen and the levels are randomly generated...
 
Last edited by a moderator:
Looking great already, imo you don't necessarily need a professional artist as it already looks pretty good and somewhat geeky ;) but you probably want to make it look more "professional"

I am very looking forward to this although I did not knew about the Mr.Driller games until you brought this up :)

foxblock out
 
foxblock said:
Looking great already, imo you don't necessarily need a professional artist as it already looks pretty good and somewhat geeky ;) but you probably want to make it look more "professional"

I am very looking forward to this although I did not knew about the Mr.Driller games until you brought this up :)

foxblock out

I want to look it pro or at least close to that but there's also another important reason. When I start a project I spend a lot of time making the graphics, and usually become very distracted by this and stop coding until I have something that looks at least decent. But then I implement a new feature which needs some graphics, so I stop coding again and make them because why waste time on placeholders if I will have to do it eventually? After a while I come to the conclusion that the graphics sucks and I start redoing them from scratch. I don't like the new ones so I become depressed and abandon the project.

The issue with the graphics was always my achilles' foot. Many projects would probably see the light of the day if not this. There were times when I would spend endless hours searching for sprites I could "borrow" or searching for proper game from which I could extract them. If doing 3d it's even worse, because it directly affects the code - I don't choose a model format based on how good it is for my project but based on whether there are models in it that could be used for the game... And so on.

Also, making graphics by someone with almost no artistic skills like me takes a lot of time. I'm too meticulous and I don't know what will look good until I see it, so I have to expriment. Also my knowledge of the techniques is pretty slim. So something that would take a pro 2hrs to make takes me 20hrs and still looks way more lame. I don't think that this effort pays off in any way because I don't need to learn that graphics software (even if it's fun at times) because I will NEVER be an artist and will never ever be fully able to utilize this knowledge.

I hope you will understand something from above because I'm too tired to do any proof-reading. And thanks for input, this community is really great!

---

As far as the search for artist is concerned:
Atombat peeks on the forum but doesn't drop a line so I think he decided not to participate (maybe because of some life circumstances, who knows?). As I want the very basic version finished, preferably, by the end of the month - because I will be quite busy after that, so I would just add features then - the artist position (or as you call it) for this project is still vacant. I took the liberty of posting in other places but if atombat decides to come back before anybody else shows strong interest I will be more than happy to collaborate with him.
---

I've set up a wiki for the project. I will fill it with some more info during next couple of days.
 
Last edited by a moderator:
Hello I sent a reply to your email, been tied down with life, but Im getting back on track, Ive started work on the blocks design and character design.
 
atombat said:
Hello I sent a reply to your email, been tied down with life, but Im getting back on track, Ive started work on the blocks design and character design.

I replied, hope you received it. Sent you wiki account details.
 
Last edited by a moderator:
@atombat: I've already replied to your last e-mail. Today I received another one, but it's exactly the same as before, are you getting my mail?
What's going on?
 
AIR.....GASP...I NEEDS AIIIR...!!...inhale exhale inhale exhale.... phew, thats better :) created this small Air animation test, it's about 30 frames of animation but it looks pretty smooth, hope you all like it, please let me know what you think, feedback would be great, colours can be changed, working on more tiles and brick animation should have them ready shortly.

The Air is 45x45px



 
atombat said:
AIR.....GASP...I NEEDS AIIIR...!!...inhale exhale inhale exhale.... phew, thats better :) created this small Air animation test, it's about 30 frames of animation but it looks pretty smooth, hope you all like it, please let me know what you think, feedback would be great, colours can be changed, working on more tiles and brick animation should have them ready shortly.

The Air is 45x45px




Wow, it looks great. I really love it! Now I need to do some coding...
 
Last edited by a moderator:
I want everybody to know that I'm still on this and doing some coding despite the fact that I have some kind of a nasty cold.

I don't know if I'm doing something wrong but the code is getting more and more complicated (It's often hard to predict what could stop working properly if I add feature X). Maybe it was an overkill to add all this engines (particle, sprite) and making it so modular... Or maybe this is my workflow. I didn't design the architecure beforehand. Instead I'm trying to keep things flexible in case I need to add something and I constantly refactor and refine the code so it meets my needs for the moment.

Also this game is pretty hard to debug, because a lot of things happen on the screen very fast. It's almost impossible in some cases to knowingly reproduce bugs.

I think it would be easier if I could enclose all the brick mechanics in a relatively simple, finite set of rules. For ex. if they could be implemented using a rigid body physics engine. But the mechanics doesn't fully resemble real-world physics. They are highly custom so I need to hand-craft code for almost every possible situation.

As far as catching memory allocation bugs is concerned - consider this scenario:
- A piece of code registers a sprite as a particle. Accidentaly this sprite isn't allocated.
- In the next iteration (frame) game crashes in the particle-processing loop on null pointer dereference.
So all I know in that situation is that I have a particle that is assigned to a nonexistent sprite. But which piece of code added that particle? Obviously debugging data gives me nothing. I have to go through every piece of code that seems even a bit suspicious.

Or this:
- A piece of codes registers sprite as a particle X, telling particle engine to destroy it on animation end.
- Another piece of code registers the same sprite as particle Y, telling particle engine to destory it on fade out.
- Whatever comes first - the fadeout or the animation end - the sprite and the appropriate particle X or Y are destroyed.
But the second particle assigned to this sprite (which is now freed) is still processed in the particle engine which causes in the best scenario:
* that a freed block of memory is accessed
In the worst
* that this not allocated block of memory is written to causing data corruption

In the latter case the behaviour of the program (especially the crashes) become undefined. It is not certain that it will crash in the very moment of writing to the freed block. For example it can crash on any malloc, free, realloc if internal data (linked lists) of libc memory routines were overwritten. If this happens - the origin of the error is virtually untraceable with standard debugger. This is where valgrind comes into play - it will tell you exactly which piece of code caused the invalid write.

Once (not in this project) I had a situation where the program was randomly overwritting a loop's index or boundary variable when inside that very loop (without crashing!). That was crazy, I thought that there is a bug in the kernel at first, because restarting the system sometimes caused the undefined behaviour to stop.

One more, consider this trivial scenario: Many pointers are pointing to the same memory block. A piece of codes frees its pointer and sets it to NULL. But the other pointers still have the same value. So how do we know that it is no longer valid? There's no viable solution in C that I know of. The only way is to keep track of what is happening and don't try to access it if you know it's invalid. And minimize your pointer duplication... ;)

I thought that this stories might be a bit interesting to someone who didn't have much experience with pointer hell. If you want, I have more of them.

Ok, so contrary to the impression you might've had after reading this my code may be not brilliant but it is pretty tight and quite well-thought in general. Such bugs are inevitable to some extent. And of course more refactoring is coming before anyone sees the code! :)

I'll post some videos when I fix some bugs and finish "advancing to the next level". "level advancing" is the moment when you dig through the "level interconnecting layer" and land on new, shiny 100 rows of bricks.
 
hah, I exactly know these problems (I feel with you ;) ).
Though I have to say that I am lucky not having any crashs atm (it seems pretty stable), all I am doing is messing with the physics which drives me insane...
Anyway, yeah duplicate pointers are a bad thing, I keep passing needed pointers as function parameters which mostly bypasses this problem... maybe this helps.
As for bad pointers, well it's good to set all pointers to NULL after memory freeing, and check that if you try to access said data, but I am pretty sure you already do that ;)

Keep up the good work, I am looking forwards to this project :)

foxblock out
 
Sometimes it's better to use references than pointers. This is a C++ program, so don't forget about references as one of your options. It makes it easy to pass mutable arguments without worrying about freeing pointers and whatnot.

EDIT: Disregard that, I suck cocks I'm an idiot.
 
Vorporeal said:
Sometimes it's better to use references than pointers. This is a C++ program, so don't forget about references as one of your options. It makes it easy to pass mutable arguments without worrying about freeing pointers and whatnot.

Are you talking to me or foxblock here? Because I'm writing it in pure C. And even if there were references in C that wouldn't solve any of the problems mentioned above. Passing by reference is just inexplicitly passing a pointer which is then automatically dereferenced when accessing the variable. It has nothing to do with memory allocation.
 
Last edited by a moderator:
For some reason, I thought that this was the Pandora Panic thread. Wow, I really need to start paying attention.
 
Back
Top