I've been wanting to develop a couple 2D games along with my 3D projects, and I just have a couple questions regarding AGK.

Arrays within User-Defined Types
Does AppGameKit allow this? =) I've read yes... just wanting to make sure

Functions that return UDT's
Is this possible? It's not possible with DBP, but I'm hoping yes with AGK

Also, what kind of data storage is there? XML, CSV?

UDTs can now be passed in and returned from functions which should open up many more useful possibilities. There are no arrays in types at this stage, though the workaround is pretty respectable for now:

TYPE leetype
myarray[100] AS FLOAT
ENDTYPE
lee AS leetype
lee.myarray[50]=42.0

For now, becomes:

TYPE leetype
ENDTYPE
lee AS leetype
DIM lee_myarray[100] AS FLOAT
lee_myarray[50]=42.0

I know you can do a few more things with arrays inside types you can pass around, but hopefully this global solution allows you to carry on while we debate internally about static vs dynamic arrays in types. I'd rather protect AppGameKit T1 users from pointers if I can.

Don't forget AppGameKit T2 users can create arrays in types all day long using industry standard C++ and a very easy to use multi-platform game engine

Hey Lee---
Thank you for the clarification. Although I do appreciate that types can be passed in and out of functions, unlike how it is in DBPro - I really, really hate the workaround solution that you gave. I think it is messy code that cannot be easily extended. What if you need to have a varying amount of leeTypes, and thus a varying amount of leeArrays?

However, an acceptable workaround that I've been using (for DBP) is within IanM's plugin kit - get arrayptr, load arrayptr, unload array, etc. It involves pointers - to a very limited extent - but it also allows better design patterns than what you posted. I mean, having access to a limited subset of pointers whose usage is completely optional is very different than forcing a person to use them at gunpoint (but that's just me)

So yeah, thank you for the clarification. And I'm not rich enough - or dedicated enough - for the Tier2 app development. But as it stands right now, I have to say this is "one step forward, one step back" and that I cannot commit to AppGameKit until this is resolved.

No worries, we'll get there soon - though it might just be static arrays in types to start with for T1 (BASIC). Just for clarity, T2 (C++) which allows pointers of all types, is provided along with T1 (BASIC) as part of AppGameKit and you don't need a Mac to use T2. You can grab a copy of Visual Studio Express for free from Microsoft and open up the same examples in T2 as you see in T1 through VS2008 (soon VS2010). The commands are almost identical and you really can be up and running within an hour. If you're on the fence, I highly recommend the T2 (C++) option as it will have all the data handling you require without any of the pain of diving into an obscure API. Just to keep the momentum on this proposed feature, can you throw up some code samples of what you think it might look like and the usage variations might be. Sorry if you repeated this elsewhere. Off the top of my head, I see it like this:

TYPE leetype
myarrayA[10] AS FLOAT
myarrayB[50] AS FLOAT
myarrayC[100] AS FLOAT
ENDTYPE
lee1 AS leetype
lee2 AS leetype
lee2=leefunc(lee1)
print(lee2.myarrayB[25])
end
function leefunc(leevar as leetype)
retvar=leevar
retvar.myarrayB[25]=42.0
endfunction retvar

NOTE: Just for reference guys, the above code does not compile. It's a work in progress proposal for basic arrays in types!

Essentially the static arrays are of a fixed size attributed to the type structure itself and can be nested in multiple user types. As they are fixed, UDT variables can be copied between each other where those variables share the type.

Hey Lee -
Thank you for the reply. I do like this option. The problem I've always had with UDTs in other languages is that it always would do a shallow copy when it came to arrays, but I think this would avoid that.

And anyway, there's workarounds to fixed length arrays. But even with the work around, this is much more elegant.

Thank you much, looking forward to further developments.

I think that would be a good idea, because it would keep UDTs behaving as a struct/value type (the term depends on your language I guess).

As for the pointer issue, I think it'd be nice if we could do a reference type system:

REFERENCETYPE playertype
score AS INTEGER
ENDTYPE

airslide AS playertype

airslide = CREATE(playertype)
addpoints(airslide)
Print(airslide.score)
DELETE(airslide)

FUNCTION addpoints(player AS playertype)
player.score = player.score + 5
ENDFUNCTION


Note the explicit REFERENCETYPE. That would be key so that you don't accidently mix n' match and so that the compiler knows that 'playertype' variables need to be treated as pointers.

EDIT: Come to think of it, I think that whole feature could probably be created with the existing language features, just with a little preprocessing so it amounts to syntatic sugar. The above could be translated into this:

DIM playertype_HEAP[100] as playertype

TYPE playertype
alive AS INTEGER
score AS INTEGER
ENDTYPE

airslide AS INTEGER

airslide = CREATE_playertype()
addpoints(airslide)
Print(playertype_HEAP[airslide].score)
playertype_HEAP[airslide].alive = 0

FUNCTION addpoints(player AS INTEGER)
playertype_HEAP[player].score = playertype_HEAP[player].score + 5
ENDFUNCTION

FUNCTION CREATE_playertype()
index AS INTEGER
repeat
index = index + 1
until playertype_HEAP[index].alive = 0
playertype_HEAP[index].alive = 1
ENDFUNCTION index


So it's just an index to a global array (obviously a robust solution requires a little more work towards array size and such). It realy just amounts to an easier way to use what I think a lot of people already do in DBP. Notice the "compiler"'s addition of the alive flag, the create function and the "heap" array. Where ever the UDT fields are accessed it replaces it with the array lookup, otherwise it is thrown around as an integer.

I think references and pointers are thorny issues for the beginner, but we'll keep hacking away at it until we come up with something elegant and so slight it hardly looks like an addition