What's Next for Inkubator?

[geezusfreeek]

Hooptie out of the way... now what? This dead time is not good.

[Carlos Camacho]

Centipede in a circle. :)

Other idea is to utilize something like SpriteWorld or CocoBlitz (depending on its license and bug progress :) )

Missile Command can teach a good amount of things I think. And can be built upon for added features.

A sports game like, baseball or volleyball or basketball. Might require game assets for the sprite animation, but you would have my interest!

Like the RB series, how about a simple card game?

My advice though is to pick a game that doesn't take too long to create, and doesn't require too much game assets. A small game can also make it easier to create docs/tutorials.

Once we get the sub-domain working again. I think Inkubator needs a kind of Wiki or online doc creation space. A place where all of you can enter in docs that will make up the little tutorials. For example, Chapter 1, Setting up the game world... anyhow, something like that, right?

Cheers,

[gatti]

From an illustrator's perspective, a key way I learned to draw was by trying my hardest to re-create a previously done work. I'd take works made by Cezanne, Michealangelo, Picasso, etc. and copy them to my fullest extent. Why did I copy them? Because I loved their work. Their works of art constantly inspired me throughout the process. This brings me to my idea.

Take an old video game such as Donkey Kong, Zelda 2, MegaMan, Metroid, etc. and cut it apart. Then, put it back together again. Since the inkubator projects are mainly for learning purposes, it may be good to once again start by re-creating works of the past. And just think, they're great games at that! They mostly all have elements of physics, screen scrolling, and other interesting event-driven facets for any beginning programmer. Any of the above listed games should also not be too time intensive since there is full direction of how the game should ultimately be.

How each party will learn.

An artist's role can be to capture/recreate the art. - This teaches them about 2-d scrolling games and how to treat graphical elements.

The programmers involved will learn: what makes a game good by re-creating the gameplay.
how to create a 2-D game in a 3-D GL system.
the "dirty/wrong but ultimately feasible" way of porting games for other systems.
The sound designer's role can be to capture/recreate the sound effects. - This teaches them about creating sound effects and where they are needed for simple games.

The musician's role can be to capture/recreate the music. - This teaches them about composing music for games and how the music must dictate the game environment.
---
Since the game will not be for sale, there shouldn't be any problem with copyright issues and things of that nature. It can also generate more media exposure for idevgames since the game is a recreation of a classic.

Please remember, this is just an idea.

[igame3d]

I highly suggest that SEUCK should be the next inkubator project, with the completed work being something Carlos can put up for shareware to support the costs of this site.

After all the first amazingly popular video game was Space Invaders (aside from the Pong craze, cause people didn't have anything else). SI is just a shoot em up without any features.

Since Metal users have mostly all tried to make an invader clone, this could very well be something they might move out of the Metal world into.

[flipflop]

For those not in the know about what SEUCK is have a look here (http://www.c64gg.com/s10.html)... don't mind all those sex games just below it. :p

Perhaps we need a vote to choose a specific ganera (Yes, I know this is spelled horrible wrong... dictionaries are not much help when you are not even CLOSE to spelling it right! :blink:) like classic arcade, sports, board game, puzzle, etc... Once we have the ganera (ugh!) we can then have another vote to select a bit more specific game like Centipede, football, Stratego, etc... The vote would also see how many people are really interested in the project too.

If we use a library like CocoaBlitz it would be nice for someone to still write up a tutorial on how to use OpenGL to create a 2d game. Setting up the orthographic projection (I believe that's the type that is used), loading bitmaps and displaying the image, etc... Perhaps this could be taken even further by creating a 2d game but using a 3d particle system.

[OneSadCookie]

genre :D:p

[flipflop]

<takes hammer and starts pounding his head> genre, genre, genre...

Thanks OSC! :D

[igame3d]

Ok I've looked at GoodDougs Enemy pattern Generator, pretty cool, but not totaly intuitive, if taken to the next step I think it could benefit from drawing points and lines to determine the ship pattern. Would be a cool tutorial, that could come in handy for several game types, for instance a more complex pattern would give you the moves for a pac man ghost, instead of just a flying galaxian devil.

Now Chopper source, especially the editor, is wicked cool stuff.
Using this as the base project i could see it capable of generating clones of:
Scrambler, Vanguard, Yars Revenge, Breakout, Defender, Twin Cobra, that awful Atari 2600 Empire Strikes Back game. All this almost right out of the box, if one knew what to do with the source.

Concidering that David is relatively new to dev, he kind of stands out as an example to us other newbs, with some time, patience, and Keith's help, anyone can be a game designer. Oh yeah, and with a heavy art background you can make kickazz graphics too!

One more suggestion before I finish this up, I think it is imperetive that this project teach how to implement a scripting language into into source.
A hard coded app, is pretty much a dead end. Joe designer can't pick it up and make anything with the source, can't even change the smallest fraction of game behavior without learning a language and recompiling, if it even compiles.

Poser, Lightwave, dim 3, iGame3D, Maya, Cinema4D, Blender, even that thing from SilverWorks have scriptability. If Inkubator remains a hard coded, "read the source code", one game only project, its going to be a lot less attractive to the average new to programming person.

If its more open to creative people, even if its :"I made garbage in 30 minutes, but its a start" it is more likely to keep attracting users.

So when do we get started?

[GoodDoug]

Remember that a "Scripting Language" can be as simple as some plists. I did a really simple version of that with Swarmed, and it should make it simple to create and read time based or trigger based scripts.

ie:

<dict>
<key>timeStep20</key>
<array>
<dict>
<key>action</key>
<string>spawnEnemy</string>
<key>whichEnemy</key>
<string>enemyOne</string>
<key>where<key>
<string>{100, 200}</string>
<dict>
</array>
<key>playerOpensDoor</key>
<array>
<dict>
<key>action</key>
<string>playSound</string>
<key>whichSound</key>
<string>openDoor.aif</string>
</dict>
<dict>
<key>action</key>
<string>startNewLevel</string>
<key>whichLevel</string>
<string>levelTwo</string>
</dict>
</array>
</dict>


as an idea for what can be done with these things. This way one wouldn't have to write a parser from scratch to make a script editor/reader. It also allows for hand creating scripts when needed to test something before you have a chance to put it into the script editor.

[igame3d]

Ok I have 59 screen shots of Amiga SEUCK. Will crop them, and attempt to explain them, and then post later on tonight. I had to restart the Amiga emulator several times as it expected a joystick button press in several spots, we can do without that.

I think the most valuable parts of the editor are its parameters for game play, you'll see what I mean when I post.

The pixel editor in SEUCK was primitive as can be, tedious to the extreme.
I think that portion of the project should be left out and made a some seperate task for others to attempt. Copy / paste or folder import will be much smoother to use.

Ok running out for a bit....in the meantime should I post SEUCK details in the game design threads when I get back??

[Carlos Camacho]

What would be nice is to se the "point-and-click" editor which iGame3D speaks of. I really liked Seuck myself, and I can't think of a better way to vastly increase the number of people in this community. Once difference with Seuck that I would like to see is the ability to look at the scripts. Seuck was visual only, which is great for most people. However, being able to also see the script, like what GoodDoug just posted would be very nice. A very good way for non-programmers to see how things are done. For developers wanting even greater knowledge, then they would work/look at the under-lining game engine.

Cheers,

[igame3d]

I've deconstructed the basics of SEUCK, have a nice little show and tell app for ..showing and telling all about it. But having a bug on that, and its quarter after 5AM here, actually almost erased the whole data base I built, so best to not mess with it when I'm sleepy.

Will post when I'm conscious and fix the bug.

Meanwhile Carlos if you want to dig around in the screenshots and
maybe wax nostalgic, or post with a particular piece of "this was really cool" info. I've uploaded the raw images here SEUCKPNGs.zip (http://www.igame3d.com/SEUCKPNGs.zip)

During my deconstruction I realised I really have to hang myself in classic for a bit and desconstruct Anvil from Marathon as well. as it had some weapons features that are totaly lacking in SEUCK.

Whats a shoot'em up without good guns?

You know SEUCk fit on two floppys, double density at that.
Anyone arond here know mobile programming?
SEUCK for Cell phones would rock!

[igame3d]

Ok I've uploaded my explanation app : Seuck Explained (http://www.igame3d.com/seuck/SeuckExplained.zip)

If anyone has an app with some feature of this, or is inspired for a much better way of doing this stuff, Speak up!

[EvolPenguin]

How about something like one of those old rpg games, where it had graphics but the text explained all that happened. That would be fun.

[DaFalcon]

Why an app and not a webpage slideshow, ig3D? That said, your app was cool enough and usable. And it did a good job of showing and explaining what SEUCK is (I kept seeing this acronym on here and being confused to all heck. The Shoot 'Em Up Construction Kit looks like it was a very nifty product indeed.)

Now I want a modern version of basically the same thing. And I want it now! :) Seriously, that would be cool to have a 2D construction kit like that (except, of course, import or copy/paste graphics, not require that we draw them by hand, and other such changes) with some 3D particle effects for good measure.

[flipflop]

Another construction kit you can look at is Gary Kitchen's GameMaker (http://www.mts.net/~bbagnall/commodore/gamemaker/index.html). They even have documents you can download in RTF or text format. FYI: The RTF document will not open in TextEdit but will open in Word... at least on my machine.

I'm not suggesting we use GameMaker over SEUCK rather one of these kits may have a nice feature the other is lacking, like the music and sound editors in GameMaker...

Has anyone found documentation on SEUCK? The screenshots and descriptions do help a lot though! Thanks, igame3d! :wow:

OT: Work BITES! :mad:

[igame3d]

Why an app and not a webpage slideshow, ig3D?

It's been 7 months since I did anything with html. 7 months of coding Revolution. I'm now using that as the template for building databases.
And that will be my big list of "game editor buttons and widgets",
which will help produce a big app of buttons and widgets.

[Carlos Camacho]

Wow, is that a Wico joystick in the add for game maker!?!?!?!?

I LOVED them!!! I miss the days of Wico!!! I even had their trackball!
Anyone old enough to remember them?!?!?!

I think if you google, you will find many game-wizard tools. I even posted one in this forum not long ago for the PC, which seemed like a modern day SEUCK. The thread is someplace in this forum. :)

[Kjurtyl]

I will not comment further on this until I get my computer back than to say that:

- Doing a game-making tool is a good idea;
- Scripting (a la plists) and game-making tools probably go hand-in-hand;
- A free sprite-making (various sizes 28x28, 32x32 etc) complementary app. could be useful and not so difficult with Cocoa: it could have a nice feature set I think and could double as an icon maker;
- Haven't looked at recently released uDG source code;
- If we're doing this for profit, how does it affect the open-source mission of Inkubator?
- Seen PenguinEdit? Some parts could be taken from there, like the tool palette;
- The entire sprite-handling system would have to be re-written from scratch rather than take Hooptie's code unless uDG source offers a viable alternative;

That is all for now, other than to ask:

Who'd be in for this?

- Kjurtyl.

[igame3d]

I will not comment further on this until I get my computer back than to say that:

- Doing a game-making tool is a good idea;
- Scripting (a la plists) and game-making tools probably go hand-in-hand;
- A free sprite-making (various sizes 28x28, 32x32 etc) complementary app. could be useful and not so difficult with Cocoa: it could have a nice feature set I think and could double as an icon maker;

Wouldn't the map editor basic work very much like the sprite editor?
Only painting texture instead of color onto a grid various sizes 28x28, 32x32 as rooms and. Then painting rooms onto a grid of various sizes.


- Haven't looked at recently released uDG source code;
- If we're doing this for profit, how does it affect the open-source mission of Inkubator? hmm


- Seen PenguinEdit? Some parts could be taken from there, like the tool palette; Yeah a good lesson for Inkubator : "How to recycle open source parts for your project"
Who'd be in for this?
- The entire sprite-handling system would have to be re-written from scratch rather than take Hooptie's code unless uDG source offers a viable alternative;[/QUOTE] See UDG source, Chopper, Argonaut, LightNings Shadow.



Who'd be in for this?
- Kjurtyl.

There's this guy I know who would be interested, I'm trying to think of his name...somethin' somethin' or other. I'll remember...

[Baldock]

- If we're doing this for profit, how does it affect the open-source mission of Inkubator?
- Kjurtyl.

Just charge for the binary of the game. The source can be open and the tools can be free. On the plus side, people who don't program pay, those that are willing to have a play / learn something can compile it and get it for free.They then might become interested in it a bit more and before you know it they are helping out.

[Kjurtyl]

Just charge for the binary of the game. The source can be open and the tools can be free. On the plus side, people who don't program pay, those that are willing to have a play / learn something can compile it and get it for free.They then might become interested in it a bit more and before you know it they are helping out.

With the MIT license that is certainly possible, though it wasn't clear what people had in mind for this project. This is acceptable to me, however perhaps another bit of clarification is needed:

- When you say "tools" do you mean the "construction set" itself or other helper applications created with this process?

- Your wording of "charge for the binary of the game" leaves me a bit perplex. Again, do you mean the binary of the "construction set" or of whatever product *we* make with said "construction set" (assuming that the "construction set" actually produces some kind of app)?

- Furthermore, if someone can have the "construction set" binary (however he does that) does he also gain a license to sell his own products made with it (however crappy)?

Here's my understanding of it:

- Source of "construction set" is free.
- Binary of "construction set" is for sale (as per terms of MIT license).
- Anything anyone does with either the source or binary is covered by MIT license and thus they can also sell their results.

However, is anything produced by the "construction set" automatically covered by the license? On top of which, is the "construction set" needed in order to run whatever games it produces or will there be a helper tool that will run the appropriate scripts independently of the set?

Hopefully I haven't thoroughly confused anyone,

- Kjurtyl.

[Kjurtyl]

Wouldn't the map editor basic work very much like the sprite editor?
Only painting texture instead of color onto a grid various sizes 28x28, 32x32 as rooms and. Then painting rooms onto a grid of various sizes.

Yes, I believe the map editor and sprite editor would essentially use the same basic concepts. What I was suggesting is to have the "set" only import textures and have another separate helper application that would essentially be a pixel painter that could produce whatever textures the "set" needs. However, I've noticed that some other people have already delved into this area so there might already be something out there for us to use.

Eventually I'll look into others' source but I cannot do that at the moment.

- Kjurtyl.

[DaFalcon]

That is all for now, other than to ask:

Who'd be in for this?

I'd be in for: testing, ideas, more ideas, some starter graphics, inspiration, etc. :cool:

[reubert]

I haven't actually looked at this project before... this thread is down next to METAL in that dodgy area ;)

But anyways...First up, I think that the "joining the project" sticky should be removed or replaced as it's kind of weird and was last posted to in May 2002. :p

Second, I feel that I almost know enough that I can help others now, like others have helped me, and Inkubator seems a good project to join to do this.

I'm thinking that I could strip chopper back to something far simpler and more re-usable. I don't think it would be a huge task, mainly just deleting code, and a lot of refactoring, but at the end there would be the basis of a good 2d scroller engine and editor. Time is a huge issue for me now, as I'm sure it is for most of us, so a couple of weeks of full time work (what I estimate it to be) would take me alone months.

Would this be useful? Is this the kind of direction you guys want Inkubator to head? Is it possible for others to help in the conversion to make things happen faster? After an engine was made what would we do with it?

[Kjurtyl]

The machine has finally returned (24 days later).

The "joining the project" sticky wasn't stickied by me but I clearly see why it was stickied and still applies. Regardless of when it was posted it clearly delineates the steps that are taken to contribute. Perhaps it could be abstracted a bit.

The whole point of Inkubator is we have one project on CVS so everyone can pitch and hopefully learn a thing or two as they attempt whatever tasks are at hand.

Essentially, that means if we were to take up Chopper's entire source we'd do the following:

- Put it on CVS.
- Detail tasks that need be done.
- Let individual contributers execute tasks at will with some coordination.
- Routinely review any submission for opportunities to clean them up.

With that engine - have you read this thread?? - we'd seek to make a "Shoot-Em-Up Construction Set" which we will more appropriately name (further from SUCK we are, happier I will be). At that point we'd be looking at furthering whatever UI art (should there be some) with a set of stock textures to use as sprites, background tiles, etc.

With that product, we'd market/sell to provide funding for iDG.

Hopefully a few target goals we set up such as:

- Scripting
- Tutorials

will be reached through this effort along the way.

- Kjurtyl.

[GoodDoug]

After reading through these posts I think I can offer some advice:

Creating a game construction kit is a lot more work than creating a game. Maybe we should consider breaking things into more bite sized chunks:
- A "Pixel Editor" that can be used to create sprites and icons
- A graphical sprite scripter that can be used to visually design paths for sprites
- A map editor for creating scrolling games... integrates somehow with the sprite editor and scripter
- Concurrent with the map editor would be the game engine (based on work already done for scripting and mapping)

Each of these tasks is pretty big by itself. Trying to put them all together at once would, I believe, mire the whole project down from the beginning.

[DaFalcon]

After reading through these posts I think I can offer some advice:
Each of these tasks is pretty big by itself. Trying to put them all together at once would, I believe, mire the whole project down from the beginning.

Sounds good... :cool:

Who can lay this out for us and describe the different modules we would need, and how they can work together? GoodDoug, would the order you propose be best? How do we use the sprite scripter without a map ..? Or, even if we can, would it be easier on a designer if the map is there? Just questions I don't know the answers to ;) But I think it would be good to solidify these ideas and turn them into actual tasks. As before, I'd be quite willing to test apps-in-progress, come up with ideas, provide graphics, and input from a graphic-design standpoint :D Let's do this! :wow:

[igame3d]

Yeah doing it all at once is too big. Thats why it should really be ordered in such a way that its very step by step:
1. create a project, get window up, make some simple sprite tools
2. scripting the sprite tools (ie, tell pen down from 1,1 to 20,20 or draw "contents/image.png",x,y) or something
3. animations, paths and scrolling
4. colissions
5. launching events (sound, screen/level switch, score change,etc)
6. Simple AI
7. level design from start to finish
8. 10 level game

Thats pretty bare bones there.

Consider that Inkubator is not on a deadline, so the length , complexity and progress of each step will not be one enourmous task but a stretched out grow as you go type of expirement.

[DaFalcon]

Is Inkubator back now that iDevGames is back?

[hytmal]

i am all for helping out with the new inkubator project (whatever form it takes).
however, as someone who is just now getting into games, i think i have a good perspective on what kind of technologies the project should accomodate.
when i say i am "just getting into games" i mean that i am in the midst of a cross-platform game engine with a friend of mine, and currently making my first game (that will actually be finished ;-)). I'm aware that many of you probably think this is early in the brainstorm phase here to be discussing anything like this, but i would just like to mention some things that i had a helluva time trying to learn on my own.

OK first of all -- i have nothing against the tools (or whatever form they shall take) being written in cocoa, but (assuming the game itself is separate) i really think it should be written in c++ or something that is not so proprietary.
Secondly, I think that OpenGL is just about the best thing to learn for someone who is new(ish) in games -- which is apparently what inkubator is aimed at.
That's pretty much all i've got cooked up right now. other than that, i'd be proud to say that i voted for Lemmings ^_^

enjoy
-- hytmal

[BobbyWatson]

Hi guys,

I would be happy to be a part of inkubator... again. I used to be on the team in the beginning, and did some of the most lousy coding in Hooptie (the custom level loading part, actually. Haven't checked in the latest code, but I'm pretty sure it must have been replaced by something better). I also actually wrote a design document for a game before we decided on Hooptie, and the design was rejected mostly because it was too complex for a first project (and maybe because it actually sucked, who knows).

My vote for the next project went to a side-scroller. I'm still puzzled why this choice and the SDL-based games are separate, since it's possible to do a side-scroller with SDL, though IMHO OpenGL would probably work faster for a game like that. SDL would still be nice since it could help to make the game cross-platform, even though Mac development is and should remain inkubator's main goal.

So that was my 2 cents (Canadian, so it's not worth much)

[Carlos Camacho]

I put it separate, because I know you can make a side scroller with SDL. The point was to see if people specifically wanted to work on a project that used some form of technology like SDL, Allegro, etc.. Cheers

[blobbo]

One major criticism I have of Inkubator (and I think it's a great project - don't get me wrong), is that by the time the people who can really benefit from it (i.e. the new people) find out about it, all the code that they could have conceivably have written or followed along with and learned from has already been written. What's fundamental in my argument is that the hardest part of any project isn't the logic, it's the basic setting up of the game, and the first methods.

I think that for this to work, the project has to be "tutorialised" as it's written. i.e. along with committing a cvs change, you also are required to update the tutorial with what you did, along with a quite detailed code breakdown. That would be really handy. Just a suggestion, though.

[igame3d]

I agree with blobbo, perhaps it should be journaled as well, written like the
old developer diaries were.

I miss my diary :( and the dim3 diary :( and the, that other 3D engine diary whose name I can't remember :( .

Progressive posts of "what learned and did today" would be helpful.