DizzyAGE New Features Board

Hey,
I'm starting this thread to give people a chance to submit NEW ENGINE FEATURES to be included in the official DizzyAGE version.

First of all, this does NOT mean I plan to put time to extend DizzyAGE.
It worked fine for more than 10 years and for more than 140 games.
But, since the sources are free, people may come up with really good new features or even solve possible bugs.
Since my time is very limited, I'd like to make sure these new features or changes are really needed by a lot of people and that they make sense for DizzyAGE and its original intentions.

Also a BIG concern is PORTABILITY. I want to be able to bring all the existing games to any future platform or OS just by porting the engine. Any games using custom versions of the engine or doing platform specific things may not be portable.

All developers should use the official DizzyAGE version if they want to assure a long life for their games. Keep it clean and simple!

Here are a few ideas about how this could work.

- Who can submit changes?
- active DizzyAGE developers who changed the engine and feel these changes are useful for others too
- if changes are in engine code experience in C++ is needed and strong understanding of DizzyAGE engine
- if changes are in the official script templates, experience with these is needed

- Who should review changes?
- active DizzyAGE developers who have one or more games finished
- if changes are in engine code experience in C++ is needed
- if changes are in the official script templates, experience with these is needed

- Who should vote changes?
- developers making games with DizzyAGE engine, if these changes are really useful for their games too

- What can be proposed?
- bug fixes, as soon as you spot them :smile:
- new editor accessibility features or extensions for easier use
- new engine (game) features, if they are really useful for everyone

- What is the post format?
- start with the feature title in each post to help people speak about it
- state the type of the change (bugfix, editor extension, game feature, etc.)
- what is it and why is it needed
- where are the changes (link to sources and compiled engine) including only this change (for easy code compare)
- do it one feature at a time

- Before you post
- make sure the change is useful for everybody
- make sure it is aligned to the original intention of DizzyAGE
- make sure it is aligned to the code style and you understand the engine flow very well
- make sure it doesn't break the existing games (test!)
- make sure it doesn't limit future features (like using an important shortcut key for a not so important task)
- make sure it doesn't reduce COMPATIBILITY and PORTABILITY (and is wrapped well in the engine)

- After a post
- active developers who think the feature is useful, please test and review
- if it's an engine change involving C++, people with C++ skills could do a review and point eventual improvements
- developers who are interested (but not sure how to review), vote for the feature
- when enough reviews and votes, please notify me on email so I can have a look as well.

Let's take it slowly and make sure these changes are really needed in the official version.
Again, I don't plan to make DizzyAGE do something different than it was created for, but some updates can be made official if people really need them.

Wasn't sure where to post this but I've found a small error in the movement.gs file.

The section:

func CM_CheckJumper()
{
x1=0;y1=0;x2=0;y2=0;
PlayerMakeBB(&x1,&y1,&x2,&y2);
materials = MaterialRead(x1,y2,x2,y2+1); // read materials under the player

should read:

func CM_CheckJumper()
{
x1=0;y1=0;x2=0;y2=0;
PlayerMakeBB(&x1,&y1,&x2,&y2);
materials = MaterialRead(x1,y2,x2-x1,1); // read materials under the player

The difference is the coordinates in the MaterialRead function, which uses the format (x,y,w,h), unlike all the other materials functions, which use (x1,y1,x2,y2)

Noggin, what problems does the error cause? Can't say I've noticed any problems with jumping (fixed or otherwise). Thanks.

The function's only used if you turn on the custom movement, so most games won't be affected at all. But if you do turn it on, try putting a jumper in the middle of a room somewhere and then jump Dizzy around to the left of it. Make sure the jumper material extends a little way below ground level. You should find Dizzy starts bouncing without touching the jumper - it's because the box that detects the collision extends too far to the right, because the coordinates in MaterialRead are wrong.

Agreed, I only use custom movement for climbing up beanstalks etc and running fast ..but I've made a note of your remedy and will add it to both movement files just in case. I don't use the 'basic' scripts as I've always included all the clever little extras people have mentioned over the years (such as Jamie's re-spawning on dry land when killed underwater without a scuba) as my 'template' script folder. You won't believe the size of my 'utility.gs' file. ...or the size of the menus and handlers file in my latest game that deals with 100 costume changes.

PS - would you believe I've only just realised how to utilise the direction Dizzy is moving in when he hits a collider :wall:

What are your thoughts on uploading the source to GitHub,

(If people want to make their own changes that you don’t want to support they can fork and you have visibility of that. Like Scripting Engine)

If they want to propose new features they can raise an ISSUE, discuss the pros/cons like you suggest here, then a PR can be made, reviewed, updated based on feedback then added to the app.
They could help with implementation if willing and able.

There could also be other repos for storing example games, scripts from the forum for specific techniques for game mechanisms, sprites etc

*copy pasted from my email to Lex_Hedley (alex)*

The best thing for DizzyAGE now is to keep it in the current state, sorry :smile:

One reason is that I no longer work on it and I don't have the time to keep it all together if it starts branching. If there will be any compatibility issues with future OS (Windows) versions, or if I do a porting on other platform, I can only fix or upgrade the current version of the engine, so all the current games will live on. If people start branching the engine code and adding engine features in code, I won't be able to maintain those, and a lot of games may be lost. So, it's best to keep it simple, and use it for what was intended.

Also, there are already a lot of games running on the current version. When I had finished with the last version, there weren't this many games running on older ones, but I had to do a pass through them and port them to the new one. Now, there are too many to do that. My main target, and the initial promise, was to keep all these games alive, by assuring engine compatibility. Because of that, I have to keep the engine development closed.

GitHUB is a place for dynamic open projects, in development, so it's not the best option in this case. Also, not many people know how to used. Consider that some people who started using DizzyAGE had no prior programming skills at all.

If you plan to make a game that *really* needs specific new engine features, the sources are open for you to start from. But I don't want to label it a "offical DizzyAGE" version, and have people start creating games on it, for the reasons mentioned above

That being said, the engine still does a great job for the kind of games it was built for. I wanted people to focus on creativity, story and puzzles, not on features and tech. Because of its scripting, it still has a lot of flexibility and many new features can be added per game, in scripts, and used by whoever needs that functionality. Indeed it would be great to have a place to document better all those script pieces and practices. The Yolkfolk forum was and still is a great place for this, starting from the original docs, and from bits of code used in games by people who spent more time to master it.

So, even if the engine development is closed, there's perfectly fine to have more than one place where people discuss about making games, script features or modules, best practices, etc. If you want to organize something like this, feel free to do it - not sure what's the best format though. Also keep in mind that Yolkfolk forums are still the place where the DizzyAGE developers are, where they ask questions, where they post their games in progress or released, etc. Trying to create another similar place, would not be easy nor useful. So ask around here and see what kind of resources are they missing. I personally feel that more tutorials would be needed. Lik "how to do" article/docs organized in categories, tagged or whatever way is best.

Also I feel that youtube playthrough videos of the existing games would be great. My kids played my "Dizzy and the Other Side" recently, and my Q&A proved limited. I couldn't find the "secret" room (shame on me) until I opened the editor. There was some videos in Russian that looked really funny, and I wanted to get what they were saying. So yeah, I vote for youtube playthrough for games, linked in the Yolkfolk DB :teethy:

Keep in mind that, if at one point I'll make a new version, either for fixing compatibility, or porting, I'll be on this thread and see if something needs fixing or adding. Also I'll make sure all current games on the latest official version will work. So post here anything relevant.

One addition I'd like to see is changing how room names and item names are stored to support lower-case without using workarounds. The former would require an editor change as well as an engine change, but backwards compatibility can be assured by having an engine option set by default (FORCE_UPPERCASE, say) which changes the relevant text to upper case at point of use in the inventory/HUD code.

Also, automatic line breaks for Message().