[PAID] Screen Framework for AGK?

Started by Amon, May 26, 2019, 16:27:52

Previous topic - Next topic

Qube

Quote from: LineOf7s on May 29, 2019, 00:15:13
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.
Mac Studio M1 Max ( 10 core CPU - 24 core GPU ), 32GB LPDDR5, 512GB SSD,
Beelink SER7 Mini Gaming PC, Ryzen 7 7840HS 8-Core 16-Thread 5.1GHz Processor, 32G DDR5 RAM 1T PCIe 4.0 SSD
MSI MEG 342C 34" QD-OLED Monitor

Until the next time.

LineOf7s

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.  :)
"Life's biggest obstacles are your greatest opportunities to excel"

Derron

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

MikeHart

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.


Qube

Quote from: Derron on May 29, 2019, 07:03:38
@ 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
Mac Studio M1 Max ( 10 core CPU - 24 core GPU ), 32GB LPDDR5, 512GB SSD,
Beelink SER7 Mini Gaming PC, Ryzen 7 7840HS 8-Core 16-Thread 5.1GHz Processor, 32G DDR5 RAM 1T PCIe 4.0 SSD
MSI MEG 342C 34" QD-OLED Monitor

Until the next time.

Rick Nasher

@Qube:
Love your fading routine, very cool.  8)
_______________________________________
B3D + physics + shaders + X-platform = AGK!
:D ..ALIENBREED *LIVES* (thanks to Qube).. :D
_______________________________________

Qube

Quote from: Rick Nasher on May 30, 2019, 18:54:50
@Qube:
Love your fading routine, very cool.  8)
Thanks. Very simple but handy for scene changes with "things to do" if needed.
Mac Studio M1 Max ( 10 core CPU - 24 core GPU ), 32GB LPDDR5, 512GB SSD,
Beelink SER7 Mini Gaming PC, Ryzen 7 7840HS 8-Core 16-Thread 5.1GHz Processor, 32G DDR5 RAM 1T PCIe 4.0 SSD
MSI MEG 342C 34" QD-OLED Monitor

Until the next time.

Derron

Quote from: Rick Nasher on May 30, 2019, 18:54:50
@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

Qube

QuoteWhy? 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.

QuoteIn a more OOP manner
OOP for everything!

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

QuoteWhile 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.
Mac Studio M1 Max ( 10 core CPU - 24 core GPU ), 32GB LPDDR5, 512GB SSD,
Beelink SER7 Mini Gaming PC, Ryzen 7 7840HS 8-Core 16-Thread 5.1GHz Processor, 32G DDR5 RAM 1T PCIe 4.0 SSD
MSI MEG 342C 34" QD-OLED Monitor

Until the next time.

Steve Elliott

#24
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.
Win11 64Gb 12th Gen Intel i9 12900K 3.2Ghz Nvidia RTX 3070Ti 8Gb
Win11 16Gb 12th Gen Intel i5 12450H 2Ghz Nvidia RTX 2050 8Gb
Win11  Pro 8Gb Celeron Intel UHD Graphics 600
Win10/Linux Mint 16Gb 4th Gen Intel i5 4570 3.2GHz, Nvidia GeForce GTX 1050 2Gb
macOS 32Gb Apple M2Max
pi5 8Gb
Spectrum Next 2Mb

Derron

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

Qube

QuoteI 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.
Mac Studio M1 Max ( 10 core CPU - 24 core GPU ), 32GB LPDDR5, 512GB SSD,
Beelink SER7 Mini Gaming PC, Ryzen 7 7840HS 8-Core 16-Thread 5.1GHz Processor, 32G DDR5 RAM 1T PCIe 4.0 SSD
MSI MEG 342C 34" QD-OLED Monitor

Until the next time.

Derron

@ 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

iWasAdam

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 :)



Steve Elliott

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.
Win11 64Gb 12th Gen Intel i9 12900K 3.2Ghz Nvidia RTX 3070Ti 8Gb
Win11 16Gb 12th Gen Intel i5 12450H 2Ghz Nvidia RTX 2050 8Gb
Win11  Pro 8Gb Celeron Intel UHD Graphics 600
Win10/Linux Mint 16Gb 4th Gen Intel i5 4570 3.2GHz, Nvidia GeForce GTX 1050 2Gb
macOS 32Gb Apple M2Max
pi5 8Gb
Spectrum Next 2Mb