Next competition ideas (The 9th)

[iWasAdam]

The only issue with collaboration is who does what, how and in what language.
A only works in Unity
B refuses to work with Unity
C will do all the code as long as it's in AGK
D want to do music, but as realtime and not streamed
C wants 3d graphics
A wants 2d graphics
Q wants to rule the world
etc...

[Derron]

> Q wants to rule the world

Wonder why you've chosen Q 


@ collaboration
Games should be little projects then as it has to have an "end" somewhen. Also - sorry if that sounds arrogant - people of similar knowledge levels should try find together. It is not satisfying for a beginner if the others nag around for the time it takes to come up with some not-that-decent artwork or if the code runs sluggish and only after 10 posts in forums on how to tackle it.
Discussing about game play stuff is also most often ... extending into a multi-page-discussion without a single conclusion. Seems there is a reason to have game designers :-)

Nonetheless programming can be split into various sections: game play, core, AI, tools ...
(still above said about "beginners/experts" is still valid there)

bye
Ron

[3DzForMe]

Also, with the varying interest in languages, there's almost enough to have a melding of AGK and blender. Plenty for people to get their teeth into there. There's even scope for two 'teams' collaborating within similar but different languages to achieve a similar goal. As Derron says there's AI, level creation/scripting, graphics, textures, creation of possibly 3d entities. Just some thoughts....

I know all aren't comfortable with 3D, 2D is also fine, but maybe a chance to embrace a collaborative 3D project, possibly a Tower defence genre utilising physics libraries to save on brain ache?

And as for Q, he can go to the back..... Of the Queue. I'll get my coat.....

[Naughty Alien]

..much as collaboration sounds attractive, it was proven in past that it doesn't end up well..for sure it will be interesting to watch it and how it is evolving, but i personally, do not believe it will work out well..

[3DzForMe]

.   ..much as collaboration sounds attractive, it was proven in past that it doesn't end up well..for sure it will be interesting to watch it and how it is evolving, but i personally, do not believe it will work out well..   

.... Yeah, it can be a journey, we could still make it a 'competition' by dividing up the team's into levels of experience and stuff. If there's more than 9 entrants for the next compo.... We could have 3 teams.... I know, the complexities of the real world infringes on everyone's indie coding time.

However, thanks to the last 8 bit competition, I now have a man cave to squirrel away and code in. It needn't be a competition, more a drive to learn new coding skills collaboratively.....

Would you be playing/ coding NA?

[Xerra]

The only way you could possibly do any kind of collaboration thing on the code side would be some kind of main project which could launch other executables from the main project. Then you could have everyone write a mini-game for the main project - only condition is it has to load the main menu or launching game back when the player exits.

I don't think it would work either but you never know.

[Naughty Alien]

Would you be playing/ coding NA?

..im playing and watching..hehe..no time for coding as im busy with some other things to code (some hardware stuff)..but i enjoy a lot, watching guys kicking out ideas and artwork here..very nice..

[Qube]

Q wants to rule the world

Wonder why you've chosen Q 

Wants to rule the world?. I already do. Ask around who Qube is. No-one knows, super spooky eh - But be careful who you ask as you never know who's connected to the inner circle

And as for Q

Go back from whence thou came or thou shalt most certainly die! ( something like that ) <--- For all you trekkies.

@Collaberation - I'd love to see a team collaboration on the comps but to state the obvious .... We don't have enough participants. We could get a list of entrants and then select the teams but then we come up against the list that iWasAdam posted. Also, does anyone work as fast to keep up with the production rate of iWasAdam? He'll be screaming at you "It's only 4am.. keep coding!!"

Unless someone comes up with a super duper eureka inducing idea then the next comp will be a random generated one via PHP script. But keep debating as something crazy awesome could crop up and get our coding juices flowing

[DaiHard]

How about combining "AI" and "Board game", and competing to write AI "players" for a specified game? The obvious problem is that we'll all write in different languages, so we might need to agree how to pass the board state between programs, and/or set up some sort of framework to run the opponents alternately/cyclically.

Not sure what game to go for - noughts and crosses clearly too easy, chess probably too hard. It could be something less predictable, like Monopoly, or the Really Nasty Horseracing game?

It avoids the issue of judging, too: you simply play some sort of round-robin tournament, and see which player wins the most games.

Alternatively, I'd prefer to see a "theme-based" topic, rather than a coding restriction.

Best wishes,

D

[Derron]

If all languages could create DLLs... We could use that approach.

Another solution would be to use Lua for the AI.

We already had the topic AI suggested and some were not pretty fond of doing such a thing.
Also we would need a proper client (the game itself).



Another compo suggestion is "multiplayer" (internet/lan, not just hotseat). Think most of us have no experience with it...so this means we all learn something new.
And if properly done, we could play some of the entries together ;-)


Bye
Ron

[3DzForMe]

only 5 mins of battery left.... heres my 5 p

[iWasAdam]

Macs and Linux don't use dll, they use something different. And dll would need to have a very strict compile base

Lua - so you now have another language being used on top of some language that no one can decide with.

If it is some form of client server, then you will need someone/where to host it.

The arguments about how, etc can go on for days... that is why you have a single vision and specs, and people choose to be part of or not part of. More than likely the single responsible person/manager would then dictate exactly what and how contributions were to be accepted.

They would have the responsibility to ensure everything was correct, refactor things that are not correct, and probably have final code say. So they would also be one of the primary programmers as well.

Initially the area of a simple collaboration has the potential to become the opposite

[DaiHard]

The kind of thing I had in mind is a host program running the game itself, which would pass a data structure representing the current position (perhaps as a file) to the player programmes in turn (for example by running them), which would return a valid move (if necessary, in a temporary file). Depending on the game, the player programs might need to hold game state information (for example, info revealed in previous moves) somewhere (for example in a data file).

That should be achievable by pretty much any programming language?

Obviously it's much easier if everyone uses the same language (we've done Reversi like this in BB4W) - you just implement the players as procedures, and call them as needed - but that doesn't seem sensible in this context.

If there is serious interest in this idea, and we can agree a game, I might be up for setting up a basic core program, and defining how data would be passed (i.e. the format).

Any thoughts on games? Involving luck, or defined? Needs to be mathematically hard enough not to be (easily) soluble in a "sensible" move time (say 1 minute - or 1 second?).

[Derron]

Macs and Linux don't use dll, they use something different. And dll would need to have a very strict compile base

Lua - so you now have another language being used on top of some language that no one can decide with.

call it .so or .dll the principle is the same.

But as this might create issues one could even say we use a TCP/UDP based communication and some RPC calls. Means you just communicate via networking. One could even ease the pain a bit more:
The (local) server acts as a kind of simple webserver: it listens to a given port (eg 12121). Commands are simply string based stuff with eg. comma separated params:
command: "GetPlayerPosition,1"
return: "1,10,10"
First value is the result code ("OK", "FAILED" ...) and the other stuff in this case simply the X and Y position (on the board or on a grid or ...).

That way the (local) server exposes the whole "API" ("GetPosition", "MovePlayer(playerID, x,y)", "GetBoardTileInformation(x,y)", "AddPlayer()") and so on.


What benefits do we have:
- this server could run locally, remote, ... could even be implemented in Perl, PHP, ... so people could observe the whole game in their webbrowser.
- the clients can be written in any language as long as they are able to send simple requests to an "IP:port" (so in this very example TCP/IP packages).


If one wants to do such a thing and we eg. decided to write it as a webapplication we could even develop the "server" in collaboration. First of all it needed the basic functionality (the API containing stuff to create test games, add and remove players, handle drop-outs/time-outs ...). So we would create a server which allows to create games we could use to test our "bots" (each dev can play its own games). It must of course also allow to register bots (you receive a unique key) which would allow multiple bots to get executed on the same computer (they then send their unique key as identifier for the server to distinguish between multiple incoming requests).
Once this all is working, people could try out basic bots to see if communication works as they want. THEN ... then it is time to decide for a game (hidden, not publically) as the game logic would need to get written too + API to expose. Once the server is written the game would be announced and people could start writing the actual AI/bot.
There is a lot of more to do and I want to avoid derailing the thread with an idea which is not of interest for all.

The whole server-program-creation already will take a lot of tinkering already - surely way way more than creating the bots (as you do not have to deal with all this ACL, GUI, ... stuff).

Once this is done you can use the base for many other bot-game-experiments.


Am pretty sure that there are some interested in such a thing - but most will try to avoid these kind of "experiments".



bye
Ron

[iWasAdam]

i like the general idea of 2d = 32
cards - however interpreted