October 17, 2019, 05:34:53 PM

Author Topic: [PAID] Screen Framework for AGK?  (Read 1438 times)

Offline Qube

  • Administrator
  • Hero Member
  • *****
  • Posts: 2148
Re: [PAID] Screen Framework for AGK?
« Reply #15 on: May 29, 2019, 06:22:51 AM »
Sell it.
I'd have to do full documentation, multiple examples of how to use and spend a lot of time offering support ( based on if it'd even sell ). My real life work unfortunately wouldn't allow the time I'd prefer to support such a thing and I'd never release something commercial that I couldn't support properly.

I think the market for a full AGK game framework is very small to be honest.
Until the next time...

Offline LineOf7s

  • Jr. Member
  • **
  • Posts: 68
    • LineOf7s Entertainment
Re: [PAID] Screen Framework for AGK?
« Reply #16 on: May 29, 2019, 06:46:49 AM »
You're not wrong there.

Still, for that small market - and the right price - maybe selling it "as-is" (eg comments = documentation) is enough?  Support's always a pain though.  I can see why people might be inclined to just release code into the wild (open source and/or public domain) just so they can say "No support!  Leave me alone!" and get on with their lives.  :)

Offline Derron

  • Hero Member
  • *****
  • Posts: 2484
Re: [PAID] Screen Framework for AGK?
« Reply #17 on: May 29, 2019, 07:03:38 AM »
Open Source does not mean you do not have to do some kind of support / are liable - which is why many licences limit liability ;-)
You cannot invent a mass destruction weapon, put up the sources and say "it is up to you what you do with it" ...albeit none of our codes is a MDW  8)


@ economic environment of AGK
Yes I think it is a small world in which you would sell your framework. Benefit is the lack of "competitors" and that people (most of them at least ;-)) already have shown their will to pay for stuff (they bought AGK).


bye
Ron

Offline MikeHart

  • Hero Member
  • *****
  • Posts: 617
    • Cerberus X
Re: [PAID] Screen Framework for AGK?
« Reply #18 on: May 29, 2019, 01:45:20 PM »
Anything that is endorsed by TGC might have some commercial success. If you are on your own, you will find yourself getting unnoticed quickly. Imho it isn't worth the effort.


Offline Qube

  • Administrator
  • Hero Member
  • *****
  • Posts: 2148
Re: [PAID] Screen Framework for AGK?
« Reply #19 on: May 29, 2019, 11:30:18 PM »
@ economic environment of AGK
Yes I think it is a small world in which you would sell your framework.
I agree. Even if I were to make a super excellent framework I think I'd be lucky to even reach 50 sales to be honest. The thought of selling it ( when it's all done along with the tools ) never entered my head. Yup, it'll remain for my own personal use, it'll be too awesome to sell ;D
Until the next time...

Offline Rick Nasher

  • Hero Member
  • *****
  • Posts: 783
Re: [PAID] Screen Framework for AGK?
« Reply #20 on: May 30, 2019, 06:54:50 PM »
@Qube:
Love your fading routine, very cool.  8)
_______________________________________
 B3D + physics + shaders + X-platform = AGK!
:D ..ALIENBREED *LIVES* (thanks to Qube).. :D
_______________________________________

Offline Qube

  • Administrator
  • Hero Member
  • *****
  • Posts: 2148
Re: [PAID] Screen Framework for AGK?
« Reply #21 on: May 30, 2019, 10:12:40 PM »
@Qube:
Love your fading routine, very cool.  8)
Thanks. Very simple but handy for scene changes with "things to do" if needed.
Until the next time...

Offline Derron

  • Hero Member
  • *****
  • Posts: 2484
Re: [PAID] Screen Framework for AGK?
« Reply #22 on: May 31, 2019, 06:57:46 AM »
@Qube:
Love your fading routine, very cool.  8)

Why? He is increasing a value or decreasing it - and executing/changing someting when it reaches a certain point.
Think this is what a fader does...


In a more OOP manner you would have a fader object which you update/render and which sends out events or runs callbacks which you can register. So you can run:
- onFadeStart
- onFadeProgress
- onFadeHalf
- onFadeEnd
...
That way you can easily start initializing stuff in your new scene or pause action or whatever you need to do.


Also this leads to:
- replaceable code (you can use other fader/effects by replacing one line in your code then)
- reusable code (not mixing game logic with presentation logic)


While Qube's code is (for now) simple enough to replace stuff here and there (eg with a function callback instead of straight game logic in the fader functions) I am sure that he would do it differently when it has to be added to his framework lib/code.



bye
Ron

Offline Qube

  • Administrator
  • Hero Member
  • *****
  • Posts: 2148
Re: [PAID] Screen Framework for AGK?
« Reply #23 on: May 31, 2019, 09:53:00 AM »
Quote
Why? He is increasing a value or decreasing it - and executing/changing someting when it reaches a certain point.
Perhaps he just liked the simple method of using a single pixel and being able to do other things?. Doesn't have to be over complex to be liked.

Quote
In a more OOP manner
OOP for everything!

The Faster You Unlearn OOP, The Better For You And Your Software
;D

Quote
While Qube's code is (for now) simple enough to replace stuff here and there (eg with a function callback instead of straight game logic in the fader functions) I am sure that he would do it differently when it has to be added to his framework lib/code.
True, this is just a version of what I use at the moment as it's super simple to use. When part of my shiny new framework it won't be in this manner as I want to also have different effects and options available during the fade process.
Until the next time...

Online Steve Elliott

  • Hero Member
  • *****
  • Posts: 2044
Re: [PAID] Screen Framework for AGK?
« Reply #24 on: May 31, 2019, 10:06:15 AM »
Quote
Why? He is increasing a value or decreasing it - and executing/changing someting when it reaches a certain point.

It's called not over-complicating something that does not need to be over-complicated!

Quote
In a more OOP manner you would have a fader object which you update/render and which sends out events or runs callbacks which you can register. So you can run:
- onFadeStart
- onFadeProgress
- onFadeHalf
- onFadeEnd
...

Oh please!  Events and callbacks for such a simple task.   :P

When all you have is a hammer, everything looks like a nail.

In other words when all you have is an OOP approach, every little piece looks like an OOP solution.  Which is nonsense, can overcomplicate and make your code inflexible to changes.
Windows 10, 64-bit, 16Gb RAM, CPU Intel i5, 3.2 GHz, Nvidia GeForce GTX 1050 (2Gb).
MacOS Mojave, 64-bit, 8Gb RAM, CPU Intel i5, 2.3 Ghz, Intel Iris Plus Graphics 640 1536 MB.
Linux Mint 19.1, 64-bit, 16Gb RAM, CPU Intel i5, 3.2 GHz, Nvidia GeForce GTX 1050 (2Gb).
Raspbian Buster, pi4 4Gb RAM,1.5Ghz

Offline Derron

  • Hero Member
  • *****
  • Posts: 2484
Re: [PAID] Screen Framework for AGK?
« Reply #25 on: May 31, 2019, 11:19:05 AM »
Callbacks/Events are the way to go if you give your code to third party programmers / writing libraries.
As soon as your code becomes kind of a "black box" you will have to allow modification somehow.


OOP makes it flexible to change - as all you need is to use another "variant" (eg "extending class").

If you wanted to reuse your code but this time you want to have some mosaique-transition instead of a fade-to-black you need to code it in both fashions yes - but then, after some time you see that the base logic has a flaw or needs extension. Now you have to go through all your different "fader functions" and update/fix the portion. Then you go to another project you were using this code too - again copy/paste functions around and maybe pasting stuff over functions which had little adjustments here and there (slower fade, other color, ...).

In OOP (or if you split your fading stuff into multiple functions - its the same then you replace your "fader.base.file" with the new file, recompile the application and you are done.


Of course you do not have to write a complete fader class if you intent to only use it ONCE in all your projects. KISS then.
But if your plan is to create stuff to reuse in other projects - or stuff which needs to be configurable ("modding") or dynamic ("scripted") then you won't be able to keep it that simple.

You plan to have multiple faders simulataneously (eg. a split-screen game)? Have two fader objects/instances instead of copying functions to not interference with some globals you are using - or maybe having to add some functions just to make the "second split screen world" still updating and rendering.


OOP (or other stuff) are in no way the holy grail but there is a reason for such stuff to be still thought and used in many projects. Rapid prototyping is of course something different and also I did not want to say Qube's code is bad. It's just that the whole approach is not something "wow" or "magnificient". It is something I would consider "basic knowledge" (inc or dec values and use the value to do something) for non-beginners in coding. It's like the usage of "sin" to smoothly do transitions between two values (there are other formulas/functions ... I know).


bye
Ron

Offline Qube

  • Administrator
  • Hero Member
  • *****
  • Posts: 2148
Re: [PAID] Screen Framework for AGK?
« Reply #26 on: May 31, 2019, 11:24:43 AM »
Quote
I did not want to say Qube's code is bad. It's just that the whole approach is not something "wow" or "magnificient". It is something I would consider "basic knowledge" (inc or dec values and use the value to do something) for non-beginners in coding.
The code was not meant as a showcase how how great I am ;D - It was a simple solution to Amon asking how you could code game transitions with fade in / out in AGK.
Until the next time...

Offline Derron

  • Hero Member
  • *****
  • Posts: 2484
Re: [PAID] Screen Framework for AGK?
« Reply #27 on: May 31, 2019, 01:44:55 PM »
@ Qube
I know that it was just to show how things could be done and I am not saying it is bad - I just defended why I questioned Ricks "Love your fading routine, very cool.  8)" - especially as it is nothing "special" - maybe things are different if you never had any fade in your games and think of using a "progress indicator" (= your fade value multiplier) as something they'd never come up.


bye
Ron

Offline iWasAdam

  • Hero Member
  • *****
  • Posts: 1313
Re: [PAID] Screen Framework for AGK?
« Reply #28 on: May 31, 2019, 01:52:41 PM »
You know what?
Fading a screen is something 'Very special'! it's not the simple task it first looks, especially when there are other controls or displayed object to take care of.
You need to have 'thought' about all the other stuff and how they fit together and operate.

I'm with Rick - very cool fading routines. It's very special :)



Online Steve Elliott

  • Hero Member
  • *****
  • Posts: 2044
Re: [PAID] Screen Framework for AGK?
« Reply #29 on: May 31, 2019, 03:17:59 PM »
Derron it's very rude and quite arrogant to say somebody else's code is not very impressive in your eyes, when others have praised it.  You might want to think and keep some thoughts to yourself.

And as for OOP there are plenty of ways to code software, every time you keep jumping on threads telling people how to code their own damn projects!  If advice is ASKED for then fair enough.  If somebody is very happy how their code runs (efficient, fast and easy to follow) then you come along, oh that's not very good I would have done it THIS way.  Then we come back to arrogance and just plain being rude.
Windows 10, 64-bit, 16Gb RAM, CPU Intel i5, 3.2 GHz, Nvidia GeForce GTX 1050 (2Gb).
MacOS Mojave, 64-bit, 8Gb RAM, CPU Intel i5, 2.3 Ghz, Intel Iris Plus Graphics 640 1536 MB.
Linux Mint 19.1, 64-bit, 16Gb RAM, CPU Intel i5, 3.2 GHz, Nvidia GeForce GTX 1050 (2Gb).
Raspbian Buster, pi4 4Gb RAM,1.5Ghz