A Community game to be ready for launch! VOLUNTEERS NEEDED.


Ill still go with the Wario Ware, mainly because Ive already got one coded some, and just need to improve it.
 
So.... Something along these lines? (its basically just chromozome with all the code removed...)
 
Hey,
I wouldn't mind contributing with a couple of mini games. Are there a final framework to use yet?

Personally I would care for Wario Ware type of mini games. It seems IMO more appropiate to the name PandoraPanic. And if this is supposed to be ready at launch, we should better get working now.
 
pstudio said:
Personally I would care for Wario Ware type of mini games. It seems IMO more appropiate to the name PandoraPanic. And if this is supposed to be ready at launch, we should better get working now.
Fair point. You can save a little bit of time with the simpler games (not as much as you might think), but more importantly the wrapper engine should be easier to write (no multiplayer support for starters). Work on Pandora Panic for the launch; later on the engine can be extended to make the larger multiplayer version, Pandora Party...
 
zacaj said:
So.... Something along these lines? (its basically just chromozome with all the code removed...)

Hi, I'm the other Pirate Games guy...hats off to you, someone else can understand our Code :D

Pretty cool for a quick throw together. I will definatley be adding 'something' to this game...got a few ideas but we'll see what I decide on
 
zacaj said:
So.... Something along these lines? (its basically just chromozome with all the code removed...)
That's the basic idea :)
And the only thing the minigame states need to report back are if the game was passed or failed. I'll be using index 4 of the variables vector to store this. 0 is fail and 1 is passed.

I'll post a framework specific for this project soon so you don't need to hack CromoZome to pieces, but well done! Love the catching mini-game and thanks for using all the stuff the engine gives you Zacaj!
 
Got another thread created at gp32x just to make sure everyone can link to the base code and such...is they want to Here
 
Last edited by a moderator:
So, are you planning for each minigame to be its own self-contained & compiled executable?
I'd strongly advise against going down that path. It will severely limit the number of developers available for minigames.

It would be much more preferable to call an interpreted script engine (say Python/Pygame), and only require the minigames to provide code for their game routine. I think you're better off putting more work into the framework so that you end up with a better minigame library.

Minigames could probably get away with implementing 3 functions:

init(game_time, difficulty)
Set up the minigame, load resources
- game_time: duration in seconds for this round (eg 10 seconds for first round, decreasing each round thereafter)
- difficulty: easy, medium or hard; minigame can adjust behaviour as it likes

run(remaining_time, [gfx_window])
Process the current frame and draw to the screen
- remaining_time: time left before the end of the round
- (maybe) gfx_window: drawable area provided by the engine (allows the engine to draw timers, score etc outside the game window)
- return true if player has won, if applicable

finish()
Determine if player has won
- return true if won, false if lost
 
Id reccomend each game has its own source file, where the author can declare variables and stuff, and he makes a GAMENAME_init,GAMENAME_update,GAMENAME_input, and GAMENAME_end
init could take things like screen res,
update would take things like fps,
input would take a class with the current states of buttons,
and end would return a score
 
Kagato said:
So, are you planning for each minigame to be its own self-contained & compiled executable?
I'd strongly advise against going down that path. It will severely limit the number of developers available for minigames.

It would be much more preferable to call an interpreted script engine (say Python/Pygame), and only require the minigames to provide code for their game routine. I think you're better off putting more work into the framework so that you end up with a better minigame library.

Minigames could probably get away with implementing 3 functions:

init(game_time, difficulty)
Set up the minigame, load resources
- game_time: duration in seconds for this round (eg 10 seconds for first round, decreasing each round thereafter)
- difficulty: easy, medium or hard; minigame can adjust behaviour as it likes

run(remaining_time, [gfx_window])
Process the current frame and draw to the screen
- remaining_time: time left before the end of the round
- (maybe) gfx_window: drawable area provided by the engine (allows the engine to draw timers, score etc outside the game window)
- return true if player has won, if applicable

finish()
Determine if player has won
- return true if won, false if lost

Actually, No. Each Minigame would be a seperate state(i.e. Source file, or Small collection of source) and a state manager would handle switching between games, the final framework is going to be provided soon, which will include zacaj's example game. Showing how each game could be implemented. You can test you own minigame locally using the framework provided but the final collection would be compiled by us, to bring all the games together using the state manager.
 
alright, couple questions. I have prototyped a very small game on the code and so want to do some design now that I know its possible.
few questions:


  • What are the limitations sizewise
  • What are the limitations as far as content go
  • how long should the game be?
 
PoisonedV said:
alright, couple questions. I have prototyped a very small game on the code and so want to do some design now that I know its possible.
few questions:


  • What are the limitations sizewise
  • What are the limitations as far as content go
  • how long should the game be?
  • Try to keep it small and use pngs for sprites, pngs or jpg for bgs.
    mod files are preferable for music, since they are small.
  • Um not sure what you mean, it should be a simple minigame with a simple goal, but under pressure
  • depends on the goal for the game :) If timed around 15-20s Or you can do some goal that is either pass or fail with one chance

PS It's preferred to continue the discussion of the project here, since we can update the first post.
 
Last edited by a moderator:
Cameleon said:
Actually, No. Each Minigame would be a seperate state(i.e. Source file, or Small collection of source) [...] but the final collection would be compiled by us, to bring all the games together using the state manager.
Hmm. In some ways that's even worse... you'll have to recompile the whole project in order to add a minigame. I thought you'd go for a system where you could download additional games to add to the collection after release...

Either way, compiled C++ minigames pretty much rules me out of contributing in the near term. :(
Good luck with it...
 
I would love to take part in getting this thing moving. I do have a little music and graphic abilities, I also have so much sprites and music already on my computer I could probubbly provide any music from any game you'd like, and some sprites. :D

If your interested, let me know so I can give you some examples.
 
Kagato said:
It would be much more preferable to call an interpreted script engine (say Python/Pygame), and only require the minigames to provide code for their game routine. I think you're better off putting more work into the framework so that you end up with a better minigame library.

I'm with Kagato on this. I think we should have a framework pre-designed and then just have the minigame authors be responsible for little modules that are added onto the framework and call back to basic functions in the framework. Either have these compile with the main program or be an interpreted language like python or lua so that they can be edited on the fly when necessary (I'd prefer the later).
 
But that would never get done. Either you go all out AFTER pandoras ship, or you tone it down for a launch title
 
dasfool said:
Kagato said:
It would be much more preferable to call an interpreted script engine (say Python/Pygame), and only require the minigames to provide code for their game routine. I think you're better off putting more work into the framework so that you end up with a better minigame library.

I'm with Kagato on this. I think we should have a framework pre-designed and then just have the minigame authors be responsible for little modules that are added onto the framework and call back to basic functions in the framework. Either have these compile with the main program or be an interpreted language like python or lua so that they can be edited on the fly when necessary (I'd prefer the later).

Look, I know that it's in many ways beneficial to support scripting languages, and yes maybe in the future it will be possible to add support for LUA and python into the engine. As it stands however, we have a launch deadline to aim for and no LUA/Python support in the engine... I personally don't have the time to research and implement this and still get this ready for launch... if you know someone that can add it in then by all means we are not stopping you. This is our engine, this is how it is right now, we can't magic support out of thin air, and no one else stepped forward with anything, so we can only do what we can do. Sorry if you feel this excludes you, but we are doing are best to help this community project along.
 
Back
Top