|
Socoder -> Concept/Design -> Community Project |
|
| Fri, 29 Dec 2006, 00:57 | |
JL235
|
I had an idea for a community project, one that might actually work. It's very simple and easy to create. It's a Warioware style of game, where people working on the project simply have to create seperate mini-games which would be easily run by a main core program. The mini-games themselves should last only a few seconds and would be run by calling a function with no parameters passed in. When the game finishes it must however return true or false depending on if the player won or lost. As the sub-games themselves are fully independant the creators of each sub-game would have full control over how they are implimented and what actually happens in them. It would also allow for quick creation time as 5 people could make 5 very small sub-games in a week. Perhaps if this were started, it would be best to create it as a single player game initially as a test project. This would also make using it far easier on a pc, but I could see it easily expanded to allow multiple players through only changing the core program and not the sub-games. What are people's thoughts. |
| Fri, 29 Dec 2006, 01:04 | |
magicman
|
Great idea, if it happens im on board all the way. i think this has good potential, and could help socoder!
-=-=- Stuff... Yeah... 
|
| Fri, 29 Dec 2006, 01:51 | |
Jayenkai
|
I once created a minigame scripting engine, about 3 years ago, and everyone around complained that "10 seconds max" was an absolutely insane idea. ... Not enough people had played Wario Ware, back then! I used "Extended Blitz2D DLL" to do most of the graphical work, but the thing was too incompatible with too many systems. It'd be easier to use Blitz3D (or cobra?) with lots of 3D sprites. Mostly because minigames work better with very few images, and lots of rotation! (Every minigame = more images = bigger filesize) The 100% hardest thing to do is to create a method of integrating everyone's games. The "Create a Function Each" thing won't work, since Blitz has a limit to how many includes a program has. (or at least it did when I tried doing it!) The easier way is to create a scripting engine. For informational+nostalgic purposes, here's mine.. MiniMania (But be aware that A it's really not that good, and B it might not work for you, due to Extended Blitz 2D being a bit iffy) Go into /Games/ and open up the .JNKMinigame files in a text editor to see the scripting. It's not incredibly complex, but it does the trick. Remember that keeping the scripts simple helps Blitz read through it quicker. I also changed all commands during file read, so that they became numbers, for quicker "Switch : Case" jumping. Of course, giving up on Blitz and using C++ instead would improve the script speed a whole lot. Since the script would more or less end up the same either way, it might be something to consider. -=-=- ''Load, Next List!''
|
| Fri, 29 Dec 2006, 01:58 | |
|
JL235
|
Thanks for the input, I'll have to take a look at that. I wouldn't want to use a scripting engine. I'd much rather use either functions or perhaps an object-oriented approach where each game was a class and you simply ran a new instance of the class. I would want it to be REALLY easy to add extra games though. Is there really a limit on the amount of includes you can have? That sounds bizzarre, I'll be testing this myself. |
| Fri, 29 Dec 2006, 02:00 | |
|
Jayenkai
|
Remember that to include something you need the source code, and the ability to recompile everything. If you script, you can just chuck in a user-made game, and play. -=-=- ''Load, Next List!''
|
| Fri, 29 Dec 2006, 13:12 | |
|
mike_g |
I'd be up for making a mini game for it.
|
| Fri, 29 Dec 2006, 13:36 | |
|
garand |
Yea this would be awesome. I would be willing to participate.
|
| Fri, 29 Dec 2006, 14:33 | |
|
MikeT |
Howdy folks - hope you all had a good xmas. I'd be interested in getting involved in this - it sounds quite fun. -=-=- One life - live it |
| Fri, 29 Dec 2006, 18:09 | |
|
hyruleknight |
i say the function way is a really good idea if you keep the screen res low and use .pngs or .jpgs to save space also since most if not all of us know B2D we should use it -=-=- i like green haired girls... |
| Fri, 29 Dec 2006, 22:40 | |
|
magicman
|
I agree with hyrule that blitz would be best to use seeing as how we all know it. as for the way of putting it all together i dont really know, i would probibly use to include thing myself, but i dont know if that would be best for this.
-=-=- Stuff... Yeah...
|
| Sat, 30 Dec 2006, 00:03 | |
|
JL235
|
Ok, I'll have to get started on it. But why don't we start setting some rules. Fisrt were using Blitz3d. Personally I'd rather use Ruby, and maybe Blitz Max would be a better choice because of it's graphical capabilities, but everyone here knows Blitz3d so it would be crazy to use anything else. So that's what we'll use. As I see it being the easiest method, we should simply have each mini-game written on it's own .bb file and included. So everything you need for the mini-game should be written into that one file. It must be run from a single function call. This doesn't mean you cannot have multiple functions, but that I should only have to type 'HyrulesMiniGame()' without any other code and it'll run. That function will also have no parameters. The game must return true or false when it ends, to state if the person has won or not. You should also presume before your function is to be run, that Graphics3D has been set to 800, 600 and is windowed, and that the backbuffer has already been set as the default buffer, the randomnumbers have been seeded as milliseconds and that the mouse is hidden (you could unhide it for your game if required, but hide it at the end). In terms of design, keep the game idea quick, short and simple. But anything is allowed. I'd love to see lots of completely different genres used, like one game could be like Starcraft and then something like a battle from Final Fantasy, and then a shoot-em-up bit. It'd be so cool if it went those three within a minute. For now we should also just try to get this working, rather then trying anything fancy and making it look nice. For this reason I think it should also be single player. Since the mini-games will be so loosely coupled from the mane game (they are only joined by a single function call) it would be VERY easy to change the core game itself in the future. Currently there won't be a limit on the size of your mini-game, but keep it small, but use .png instead of .bmp (or .jpg if you really want Hyrule). Also have all your files kept in their own folder with your name on it, so for example you'd load 'hyrule/background.png' rather then just 'background.png'. This will keep everyones files seperated and ensure we don't have 20 files all named 'background' in one place. You might want to also preload all images in the include file, so everything is loaded when the game starts. This may change in the future, but for now it'll ensure the game doesn't slow down when loading in a mini-game. Try not to do anything which will cause slowdown or loading times, like large amounts of 3d. Finally you may want to make several alternate versions of the same game (getting progressively harder if possible). If so, you might want to try to use the exact same graphics on each version, but having multiple variations means the exact mini-game will not be run multiple times (or not as often). |
| Sat, 30 Dec 2006, 01:42 | |
shroom_monk
|
I might join in if there are any 2D games.
|
| Sat, 30 Dec 2006, 01:45 | |
|
JL235
|
I'm only including 3d so people could use 3d. Personally all my mini-games will be 2d.
|
| Sat, 30 Dec 2006, 01:46 | |
|
shroom_monk
|
Ok. I'm probably in then.
|
| Sat, 30 Dec 2006, 02:30 | |
|
JL235
|
Also, if your using types or adding anything into an array make a function to clear all your types out at the end of the function. Remember your minigame will need to be able to be called multiple times in a row. And becareful if your using globals and types, try to keep the names destinctive to avoid people create types and globals of the same name. |
| Sat, 30 Dec 2006, 10:27 | |
Phoenix
|
If every function returns true/false, how do we determine which player won or lost in multiplayer?
|
| Sat, 30 Dec 2006, 10:27 | |
shroom_monk
|
I thought Diablos said that there would be no multiplayer... |edit| In fact, he did: DiablosDevil |edit|
 For this reason I think it should also be single player. -=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom! |
| Sat, 30 Dec 2006, 10:31 | |
|
Phoenix
|
DiablosDevil
...but I could see it easily expanded to allow multiple players through only changing the core program and not the sub-games. |
| Sat, 30 Dec 2006, 10:31 | |
|
shroom_monk
|
That was then, and this is now. You may have missed by edit above. ^^^
-=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom! |
| Sat, 30 Dec 2006, 11:32 | |
|
JL235
|
First, I think this should be a single player game initially. Simply because it's easier. But because the mini-games are completely abstracted from the core game, I think it would be easy to add other players. When I suggested that initially I was thinking in terms of offline multiplayer. But to decide who has won or lost would be easy. You'd simply say who was playing, run and store the result of the mini-game, change the selected player accordingly (i.e. loose a life) and finally select a different player to be playing for the next frame. |
| Sat, 30 Dec 2006, 12:48 | |
|
Jayenkai
|
Yeay for Bishi Bashi.. Didn't think anyone remembered that one! The Wario Ware before Wario Ware... And on the Playstation of all things! Single player would be much easier, but if Diablo (I'm assuming Diablo will be building the framework) got a simple network connection setup with easy "Start Game, Play Game, End Game" stuff, then adding more games would be easy. But yeah, Single is easier for now. Now, I'm too sure, but if you keep setting up arrays, and types, then freeing them every game.. Could that possibly mess things up, at any point? A big single multipurpose array (800,600,100, enough for 100 screens of single pixels, and pretty much anything else really) would probably work out better. Maybe not the best choice for ease of coding, but it's one less thing for Blitz to have to deal with... .. Assuming you're even using Blitz. Any thoughts on that? -=-=- ''Load, Next List!''
|
| Sat, 30 Dec 2006, 13:27 | |
|
JL235
|
Why would I have an array the size of the screen? Where has that come from?
|
| Sat, 30 Dec 2006, 13:36 | |
|
mike_g |
If we use arrays we could allways use local ones. I just found out that you can do that in Blitz. |
| Sat, 30 Dec 2006, 14:30 | |
|
Jayenkai
|
Tron.... A minigame might be tron... I dunno, there's no harm in making arrays too big, just incase. You might have 800 bees, or 800 lemmings, or something. 800 particles * 600 explosions. Theres lots of things you can do with it. -=-=- ''Load, Next List!''
|
| Sat, 30 Dec 2006, 14:36 | |
|
JL235
|
it would be far simpler to either have global arrays with good names or local arrays.
|
| Tue, 02 Jan 2007, 01:17 | |
andrewsoltan
|
Hmmmmmmm. Interesting, so interesting that I think I going to join in. Time to rack my little brain for ideas. And by the way, can the game only return true or false as that means you can't really have scores or lives or anything else other than win or loose. |
|
|
| |||
|
| ||||