Please share ideas or input on a community Warioware like project. At the moment I have motion sickness from typing in the car too much, so I'll come back to this.
Community Warioware
That's the general idea. I don't really know what kind of coding structure it should follow. I hate to have a hunk of Frankenstein patchwork code to deal with. Ideally I'd like to build a framework that even less experienced programmers (like myself) could contribute to without too much effort. It's just pseudo in my head at the moment, but I plan to start working on it soon.
If anyone has any input on this, then feel free share.
I'll have a prototype engine and some games completed some time next month, so now's a good time if anyone has suggestions on how the code should be structured. Please keep in mind that I want this to be simple enough that most people could contribute if they wanted.
This isn't a dead project...yet. I've made 1.5 games so far. I'm still working on the screen between minigames. Some of the framework is there, but not everything. I don't have a lot of time lately to work on SB stuff (school, work, teaching, etc). I need help, so I'm reaching out to anyone who wants to collaborate. I can release what I've got so far. Just let me know. :)
Well, 12 "Me" 21, hear me out.
An game development cycle actually has three parts to it: the idea, the spaghetti code, and the finished game. And together, this forms one complete game development cycle.
Now, usually it's the finished game that's useful, because that's the only part that makes your game complete. However, sometimes it's sufficient to just use the spaghetti code part, which allows game devs to do little tricks, make a prototype, to forget how their game works due to a hiatus, and to forget how their game works due to complexity. And as for the idea... well, there's currently no cases where that's useful or important, so don't worry about that part.
a game is a game, you can't say it's only a halfWhat I have at the moment is a skeleton with some guts in it. I have made one game for this project, and I'm working on another (hence the 0.5). I will post what I've got so far later on tonight...till then I'll be doing homework.
The code for this is: 4KVXD3HE.
I would have liked to work on it more, but I didn't have the time. I'll probably start back on this during the winter break, or if I get any slack on my research project. Any input and/or constructive criticism will be appreciated.
I've always wondered if this was possible with SmileBASIC, but maybe we could work on a Monkey Ball-style game? I was thinking of something top-down to reduce lag. Unfortunately, I couldn't help on the coding side because:
A) I am not good at coding in BASIC
B) I never took the time to really learn BASIC
Also, I'm not dead anymore. ;)
- Michael Shaw, self-employed founder at Flippin' Fun Video Games
https://ffvdgames.blogspot.com
I don't know what you want to do with this project. I imagine that it could be one of these options:
1-It's a framework to do microgames.
2-It's just a collection of minigames.
3-It's a program to make games(Like wario ware D.I.Y. or RPG maker where you don''t need much knowledge about programming)
But from what I saw in your demo, I guess it will be a collection of minigames. If that's the case, then you should use a framework to isolate the code of each game.
What I want to do is create a framework that players can add to. Also, I want to make it as easy as possible in order for beginners contribute. As such, I want this to be something were people could learn the basics of making a game with SB.
Ok, I understand. I think you should try to use lowerdash in your project because it could help you separate your library in different modules.
I think this are the things that could help the beginners:
-A module that handle the lifecycle of the game:
I use a mix of the gameloop pattern and some ideas from the Android lifecycle to separate each screen in diferent contexts.
OnCreate->OnStart->{input->update->render}->OnStop->OnDestroy
OnCreate and OnDestroy are called when the screen is created or deleted respectively.
OnStart and onStop are used for transition between screens.
(input->update->render) is the lifecycle.
-A way to handle the entities(Sprites) of the game automatically:
This could be usefull to clear the unused memory of some elements of the game or to add behaviors to them.
-Code generator: This could be used to generate predefined scenes or entities, and all the functions needed to work properly
-A way to declare events global events or local events on entities.
Well, that are all my ideas. You could try to put a code generator to generate code for common things in game(Controller, sound, etc).
I think you should check this link: http://gameprogrammingpatterns.com/contents.html and check how gamemaker and unity handle the code to create a game.Thanks for the input! I hope to get back to this project soon.
