Yhteisprojekti

[Ilmuri]

GIT was here, SVN is a loser.

[Warlock]

GIT was here, SVN is a loser.

Siis?

[Koodiapina]

"GIT oli täällä, SVN on luuseri."

http://git-scm.com/
http://subversion.tigris.org/

Google on hieno asia.

[KankiKalle]

Näyttää siltä, että kaikki halukkaat osallistujat ovat mukana, ja Jare ja temu92 pitävät huolen tuosta koodin lähetys/vastaanottamispuolesta koodarilta toiselle. (tai jotain sinne päin?) Nyt pitäisi sitten vielä miettiä se sopiva aihe projektille, ja keskustella tuosta mitä Jare on kertonut:

Kannattaa ehdottomasti ottaa huomioon sekin, että jokaisella on oma tapansa koodata. Vaikka kieli on sama, jokaisen koodi voi näyttää erilaiselta kuin toisen. Ehdotan siis, että joku kirjoittaa kattavan dokumentin siitä, miten muuttujat nimetään (miten erotetaan muuttujan nimestä helposti sen tyyppi ja näkyvyys?), funktiot nimetään, yms. Mieluiten vielä ihan rautalangasta vääntämällä. Käytetäänkö sisennyksissä välilyöntejä vai "oikeita" sarkaimia? Ja jos välilyöntejä, niin miten monta. Millä kielellä asiat nimetään? Joku voi tykätä, että suomen kieli on helpoin, mutta joku toinen taas saattaa ajatella, että on turha sotkea kahta kieltä kun CB:n komennot kuitenkin ovat englanniksi. Miten ja millä kielellä kommentoidaan? Mitä kaikkea kommentoidaan? Jaetaanko koodi Include-tiedostoihin? Kaikki mahdollisimman tarkasti, niin koodin yhtenäisyys on mahdollista säilyttää.

Projektin suunnittelu taas on sitten aivan oma asiansa. Pähkinän kuoressa mainitsen, että ennen toteutusta laatikaa lista ominaisuuksista, joita peliin tulee (kaikista ominaisuuksista!). Sitten jakakaa lista loogisiin osiin niin, että tärkeimmät ominaisuudet tulee tehtyä ensimmäiseksi. Kun alatte toteuttamaan peliä, edetkää aina listan mukaan - ja jos on uusia ominaisuuksia lisättävänä, niin lisätkää mieluiten listan loppuun - eikä siihen kohtaan, mitä juuri nyt työstetään.

Ihan vinkkinä vain.

Laiska kun olen niin päätinpäs vain lainata tuota viestiä
Ja, kuten jo sanoin, mikä nyt sitten on projektin aihe? Minulle sopii hyvin jokin noista Galgoneerin mainitsemista managerointipeleistä.

[rami123]

EDIT:

ei mitt..

[Awaclus]

Myös minä voisin kai tulla mukaan , jos sopii? taidoistani kai numero 6.
Sellanen vuoropohjainen stragedia peli kuten civilizationit(kirjoitinko oikein? varmaan..) tai simulaatio peli olisi varmaan iha hyviä ideoita .

Off: Et kirjoittanut. Se on STRATEGIA, ei STRAGEDIA.

[Jare]

Näyttää siltä, että kaikki halukkaat osallistujat ovat mukana, ja Jare ja temu92 pitävät huolen tuosta koodin lähetys/vastaanottamispuolesta koodarilta toiselle. (tai jotain sinne päin?)

Minun puolestani Temu92 voi hoitaa tuon. Minä voin tarvittaessa antaa neuvoja.

[Dande]

Kun puhuttiin noista yhteisistä koodauskäytännöistä, niin ihan vain herättääkseni keskustelua esitän seuraavanlaisen nopeasti kyhätyn version (esimerkkimuuttujat on nimetty todella ärsyttävän pitkästi, mutta todellisessa projektissa aivan tuollaisia muuttuja hirviöitä tuskin kohtaisi):

• Sisennyksenä käytetään neljää välilyöntiä (CoolBasicin oletus)
• Muuttujat kirjoitetaan pienellä ja moniosaisten sanat erotetaan alaviivalla.
• Muuttujien nimen perään lisätään alaviivalla lyhenne muuttujan tyypistä. Lyhenteet ovat: Integer i, Float f, String s, Image img, Object obj, Sound snd, Memblock mem, Map map.
  Esimerkkejä muuttujista:
  very_long_and_stupid_name_for_storing_an_object_obj
  vihu_img
  ase_snd
• Tyypit nimetään isolla alkukirjaimella ja moniosaiset nimet kirjoitetaan putkeen aloittaen aina seuraava sana isolla kirjaimella. Tyyppien loppuun lisätään aina alaviivalla t-kirjain. Esim. SomekindOfEnemy_t
• Tyyppeistä luodut instanssit nimetään lisäämällä nimen loppuun tyypin nimi ilman t-päätettä. Esim. iterator_SomekindOfEnemy //määriteltäessä tietenkin siis Dim iterator_SomekindOfEnemy.SomekindOfEnemy_t
• Osoittimet tyyppien instansseihin nimetään lisäämällä loppuun alaviivalla ptr. Esim. returnable_SomekindOfEnemy_ptr.
• Funktioiden nimet aloitetaan isolla alkukirjaimella ja moniosaiset nimet kirjoitetaan putkeen aloittaen aina seuraava sana isolla kirjaimella. Functioiden loppuun lisätään alaviivalla funktion paluutyypin lyhenne. Jos funktio palauttaa osoittimen tyypin instanssiin, ei paluutyyppiin kuitenkaan kirjoiteta ptr-liitettä, sillä normaaleja tyyppejä ei voi funktioista palauttaa. Esim. FloatReturningFunction_f tai GetEnemy_SomekindOfEnemy
• Globaaleiden muuttujien tapauksessa alkuun liitettäisiin g-etuliite ilman alaviivaa, ja muuttujien nimet kirjoitettaisiin isolla (päätteet kuitenkin normaalisti). Esim. gSOMETHING_THAT_YOU_NEED_EVERYWHERE_i
• Koodi kirjoitettaisiin ForceVariableDeclariation-yhteensopivaksi, jotta virheellisesti kirjoitettu muuttuja ei aiheuta kauheata virheenmetsästystä, vaan paljastuu jo heti käännettäessä.
• Kielenä toimisi siis englanti. Kommenteissa saa toki puhua suomea sydämmensä kyllyydestä.

Sen lisäksi pitäisi varmaan myös päättää mitä projektia tässä oikein ryhdytään väsäämään.

[Jare]

• Koodi kirjoitettaisiin ForceVariableDeclariation-yhteensopivaksi, jotta virheellisesti kirjoitettu muuttuja ei aiheuta kauheata virheenmetsästystä, vaan paljastuu jo heti käännettäessä.

Toki koodi kannattaa kirjoittaa noin, mutta muuten FVD kannattaa mielestäni jättää käyttämättä, koska se estää goto-labelien käytön. Muuttujavirheiden havaitsemiseksi pitäisi olla ihan oma ohjelmansa... :s

[Koodiapina]

... koska se estää goto-labelien käytön. ...

Mielestäni goto-labeleita ei saisi missään nimessä käyttää. Nehän nostavat vain koodin epäselvyyttä, ja tälläisessä projektissa kaikkien pitäisi saada koodista selvää. Hirvittää ajatellakkin projekti jossa on kymmenen eri koodaajan kyhäämä goto-viidakko, josta eivät itsekkään saa selvää. Tietenkin CoolBasic sisältää älyttömän funktiorajan, mutta kyllä siihenkin saa mahtumaan aika paljon tavaraa kun on säästäväinen.

Itse suosittelen lämpimästi tuon FVD:n käyttöä, sillä ratkoo monet pulmat etukäteen. Koodin alussa voisi olla kommentoituna pieni pätkä ohjeistusta miten tyypit saa esiteltyä, jotta aloittelijat eivät tipu heti kelkasta. Ainoaksi jäljelle jääväksi ongelmaksi näkisin nämä konekohtaiset MAV-virheilmoitukset, joita ei yleensä voi korjata mitenkään. Entä jos koodi toimiikin edellisellä koodaajalla, mutta ei enää seuraavilla?

Itse en pääse osallistumaan tähän, kun siirryin vähän aikaa sitten kokonaan Linux-puolelle. Toivotan kuitenkin onnea projektillenne :-)

[Dande]

... koska se estää goto-labelien käytön. ...

Mielestäni goto-labeleita ei saisi missään nimessä käyttää. Nehän nostavat vain koodin epäselvyyttä, ja tälläisessä projektissa kaikkien pitäisi saada koodista selvää. Hirvittää ajatellakkin projekti jossa on kymmenen eri koodaajan kyhäämä goto-viidakko, josta eivät itsekkään saa selvää.

Olen ehdottomasti samaa mieltä.

Ainoaksi jäljelle jääväksi ongelmaksi näkisin nämä konekohtaiset MAV-virheilmoitukset, joita ei yleensä voi korjata mitenkään. Entä jos koodi toimiikin edellisellä koodaajalla, mutta ei enää seuraavilla?

Aika paljon noista ns. konekohtaisista pystyy myös erilaisilla tarkistuksilla välttämään. Esim. yleensä For Each-looppi ei aiheuta Mavia, vaikka loopattavia ei olisikaan, mutta vanhemmalla koneellani se aiheutti. Tästä pääsi lisäämällä yksinkertaisen tarkistuksen loopin alkuun.

Itse en pääse osallistumaan tähän, kun siirryin vähän aikaa sitten kokonaan Linux-puolelle.

Mikäs ongelma tuo nyt muka on? Itse ainakin olen pyörittänyt CoolBasicia ja sillä tehtyjä pelejä niin openSusella kuin Ubuntullakin.

[Jonhu]

Minäkin voisin tähän projektiin liittyä.. Tasokseni arvioisin noin 4-5

Code: Select all

KankiKalle   2
Warlock      2-3
Tuxu         5
Chaosworm    1-2
Pate5        8
temu92       9-10
Viltzu       4-5
Galgoneer    8-10
Jonhu        4-5

EDIT:
Tasoksi 7,5 uusimman asteikon mukaan.. Kaikista muista pisteet paitsi muistipaloista ja DLListä. Muistipaloja osaan jotenkuten pyöritellä, mutta en katsonut tarpeeksi, että ansaitsisin pisteen

Code: Select all

Jonhu 7,5
Galgoneer  9
Viltzu    11

(Esa94 mielestäni ei edelleenkään tarvitse postata uutta viestiä yhden i-kirjaimen poistamisen takia)

[esa94]

Code: Select all

1. Tiedät, mikä on CB
2. Osaat käyttää taulukoita ja tyyppejä
3. Osaat funktiot sekä soveltaa hyvin aiempia kohtia
4. Osaat sinin ja kosinin sekä lähes kaikki objekteihin ja kuviin liittyvät komennot CB:ssä (Hups)
5. Muistat ulkoa useat CB:n komennot sekä osaat soveltaa niitä hyvin
6. Muistipalat eivät aiheuta ongelmia sinulle
7. Muistat lähes kaikki komennot ja osaat käyttää niitä järkevästi
8. Osaat luoda järkeviä tekoälyjä
9. Osaat tehdä CB:lle hyödyllisiä DLL:iä ja käyttää niitä ohjelmissasi
10. Katsot, että CB vain hidastaa kehitystäsi ohjelmoinnissasi :) 

Kielioppivirheet korjattu. Muutin myös muutaman kohdan ehkä hieman järkevämmäksi (Srsly, kukaan ei muista kaikkia komentoja!)

EDIT:

No pitihän sinne jäädä vielä yksi 'kaikki'

[Awaclus]

Ai, no jos taulukko on tuo, niin sitten 2-3. Saatan osata käyttää funktioita ihan vähäsen ja soveltaa osaan mitä vain.

[Dande]

Tuo teidän taulukkonne on aika mielenkiintoinen... Entä jos osaa hyvin funktiot, mutta ei osaa käyttää tyyppejä, tai jos osaa kyllä sinit ja cosinit, mutta ei funktioita/tyyppejä? Sen lisäksi on aika suuri harppaus 1:n asteen ja 2:n asteen välillä. Jos tietää, mikä CB on, ei sillä tarvitse edes osata tehdä mitään.

Minusta ehkä hieman parempi olisi määritellä tietyt asiat joiden osaamisesta saa pisteet, kuten

• Tyypit (perusteet ½ piste, kehittynyt käyttö 1 pistettä)
• Objektit (perusteet ½ pistettä, kehittynyt käyttö 3/4 piste)
• Kuvat (perusteet ½ pistettä, kehittynyt käyttö 3/4 piste)
• Äänet (½ piste)
• Funktiot (perusteet ½ pistettä, kehittynyt käyttö 1 piste)
• Taulukot (perusteet ½ pistettä, kehittynyt käyttö 1 piste)
• Matemaattiset komennot, kuten sinit ja kosinit (perusteet ½ pistettä, kehittynyt käyttö 1 piste)
• Muistipalat (perusteet 1 piste, kehittynyt käyttö 1½ pistettä)
• CB:n kanssa yhteensopivien DLL-tiedostojen tekeminen (perusteet ½ pistettä, kehittynyt käyttö 1 piste)
• CB:n manuaalin tehtävät (helpot ½ pistettä, keskivaikeat 1 piste, vaikeat 1½ pistettä)

Tuosta sitten laskettaisiin yhteen niiden pisteet, jotka osaa.
Tuolla perusteella oma tasoni olisi 9, sillä DLL-tiedostoilla en ole CB:n kanssa paljoa leikkinyt, (Niitä kun voi tehdä esim C++:lla, niin sitten voi käyttää C++ kaikkeen muuhunkin.) ja kaikkia vaikeita tehtäviä en ole jaksanut toteuttaa.
EDIT: typokorjauksia

[Viltzu]

Nooh, tuon Galgoneerin pisteytyksellä sain 11 pistettä. Muistipalat ja DLL ei suju ollenkaan, en niitä ole edes tutkinut.

Code: Select all

Galgoneer  9
Viltzu    11

Jos tehdään nyt uus taulukko Galgoneerin pisteytyksellä?[/size]

[Dande]

Nooh, tuon Galgoneerin pisteytyksellä sain 11 pistettä. Muistipalat ja DLL ei suju ollenkaan, en niitä ole edes tutkinut.

Code: Select all

Galgoneer  9
Viltzu    11

Jos tehdään nyt uus taulukko Galgoneerin pisteytyksellä?

11? Maksimi pistemäärä on kymmenen kuten alkuperäisessäkin...
Tietenkin jos esim. osaa tyypit hyvin, niin siitä saa 1 pisteen, ei ½ + 1 pistettä. Eli samasta asiasta vain yksi pistemäärä
Vai laitetaanko sama vielä oikein desimaaliluvuilla, niin on helpompi ehkä tulkitä:

• Tyypit (perusteet 0.5 piste, kehittynyt käyttö 1 pistettä)
• Objektit (perusteet 0.5 pistettä, kehittynyt käyttö 0.75 piste)
• Kuvat (perusteet 0.5 pistettä, kehittynyt käyttö 0.75 piste)
• Äänet (0.5 piste)
• Funktiot (perusteet 0.5 pistettä, kehittynyt käyttö 1 piste)
• Taulukot (perusteet 0.5 pistettä, kehittynyt käyttö 1 piste)
• Matemaattiset komennot, kuten sinit ja kosinit (perusteet 0.5 pistettä, kehittynyt käyttö 1 piste)
• Muistipalat (perusteet 1 piste, kehittynyt käyttö 1.5 pistettä)
• CB:n kanssa yhteensopivien DLL-tiedostojen tekeminen (perusteet 0.5 pistettä, kehittynyt käyttö 1 piste)
• CB:n manuaalin tehtävät (helpot 0.5 pistettä, keskivaikeat 1 piste, vaikeat 1.5 pistettä) //EDIT: Meinasi unohtua tähän vielä yksi murtoluku

EDIT: typokorjauksia

[Awaclus]

Tyyppien perusteet 0,5 + objektit kehittynyt käyttö 0,75 + kuvat "peusteet" 0,5 + äänet 0,5 + taulukot "peusteet" 0,5= 2,25

Mielestäni kuitenkin pitäisi lisätä "purkan hyvin kehittynyt käyttö", koska sen luultavasti saisin. Tosin yhteisprojektissa taitaisi tulla siitä enemminkin miinuspojoja.

[Jare]

... koska se estää goto-labelien käytön. ...

Mielestäni goto-labeleita ei saisi missään nimessä käyttää. Nehän nostavat vain koodin epäselvyyttä, ja tälläisessä projektissa kaikkien pitäisi saada koodista selvää. Hirvittää ajatellakkin projekti jossa on kymmenen eri koodaajan kyhäämä goto-viidakko, josta eivät itsekkään saa selvää. Tietenkin CoolBasic sisältää älyttömän funktiorajan, mutta kyllä siihenkin saa mahtumaan aika paljon tavaraa kun on säästäväinen.

CoolBasicista puuttuu Continue-komento For-lenkeistä, jonka korvaajaksi goto on mielestäni mainio keino. Toki ehtolauseella saadaan tämäkin aikaan, mutta goto säästäisi ylimääräiseltä If:ltä ja näin ollen myös ylimääräiseltä sisennykseltä.

[Dande]

CoolBasicista puuttuu Continue-komento For-lenkeistä, jonka korvaajaksi goto on mielestäni mainio keino. Toki ehtolauseella saadaan tämäkin aikaan, mutta goto säästäisi ylimääräiseltä If:ltä ja näin ollen myös ylimääräiseltä sisennykseltä.

Mieluummin kirjoitan ylimääräisen iffin, kuin luovun FVD:stä, sillä FVD tulee varmasti auttamaan useissa kirjoitusvirheiden metsästyksissä. Onhan totta, että Continuen korvaajaksi goto sopii kivasti, mutta kun otamme huomioon sen tuomat haitat verrattuina etuihin, niin FVD taitaa tuoda enemmän etua verrattuna Goton käyttöön