AppGameKit Classic Chat->AGK Survey
Z
Zubby1970 Joined: 22nd May 2008
Location: AGK Studio Always
Posted: 6th Feb 2011 2:56
i think most good programmers will know more than they think they know about language design. as a full time programmer myself i know which languages i like and which i dont.

DBpro is an awsome language to use for development, so i think if they keep along those lines AppGameKit should be just as powerful and easy to use.

keep up the good work guys.
B
Benjamin Joined: 24th Nov 2002
Location: France
Posted: 6th Feb 2011 3:14
i think most good programmers will know more than they think they know about language design. as a full time programmer myself i know which languages i like and which i dont.


DBpro is an awsome language to use for development


No offence but any good programmer will know that the language has many flaws that can be corrected in AGK.

I'm just thinking most people will vote for what they know, since it's easiest for them. That and they think DBP is a great language.
B
bitJericho Joined: 9th Oct 2002
Location: United States
Posted: 6th Feb 2011 11:12
I would like to be the first to say that I verifiably have no idea what I'm talking about.
S
Sph!nx Joined: 3rd Dec 2008
Location: The Netherlands
Posted: 6th Feb 2011 11:52
Am I the only one sceptical about the idea of taking on-board the opinions of random people taking a survey who probably don't know much about language design, and how such changes could benefit the language?

I'm just thinking most people will vote for what they know, since it's easiest for them. That and they think DBP is a great language.


Isn't that the whole point?

We want AppGameKit to be the tool you want.
D
DVader Joined: 28th Jan 2004
Location:
Posted: 6th Feb 2011 15:51
Well, all I can say to Benjamin's comment is quite simple. If you love C++ so much then why even use DB? The whole point of this was to have a DB style language for mobile apps, that is quick for people who know DB to take up and get running. As far as I can see the fastest way to achieve this is to keep it pretty much the same. If things are going to be changed radically then people who know DB will not be able to jump in as easily and may well be put off.

I see the tier 1 package really being for DB users who want an easy in to programming for multiple devices. They will have little or no interest in learning C++ syntax, and will want it to be as similar to DB as possible.

People who are pushing for language changes might want to consider a higher tier and just using c++ anyway. They may well already know it (else why push for changes), and will probably want to go that route so they can publish themselves(the tier one option looks to me like it will use an emulator/virtual machine type app to run any game wrote in app game kit. You must publish through TGC using this.)

I do think a lot of peeps are forgetting the tiers, and changing the basic one to mimic C++ style, yet have none of the speed advantages, to me seems a waste of time.
B
Benjamin Joined: 24th Nov 2002
Location: France
Posted: 6th Feb 2011 16:39
@DVader: I don't see why you mention C++ in every paragraph, what does it have to do with altering the syntax of AppGameKit slightly? Some of the suggested changes are common in many languages, and they benefit the language in either conciseness or functionality, as well as possibly making compilation easier or quicker. I see nothing wrong in using syntax that shares similarity with other popular programming languages, it's not going to really add any difficulty to using the language. If anything it's going to be easier to learn since you won't be confused by ambiguous statements.

Isn't that the whole point?


Of course, they want their current and potential customers to be interested, but if the language is improved (ie. changed) it'll attract more business in the long run. Some of the things suggested in that survey may be beneficial to overall users, and I'm just worried that they are going to cater it to DBP users that basically want the exact same syntax and functionality that they are used to, regardless of the long-lasting impact it might have.
S
Sph!nx Joined: 3rd Dec 2008
Location: The Netherlands
Posted: 7th Feb 2011 12:23
Well, I think, correct me if I'm wrong, that the developers are trying to create a code syntax similar to DB Pro but advance or upgrade that.

The survey is just for that, to see how many people are using/wanting the DB syntax and what needs to be improved on that.

Edit:
I think it's great that the developers are involving us like this!
D
DVader Joined: 28th Jan 2004
Location:
Posted: 7th Feb 2011 18:07
I mention C++ because that has the sort of syntax you mention. Obviously other languages use similar systems and I hate each one of them lol. I also have been programming on and off in DB since it was first released, the original, not pro. Because of this I know it pretty well, and having a new tool that works the same way would be a great help, rather than having to relearn commands.

I don't have any real issues with the way DB Pro works at the moment, apart from a bit more speed of course. So I am fairly happy to keep agk as close as possible to it. As to people voting for what they know to make it easier, what's wrong with that? As far as I am concerned anything that makes it easier to finish a project is welcome. It is also not possible to be easier to learn, than already knowing the language in the first place. Of course for new people perhaps that could be true, perhaps not. I personally do not find any of the DB syntax to be confusing whatsoever.

If for instance, TGC had said they were developing a similar system to this but completely c++ based rather than with support for DB based code I would not have even the slightest interest. Even as it is, the idea of an app running in some sort of emulator, when using the db based code, is off putting anyway. I may be wrong about that but as they have not elaborated on it too much I can only guess that is how it works.

My point is that a lot of users here will prefer a DB compatible version, especially if they plan on using existing projects that they may have worked on for some time. I have no projects to use, as mine are all 3D, but some people probably have.

It's all a matter of personal preference. I don't think TGC are going to get many pro devs using the tier 1 version of agk, possibly the higher ones, but for those, the db interface sounds immaterial.
C
Clonkex Joined: 20th May 2010
Location: Northern Tablelands, NSW, Australia
Posted: 14th Feb 2011 1:48
Can't wait for this to be released! Should be as much like DBPro as possible, including how the brackets, spacing, and in-sensitivity. It should definitely NOT be case sensitive!

Can't wait!

Clonkex
H
HowDo Joined: 28th Nov 2002
Location: United Kingdom
Posted: 14th Feb 2011 17:49
Will have the ablity to add user plugin's, sorry if this was in the FAQs .

Edit
You guess it miss that one when I read it the first time,
L
LeeBamber Joined: 21st Jan 2000
Location: England
Posted: 25th Feb 2011 20:13
Hi Guys,

Thanks for the feedback and comments, it's a great indicator as to what the community is looking for to create cross-platform apps Just to keep up the interest, here is some code that is compiling and running now in AppGameKit Tier 1:

+ Code Snippet
rem Small Game Test
LoadImage ( 1, "backdrop.png", 0 )
Sprite ( 1, 1, 0.0, 0.0 )
img=LoadImage ( "sprite.png", 0 )
iDeviceWide# = 240 : iDeviceHigh# = 360 : iAspectRatio#=(iDeviceWide#/iDeviceHigh#)
gridx#=100.0/7.0
gridy#=gridx#*iAspectRatio#
dim sprx(500) as float
dim spry(500) as float
dim sprfall(500) as integer
for s=1 to 300
 Sprite ( 100+s, img, -100.0, -100.0 )
 SetSpriteSize ( 100+s, gridx#, gridy# )
next s
gameloop=1
gamerestart=1
while gameloop=1
 rem Reset
 if gamerestart=1
  gamerestart=0
  gamespeed=12
  rowpos=0
  rowindex=1
  rowqty=3
  lastrowqty=3
  rowdir=1
  rowtimer=0
  rowobjoffset=1
  rowobjoffsetindex=0
  gameblockfall=0
  for s=1 to 500
   sprfall(s)=0
  next s
 endif
 rem Control
 if gameblockfall=0
  if GetTouchPressed()=0 then click=0
  if GetTouchPressed()=1
   if click=0
    inc rowindex
    tshiftpos=0
    if rowindex=2
     rowqty=3
    else
     if lastrowpos>rowpos
      deduct=lastrowpos-rowpos
      rowqty=rowqty-deduct
      for trim=0 to deduct-1
       sprfall(100+rowobjoffset+trim)=1
      next trim
      tshiftpos=deduct
     else
      if lastrowpos<rowpos
       deduct=rowpos-lastrowpos
       deduct=deduct-(lastrowqty-rowqty)
       if deduct>0 
        rowqty=rowqty-deduct
        for trim=0 to deduct-1
         sprfall(100+rowobjoffset+((lastrowqty-1)-trim))=1
        next trim
       endif
      endif
     endif
     if rowqty<=0
      gameblockfall=1
      rowobjoffsetindex=rowobjoffset
     endif
    endif
    lastrowpos=rowpos+tshiftpos
    lastrowqty=rowqty
    rowobjoffset=rowobjoffset+3
    gamespeed=gamespeed-1
    rowpos=-1
    rowdir=1
    click=1
   endif
  endif
  rem Logic
  inc rowtimer
  if rowtimer>gamespeed
   if rowdir=1 then rowpos=rowpos+1
   if rowdir=2 then rowpos=rowpos-1
   rowtimer=0
  endif
  if rowpos>5 then rowdir=2
  if rowpos<-1 then rowdir=1
  rem Row Qty
  for rq=0 to rowqty-1
   sprx(100+rowobjoffset+rq)=(rowpos+rq)*gridx#
   spry(100+rowobjoffset+rq)=100.0-(rowindex*gridy#)
   SetSpritePosition ( 100+rowobjoffset+rq, (rowpos+rq)*gridx#, 100.0-(rowindex*gridy#) )
  next rq
  for rq=0 to rowobjoffset+rowqty
   if sprfall(100+1+rq)=1
    spry(100+1+rq)=spry(100+1+rq)+1.0
    SetSpritePosition ( 100+1+rq, sprx(100+1+rq), spry(100+1+rq) )
   endif
  next rq  
 else
  rem block fall to start again
  if rowobjoffsetindex>0
   inc rowtimer
   if rowtimer>5
    rowobjoffsetindex=rowobjoffsetindex-1
    rowtimer=0
   endif
  else
   inc rowtimer
   if rowtimer>50
    gameblockfall=0
    gamerestart=1
    rowtimer=0
   endif
  endif
  for rq=rowobjoffsetindex to rowobjoffset+rowqty
   spry(100+1+rq)=spry(100+1+rq)+1.0
   SetSpritePosition ( 100+1+rq, sprx(100+1+rq), spry(100+1+rq) )
  next rq  
 endif
 Sync()
endwhile
end


As you can see, it's still very close to DBC/DBP but brings some of the better features from other languages such as spaceless commands, brackets on non-expression commands and commands that auto-assign index numbers such as img=LoadImage("file",flag). Still a few tweaks to make such as square brackets for the arrays, but I've been coding DBP for so long I'm going to miss by smooth brackets for array handling

We've also had time to do lots of performance tests across multiple devices and we're pleased to report the interpreter system is hideously fast, and more than capable of running your apps. To put the engine in context, the Dark Basic Classic product was an interpreter engine and some amazing games have been created with that language.

Watch out for the newsletter for more AppGameKit news! Again thanks for the feedback, it's a great help.
H
Hodgey Joined: 10th Oct 2009
Location: Australia
Posted: 25th Feb 2011 22:09
Looks great!!! And for the great debate that is going on in the other thread you've been able to satisfy both views with the LoadImage command.
B
Blobby 101 Joined: 17th Jun 2006
Location: England, UK
Posted: 26th Feb 2011 11:56
That's cool, I like the way you can use reference numbers OR handles for loading media, that's a nice way of keeping everyone happy
B
Benjamin Joined: 24th Nov 2002
Location: France
Posted: 1st Mar 2011 11:09
I'm sorry, but that code looks hideous.

For starters, you're supporting those archaic hash and dollar symbols for variable types which look messy and can lead to confusion if (like DBP) you allow them to be typed as something else. If not, you (as the compiler writers) have to write pointless additional logic to make sure you can only declare variables ending with # as floats, and those ending with $ as strings. I'd say do away with these symbols completely as they contribute little to the language other than making more complex syntax.

Command stacking is also hard to read, and potentially ambiguous. Remove that ability, and you'll again have simpler syntax and easier to read code, without losing anything from the language. Additionally, parsing will be easier.

All variables in that code are lowercase, which apart from making the code look a mess make me wonder if you're not actually using case-sensitivity, which without option-explicit is undoubtedly going to cause problems for many users. Also, it's inconsistent with your use of camel case for function names.

On a note unrelated to the language itself, the spacing and indentation makes that code yet harder to read. You've put spaces around brackets yet you don't put them in relevant places in equations and assignments, which need clarifying more than anything else.

I'm curious, apart from functions requiring brackets will there be any other differences from DBP's outdated syntax?
D
DMXtra Joined: 28th Aug 2002
Location: United States
Posted: 1st Mar 2011 12:13
Yes, I agree the # and $ are not really needed and are out of date, if you want to know what you defined them as you can always look at the variable init part of your code. It does make the code look very messy.

The other things like formatting the IDE should do for you, so that isn't a big deal.
C
Ched80 Joined: 18th Sep 2010
Location: Peterborough, UK
Posted: 1st Mar 2011 13:27
Personally - i prefer the # and $ syntax - if you have a lot of code you wouldn't need to search to find what type the variable was declared as - it makes debugging a lot easier.

Thought overall the sample was helpful and didn't put me off.
D
Digital Awakening Joined: 27th Aug 2002
Location: Sweden
Posted: 1st Mar 2011 14:08
Yes, I agree the # and $ are not really needed and are out of date


They are also quite annoying to type, at least on a Swedish keyboard. # requires Shift and $ requires Alt Gr.

I guess they are in there for those that doesn't want to declare their variables. However, just using . for floats and "" for strings should be enough IMHO.
M
Mike Johnson Joined: 13th Sep 2002
Location: United Kingdom
Posted: 1st Mar 2011 17:49
Something to bear in mind is this - the use of # and $ is optional. You can declare variables like this:

myValue as float
myString as string

As far as spacing, indentation, naming etc. that is all down to personal preference and is simply the way Lee has written it for this example, others can do it their own way.
D
DMXtra Joined: 28th Aug 2002
Location: United States
Posted: 2nd Mar 2011 2:19
Well, the fact that they are optional, works for me.
C
Conjured Entertainment Joined: 12th Sep 2005
Location: Nirvana
Posted: 21st Mar 2011 14:39
I have a feeling that a lot of newcomers will want to jump on board this thing.
A thorough manual will guarantee smooth sailing for everyone.

Just to keep up the interest, here is some code that is compiling and running now in AppGameKit Tier 1:

Looks like Tetris or something.