Pandora League Dodgeball - Help Wanted

[Prometheus]

Milkshake, I didn't mean to disinclude you... anyone really, stand up, I'm bad with names (and a bit drunk).


Gruso, Prometheus, Sony, mods or users with 2k+ posts...

Hahaha, I'm really not special - just a forum janitor! :lol:


If you really do need the handle or such to use in-game, though, you're very welcome to do so.

 

[milkshake]

sure I dont mind if you use my handle just make sure im badass in the game

 

[Link]

I'm game for the game, don't forget Askarus. Who else has L2/R2 buttons?

 

[Zuk]

If I get enough responses, maybe there could dev team and a forum team...


EDIT: If we had a mod team they could throw ban hammers.

 

[pmprog]

Stick me in if you need the chars

 

[Binky]

Maybe Hak should randomly appear and throw a fake ball onto the court, just to be annoying? He's almost as well known as them as got >2k posts...

 

[moz]

^ Or his head could be a ball


Oh the fun I'm going to have spriting you all, I won't be too mean, I promise

 

[Tensuke]

If there's a forum team, and there's not a Quasist character, I'll be very sad. :rolleyes:

 

[Binky]

Maybe the annoying character should have a really strange name, and only go away when you type h-a-k ?

 

[Prometheus]

Come on, guys, you're being mean. Not fair.

 

[Binky]

Come on, guys, you're being mean. Not fair.

All right targeting people isn't nice, but maybe there should be a generic troll or something - especially as it would fit the theme nicely.


EDIT: had a quick go at a pixel-art trollface:

 

[Zuk]

Progress is going a bit slower than I had hoped. Between work, my other hobbies, and me adding in features every time I start programming a new portion, it is taking a while. The good news is, the game is getting a lot better for it.


I just massively upgraded the animation back-end and built-in a system that would allow adding user created teams. Before, there was just one sprite mirrored left and right for every "animation cell", if you will. Now there is the possibility of 6 different sprites per "cell" to accommodate the combinations of facing up, down, to the side, left, and right. You can specify it to mirror, if you want, but you have the option to set them separately. I also made it so you can define how many cells are in an animation and how many frames that sprite will be displayed before moving to the next. This would allow for much smoother animations if one were so inclined to make them. You can also edit where the ball is in relation to the character that is holding it for each cell.


This made the character config files terribly complicated to edit by hand (unless you programmed it ) so I also plan to write a character/team editor. I don't even want to write all the files by hand for the all the default teams. LOL! I'm planning to make it a fairly point and click affair. No sprite editing, just defining sprite files, their attributes, and spitting everything out into a pretty, distributable form. Sprite editing would have to occur with whatever editor of your choosing.


I think the switch to 8-Bit res sprites put Moz off the project. He said he wasn't getting the hang of 8-bit and I haven't heard from him in weeks. I don't want to start looking for a new spriter until I get more of the new engine finished. I'd like to get something semi-playable to hand a would-be spriter so they can see their work in motion.


The attached picture is the build that has been keeping me from coding off and on for the last week. Of course I had to thoroughly play test it. The parts for his brother will be showing up soon (a similar Ken Image with red buttons/bat). It's a Foe Hammer case with an MC Cthulhu board. It made me realize how much I suck at Street Fighter Vs. Tekken (or any other fighting game) with a stick. I do love it for MAME, though.

 

[foxblock]

Hey there, somehow managed to miss this project until now (probably because it's in General Talk, where I usually don't look at closely due to the amount of topics I don't care for - Developers corner would be the way to go, then again the traffic is much lower there).


Anyway, just wanted to wish you good luck with the project. I have not played a virtual dodgeball game yet (ever, oh my gosh), but it looks fun and with the added bonus of some community characters this could be extra charming.


So keep up the good work.


An idea for characters: What do you think about including some characters from "Pandora Original" games?


For example I personally could convert some sprites of my

https://www.youtube.com/embed/5C-RK-zb0dw?feature=oembed or another character I missed (which should at least be from a game started in the GPH/Pandora community).
In my eyes these should be created by the original author and will obviously not perfectly fit the style of the game (or could be adapted a bit once you have settled on a style), which will look awesome regardless (or maybe just because).


I think they could serve well as unlock-able characters and especially looking a bit out of place will make them shine. Also seeing some currently non-sprite characters (like the PaperWars soldier) imagined as 2D sprites should be fun.


Apart from that I sadly have too much on my plate to offer my services as a full-time artist (though as I said I can personally convert my characters, if you give me the necessary info). You are better off with anybody else anyway


Good luck with the project and tell me what you think.


PS: Necessary info on the sprites would be: Size of a single sprite (min and max in pixels), states/animations needed, desired frames per second, format of the graphics (file format and layout) - best thing would be a reference sprite sheet to paint over.

 

[Zuk]

@ foxblock


Right now I am shooting for 60FPS, but I am writing everything so that it can be played at 30FPS without noticing a difference. The engine will handle PNG with alpha and/or tranparent color key for sprites. 30 or 60 FPS without difference was decided upon because A - I don't know how netplay will slow it down and B - I don't know how fast it will move when finished regardless of platform and C - I wanted as many choices as possible. Max sprite sizes are *probably* 32x32. haven't exactly setteled on that yet. Everytime I settle on it, I think about the possibility of a big freakin' player that takes up a lot of the screen. That intrigues me.


I decided to go with a base resolution of 240 on the Y axis and pixel double from there. 240 works perfectly on Wiz and Caanoo (both of which I own) and double is the Pandora. I haven't found a way in GLBasic tha takes a specific resolution and resizes it to the screen. If you have seen one, let me know. Otherwise, I am doing pixel doubling in mem to resize the sprites and everything else on the screen so it runs at native resolution on whatever platform, as long as it's a multiple of 240.


I am literaly writing it so that you just have to uncomment the target platform line for your platform, or add in the line for the target platform and set all the specifics for it. This works well because it's easy to port to any platform GLBasic complies to (which is many), but it also makes things a bit (LOT) less optimized. There is a lot of math going on for the privledge of porting that easily. That's also why I'm going with the 30/60 FPS limit. Everything is caculated at the base resolution and then the graphics are scaled (pixel doubled, tripled, quadrupled, or more).


I'm totally open to whatever characters you want to put in! That's why I am going with the make your own team thing. Pandora is open and so will be Pandora League Dodgeball! I think I am going to make it a team versus single characters, though. That doesn't mean you can't modify the source to make things happen. I will include the source in the PND, the Wiz, Caanoo, Windows, and Linux versions (which technically should be the same code) and just readily available. Those are the only versions I plan to compile for, though. It should be trivial to hack in controls and compile for other platforms. I am commenting in my code to the point where "real" coders would probably get upset. LOL! I have looked through other people's code before and got upset that I spent hours decoding their variable names just to realize they did something simple. I want to make things as straight forward as possible for novice or advanced coders.


At the beginning of every type and function there is a description of what it does.


Above or to the side of every line of code there is a description of what it does or why it's there.


EVERY variable is PAINFULLY descriptiive. I am getting tired of typing in those names. LOL!


I chose GLBasic for this project because I have been programming in one basic or another for the last 30 years. Next time I'll probalby choose to learn C++ because I see the limitations now (mainly resolutions). This is the first game I have programmed with real graphics in real time. I programmed some B.S. ASCII games on a x286 (or something similar) in line basic and saved on a bernuelli drive when I child, but I want this to be really good. It seems like I am getting very good results very quickly in this format.


If you haven't played any dodgeball games, I suggest Super Dodgeball on the NES. That's the basis for this game because it's a favorite of mine. It's so simple, and yet painfully brutal. I hope I can do it justice AND one up it. As I add options, I see why they kept the original so simple. There is a LOT more going on with mine than there is with the original. That leads to a lot more problems that I haven't completely solved yet. I bought two Pandoras originally. One pre-order upgraded to premium then another premium (for the purpose of writing this as a net game and testing). I just got a 512 meg German so I am sending one 256 meg to my brother. Hopefully I will be able to play him at my own game soon. WAH HA HA!!!


Dude, finish up WANDOR!!!! I've wanted to play that for what seems like years now.

 

[Zuk]

I realized that I wasn't quite clear on what it was doing graphics-wise. It goes like this:


1. When graphics are loaded, they are resized to approprate resolution.


2. Gameplay calculates the position of each sprite at 320x240


3. When drawing occurs, the positions of the sprite are translated from 320x240 to the target resolution


Speeds are set at pixels of movement per frame @ 60FPS 320x240, so if it is set to 30FPS the pixels per frame are doubled and the actual position on screen is again handled by the resolution translation. As far as I can tell, GLBasic only has a frame limiter without any way to frame skip and that's why I do it this way.


I also haven't found any way to draw at one size and then scale the back buffer to the screen. There are some sprite resizing functions built into GLBasic, but they seem to put the sprite through some sort of bluring filter. I wasn't liking the results so I just pixel double in memory during sprite load. That keeps everything crisp and 8-bit looking.


It seems like I might be missing something because it feels like I am doing it stupidly to work around these issues. I've only been using the online manual for help or research. I haven't hit any barriers yet that have kept me from getting the speeds I want so I keep marching on.

 

[foxblock]

Well I figured at the beginning of the match you just select three characters of a pool, like in a fighting game.


In any case, if you decide to put in Pandora video game characters there should be a bunch of them, so best thing to do probably would be contacting the authors of the projects mentioned above when the time is right (aka the game is shaping up and almost done).


(and I am not sure if I understood your part on this correctly, so to clarify: I think those should also be included in the game by default as few people will bother downloading extra characters, which kind of would be a waste of work).


In any case, the artists need fixed guidelines to work with, so at least the size of the sprite should be set in stone.


Also: The game might run at 60 or 30 FPS, but do the animations need to? I rarely do anything over 10 FPS, just because you can't really tell the difference in motion anyway (in most cases) and it's a lot less work.

Dude, finish up WANDOR!!!! I've wanted to play that for what seems like years now.

Yeah, thanks... however, it's at the bottom of my todo list atm for various reasons.

 

[Zuk]

The teams are comprised of six characters. You pick your three main characters to go into the main field and the rest go on the outside of your apponent's side. I would love to put characters in from other Pandora games by default. I also want to make it so you could make any team you want. I'm thinking the team editor will be able to spit out a PND team installer when all is said and done. This would allow for putting the team packs in the repo, so hopefully people would download them.


I totally agree that there needs to be standards for the artists to work off of. I'm just not at the point where that's 100% nailed down yet. I think writing the editor will set my mind on 32x32 max. Most of the sprites I'm using now are 16x32.


I honestly don't know where the point of diminishing returns happens on animation. I *think* I remember reading somewhere that cartoons are drawn at 12FPS and then frame doubled to get 24. The sprites I am making (read: tracing over and coloring in) really only have two, and a very few have four, different sprites per action. With my sprites, I could even probably scale it back to 15FPS without much notice. I haven't tested, but I think the ball will move noticabley smoother at 30 rather than at 15. I do agree that 60 is probably overkill, but why not shoot for the stars?

 

[foxblock]

The teams are comprised of six characters. You pick your three main characters to go into the main field and the rest go on the outside of your apponent's side. I would love to put characters in from other Pandora games by default. I also want to make it so you could make any team you want. I'm thinking the team editor will be able to spit out a PND team installer when all is said and done. This would allow for putting the team packs in the repo, so hopefully people would download them.

Sounds good.

I totally agree that there needs to be standards for the artists to work off of. I'm just not at the point where that's 100% nailed down yet. I think writing the editor will set my mind on 32x32 max. Most of the sprites I'm using now are 16x32.

Well you probably want to keep the collision area the same for all characters or some would have a advantage or disadvantage (or you would need to balance that out with a stronger throw, etc.), so going with a fixed 16x32 for the sprites seems good to me.


You could make so characters can be up to say 18x34, but all pixels outside the centre 16x32 area are not taken into account for collision detection - so there is some room for single hairs sticking out or certain frames being slightly larger.

I honestly don't know where the point of diminishing returns happens on animation. I *think* I remember reading somewhere that cartoons are drawn at 12FPS and then frame doubled to get 24. The sprites I am making (read: tracing over and coloring in) really only have two, and a very few have four, different sprites per action. With my sprites, I could even probably scale it back to 15FPS without much notice. I haven't tested, but I think the ball will move noticabley smoother at 30 rather than at 15. I do agree that 60 is probably overkill, but why not shoot for the stars?

I am not saying the game should run at 10FPS or something like that. The game obviously should run at 60FPS (especially if you are only calculating collisions every frame, which it sounds like you do) - usually I would even advice to run the update loop (collision, movement, etc.) on a much higher framerate (500 or 1000FPS) and only update the screen (render, flip) 30 or 60 times per second.


That all does not mean the sprites have to be animated at the same rate, you could easily just display a new animation frame every 6 screen frames, which would give you a sprite framerate of 10 FPS.


So, what I am trying to say is, keep the animations separate from the global update loop to allow assignment of custom framerates per animation. (In Penjin for example every animated sprite has its own timer to keep track of updating the animation, totally independent of what framerate the game is running at. So in Greyout I have some animations running at 10FPS, some at 15, one even at 8, while the whole game is running at 60FPS).

 

[Fzero]

...just to quickly interupt the dev talk, this game looks great and I'm loving the idea of OP team for the finals team, nice variety of ball sprites too. This id like to play when complete, nice work

 

[Zuk]

...just to quickly interupt the dev talk, this game looks great and I'm loving the idea of OP team for the finals team, nice variety of ball sprites too. This id like to play when complete, nice work

Thanks! It's still a ways off yet, though. When I get something I would consider alpha I'll release for bug finding. I would imagine at my current rate of coding that it will be at least a month before that happens.