Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers AppGameKit Corner / Two AGK questions

Author
Message
berserkivix
User Deleted
Posted: 23rd Dec 2016 10:20
Hello there.
I have 2 questions about AppGameKit, they are:
1) Is that object oriented?
2) Is there any GUI system?

Thanks in advance for any help.

Bye, Ivano.
Carharttguy
8
Years of Service
User Offline
Joined: 8th Jul 2016
Location: Belgium
Posted: 23rd Dec 2016 11:41
Hello

1) No
2) Very basic, you can show a button and a textboxx at this moment.

Cheers
Mathias
damothegreat
User Banned
Posted: 23rd Dec 2016 12:06
AGK is more Game Development not Application development

Maybe if you know C++, you can sure implement the Windows GUI side of things with core C++ and to work with and along side via AppGameKit Tier 2

Damo
Using Tier 1 AppGameKit V2
Started coding with AMOS
Anything is possible if put mind to it
Carharttguy
8
Years of Service
User Offline
Joined: 8th Jul 2016
Location: Belgium
Posted: 23rd Dec 2016 13:04
damothegreat is indeed right. Full application development is not the scope of AGK2. That's why there are no menu's, switches or sliders.

However, I do think some more GUI elements could be handy. I personally would like to have a dropdownlist for selecting races/classes.
damothegreat
User Banned
Posted: 23rd Dec 2016 13:34
Nothing is truly impossible though,

If anyone puts there mind to it - I'm sure we can create something along these lines with the use of the Draw and text commands with the mouse
pointer collision detections over them

I.E.
To create: our own-

- List boxes
- Combo boxes
- Menus
- Buttons
- etc
- etc

and build your own library of these to create Windows GUI style features from scratch all within AGK

errrrrm - very interesting

Damo
Using Tier 1 AppGameKit V2
Started coding with AMOS
Anything is possible if put mind to it
damothegreat
User Banned
Posted: 23rd Dec 2016 14:44 Edited at: 23rd Dec 2016 15:23
Something ive just knocked up in half hour



Try it, it can be all tweakable and indeed look more professional but it can be achievable.

To be honest, I'm going to carry on with this, will look like a good development learning experience and will send on some library in the near future

Damo
Using Tier 1 AppGameKit V2
Started coding with AMOS
Anything is possible if put mind to it
Cor
AGK Developer
13
Years of Service
User Offline
Joined: 19th Dec 2010
Location: Its a trap!
Posted: 23rd Dec 2016 18:53
There is not currently a gui system but you can easily achieve some great looking results with sprites. For my games i make a sprite and detect when the user hovers or touches the button and change the scale so it creates a nice pop effect.
berserkivix
User Deleted
Posted: 26th Dec 2016 08:39
Well, in truth I would be interested in something like BlitzMax GUI.
Also sorry to hear AppGameKit is not object oriented, BlitzMax is.
The downside about BM is that you can only deploy to Win, Mac and Linux, AppGameKit also supports Android and iOS.

Thanks anyhow.
MikeHart
AGK Bronze Backer
21
Years of Service
User Offline
Joined: 9th Jun 2003
Location:
Posted: 26th Dec 2016 09:15 Edited at: 26th Dec 2016 09:16
If the lack of OOP in AppGameKit is limiting you, then I feel bad for you. And maybe your OOP mindset is holding you back, to achieve the same things. I would look at the featureset of a tool. And the target platforms and audience of a tool. Size of a community. Is it easy to learn. These points would make up my decision.

Here are two lines, one is from my AGK2 framework, the later one is from my other framework which is OOP. Same amount of typing, Actually the AGK2 version uses one character less.
same functionality:



Now the OOP version



Interesting, isn't it?
Running Windows 7 Home, 64 bit, 8 GB ram, Athlon II X2 255, ATI Radeon HD 4200. Using AGK2 Tier 1.
Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 26th Dec 2016 10:44
Quote: "If the lack of OOP in AppGameKit is limiting you, then I feel bad for you. And maybe your OOP mindset is holding you back "

How do you figure that? OOP is much easier to write complex designs.

Are you telling me this: (unless agk can pass by reference, can it?)
player = positionPlayer(player, x, y)

Makes more sense than simply saying this:
player.position(x, y)

Not saying that you can't accomplish the same thing procedurally, but object-oriented is by far superior in terms of design structure.

berserkivix, unfortunately there are no gui commands. To design an application you'd have to make all your own components and manage them. If you need mobile support then stick with AppGameKit, otherwise BM might be a better solution. It is a more mature language afterall. It just depends on your goal and what your target is. And if you want html support, agk is about as simple as it gets.

"I like offending people, because I think people who get offended should be offended." - Linus Torvalds
MikeHart
AGK Bronze Backer
21
Years of Service
User Offline
Joined: 9th Jun 2003
Location:
Posted: 26th Dec 2016 14:32 Edited at: 26th Dec 2016 14:33
It is not a matter if it makes more sense. I said that you can achieve it in a similar way.

Phaelax wrote: " but object-oriented is by far superior in terms of design structure."


I think that varies a lot on the opinion of the individual. They both have their place in different projects and needs. Imho for AGK2 it definitely isn't needed. I used the BRL products extensively before. And other tools.
At work, we code without OOP. Works perfectly. If you limit yourself as a coder to a specific mindset, you will loose out.
Regarding game creation, AGK2 has a feature set that is one of best you will find with game programming languages.

Particles, Physics, Spriter, Spine, 3D, dynamic arrays (lists), Sound, Ads, various input methods, Tweens, Bitmap fonts, UTF8, Video playback, Social media, Multiplayer. You name it, you have it.

And today, it is basically the only actively supported one which is a relevant game programming language.

Why do you use AGK2 over the previous mentioned tools?
Running Windows 7 Home, 64 bit, 8 GB ram, Athlon II X2 255, ATI Radeon HD 4200. Using AGK2 Tier 1.
Dybing
13
Years of Service
User Offline
Joined: 12th Sep 2011
Location: Bergen, Norway
Posted: 26th Dec 2016 19:11
OOP is by and large just an open invitation to over-complicate things. In concept it sounds good, in practice however all you get are a plethora of glue-objects that got no reason to exist apart from facilitating communication between two other objects. It soon becomes an unholy mess of dependencies criss-crossing the enormous number of files required to provide a semblance of structure to this labyrinth. Untangling it is near impossible. Not to mention the verbose continous argument with the compiler, where every definition got to be filled out in triplicate before it passes. It's just horrible.

Unfortunately this methodology is taught as holy gospel at colleges and universities - brainwashing generation after generation of programmers to sacrifice their sanity at the altar of the great OOP deity. Breaking out of this cargo-cult mindset, removing the blinders, is hard for many to do.

Procedural Programming as with AppGameKit may not be optimal, but at least you get to keep your data separate from the operations. Better yet is Golang, where you get interfaces, methods, concurrency and channels. Either way, both approaches are much preferable to OOP.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 27th Dec 2016 17:11 Edited at: 27th Dec 2016 17:20
@MikeHart and @Dybing I agree with you two. One of the reasons I recently ended up here is because for the past few years or so I had been increasingly questioning all of the OOP stuff. Particularly the additional layers and layers of abstraction complexity the industry kept piling on such as DI and IoC but more than the specifics it was just what was actually happening in general. This obsession with adding more and more layers of complexity in an attempt to abstract away the implementation of things. And the craziest part is each new thing adds its own problems and then a year or two later a new pattern, another layer is added as a way to get around the problems introduced by the last one.

For a long time I embraced it all wholeheartedly. Truly C++ was my favorite programming language for many years. At work I still use OOP, interfaces and so forth. But for my own projects I decided to simplify. Because I came to believe we had all been led down a rabbit hole so to speak. And in reality, simple straightforward structured procedural programming was the ideal. The most efficient way to develop. Of course, a person does need to keep the concerns that OOP and these modern "best practices" focus on in mind. But that is actually very easy to do. Simple naming conventions for example go a long way. More importantly there are minimal layers of abstraction and perhaps even none at all. This has benefits such keeping the code easier to follow, easier to debug & enhance as well as maximizing the execution speed due to the processor not needing to continually grind through layers of abstraction to get to the code that is actually finally doing the real work.

With simple structured procedural design we can still abstract things as needed without buying into such a mindset wholesale and needlessly complicating every program we write. The way OOP and all of these modern best practices are presented today is of most use for academics and people more interested in software engineering to tinker around with. People who get more satisfaction simply out of designing a complex abstract very loosely coupled system. On the other hand, if your goal is to actually create products such as games I think buying into such a mindset greatly increases the cost without any real benefit. Again, assuming you are keeping the concerns in mind and designing & programming smart to begin with.

For example, I would use this syntax:

speed = PlayerGetAngle()
PlayerSetPosition(x, y)

The first word is always the object (or object type anyway) followed by the actual purpose of the method.

Now don't take that all the wrong way. I may well switch over to C++ & AppGameKit at some point just to try it out. But I certainly won't be using IoC and all of the other crap that is preached these days for proper software design. Basically I am just saying that for me whatever makes things the simplest & fastest way to program is the way I want to be using.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 28th Dec 2016 15:48
Quote: "speed = PlayerGetAngle()
PlayerSetPosition(x, y)"


So are the player variables global then? Those functions have no implication of what data it's interacting with.
I too follow a specific structure, though I start my names with get or set as it is common naming conventions in java which is what I'm used to. And java as you probably know is all OO, which I will always argue is better. I'm not arguing that procedural is easier and quicker. But I find OO more scalable and definitely more manageable in large projects.

"I like offending people, because I think people who get offended should be offended." - Linus Torvalds
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 28th Dec 2016 16:31
@Phaelax yeah the player would be global. Generally speaking the instance of player in an OOP implementation would also be global just referenced as player. I'm not against using basic OOP with classes. I have no problem with them. I just no longer view it as being superior.

Basically it comes down to would you prefer to type a dot or not for this case? player.GetAngle() or PlayerGetAngle(). Yes with OOP all of those methods are encapsulated beneath player. All I am getting at is this is stuff that can be easily managed ourselves with naming conventions.

Really there is no right or wrong. It is whichever approach works best for a person. I can see pros and cons of both methodologies but have no issue with using basic OOP. I just have no issue using structured procedural programming either. But I also do it with an OOD in mind. I always have and that is why when I first got into C++ long ago I loved it.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 29th Dec 2016 15:37
My twopenneth...

For a simple game I think that structured programming is a better option, especially for newcomers and hobbyists. To write Flappy bird using OOP methodologies would be overkill.
For a AAA title, OOP is clearly essential. You simply couldn't manage the complexities (easily) in a structured environment.

I use many languages, and choose the right one for each job.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
Ortu
DBPro Master
17
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 30th Dec 2016 06:42
It's easy to start over-engineering things when working with OOP, when everything is a sub class of a sub class, you know it's time to start exercising some self restraint and rethink the design. It doesn't have to get that complicated.

That said, when dealing with entities and components that encapsulate instances of complex data, OOP class objects are just a natural fit. Naming convention is only equivalent at the most basic levels. My AGK/DBpro code follows strict conventions and formats to emulate simple OOP classes/objects as closely as possible. In most cases it does the job, for something like managing RPG characters however, convention alone simply falls short.

The biggest issue is simply maintaining an accurate reference to a given entity within a dynamic list of entities. This is very simple in OOP, an entity is itself and contains it's own properties and methods which it can call upon itself. In procedural with convention, you have to do a lot of array iteration and lookup to simply find the data you are looking for, or to find the correct index to pass to a function. This can add up to costly overhead and require greater complexity of code.

At the end of the day, most OOP languages can be used almost entirely procedurally, they generally only hold what complexity you build into however and whatever you use them for.
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
Dybing
13
Years of Service
User Offline
Joined: 12th Sep 2011
Location: Bergen, Norway
Posted: 30th Dec 2016 14:21 Edited at: 30th Dec 2016 14:22
A great video mulling over the deficiencies of OOP:

https://www.youtube.com/watch?v=QM1iUe6IofM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 30th Dec 2016 16:18 Edited at: 30th Dec 2016 16:21
@Dybing I agree with many of the thing the creator of that video is talking about. Like I mentioned in my first post above I am not against OOP wholesale. I appreciate what it was trying to solve and believe if used right it is actually a good thing in many cases. But all of the other crap that has been piled on over the years is what I am mainly against. All of these patterns and "best practices" that serve primarily to convolute and increase the complexity of code in an attempt to fix issues found in the patterns and "best practices" added before.

I like just a simple design structure. I do use managers but not some "proper" academic level manager. Rather just a very simple organizational thing. If a game has enemies I will have an enemy manager and perhaps even multiple enemy managers. This becomes a way to group all code into a central place.

Basically I guess through my own experience over the decades I arrived at some of the same "best practices" that are preached these days. It's the way these things are being implemented that I don't agree with. It seems like at every opportunity people have taken the initiative to add more complexity. To over-engineer. I don't think abstraction is a good thing in general. I do think there are specific cases where it is good.

I have no problem with global variables. Yet I do think control to them should be managed. For example, any code could simple get or set the position of the player by directly accessing the appropriate global variables. That kind of thing can cause issues. An easy solution is simply to create functions inside my PlayerManager code file PlayerGetXPos() and PlayerSetYPos(). And PlayerSetPosition(xp as integer, yp as integer). This allows the PlayerManager to always be aware when something is checking or attempting to change the player position. More importantly, if something ever changes only one spot these methods need to be updated.

I used to be a big fan of OOP and all of the patterns and so forth that have been tacked on. Like I said, it was just in the past few years I started really questioning all of this stuff. In most cases it is causing people to write programs that are needlessly complex and verbose.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Dybing
13
Years of Service
User Offline
Joined: 12th Sep 2011
Location: Bergen, Norway
Posted: 30th Dec 2016 17:21
You should look into Golang GarBenjamin

You get the best of all worlds - and very little of the crap. Want objects, sure, define an interface and declare some methods to it. Done. But your data is still just data, and not tangled up with some class object. Great way to decouple code. It gets even better when you add the easy to use concurrency model. If I must have a criticism of Go, it is all the boilerplate code to handle errors. It is done on a function to function basis, so if you do call a function that got error reporting, you can either ignore it (not recommended) or you have to set up the boilerplate:

x, err = doStuff()
if err != nil {
// handle error
}
// continue doing stuff

It do result in code that contain quite a few lines that don't really add much to what you're trying to do. But it do catch errors

Login to post a reply

Server time is: 2024-11-24 16:19:17
Your offset time is: 2024-11-24 16:19:17