Do you think Sc could go commercial?

[Gnome]

in order to revive this quiet forum, I had a thought.

Experimenting with SC a bit has led me to the conclusion that SC is more then capable of handling engines (on a smaller scale) for most genres. Hell, there's even a turn based strategy game.

Do you think that SC has reached a point where if someone spent a good a amount of time making and engine and graphics, he could market said game?

Discuss.

[Gan]

Possibly. Sc is still a tad slow for a graphic intensive game and does lack certain things. Though probably could make a commercial game in it and maybe if somehow an iPhone compiler was added onto it....
Thinking out loud.


-Gan

[GMG Mike]

The Windows runtime definitely gives SC a boost here.

As far as speeds go: scripting speeds are improved in the next beta, and I think there's still room to get even faster. Graphics speeds could triple with a properly implemented switch to OpenGL. I believe these improvements would propel SC far past TNT Basic.

iPhone and iPad runtimes would give SC a unique advantage, making SilverCreator by far the easiest way to produce iOS games.

[Gan]

I made the Ultimate iPhone Template and the source files can be editted easily so if somehow you could make an Sc to iphone code converter then you could easily insert the code into the Ultimate iPhone Template. Then the user would just need to open and compile the iphone source in Xcode.


-Gan

[GMG Mike]

There needs to be a runtime made specifically for SilverCreator, to handle mundane tasks common to all games.

For example, instead of outputting the code to handle SPRITESTOUCHING every time that command is used, the runtime should have a method to handle that command, which can accept parameters such as which sprite number is involved.

Some things that you take for granted in Cocoa are written differently in REALbasic. These things must be rewritten in the runtime to act the same as in REALbasic. For example, although Cocoa may have some better way to determine sprite collisions, we must determine them identically to how the current REALbasic Runtime does so. Otherwise, cross-platform computer & phone games will not work correctly, and you will not be able to rely on the built-in debugging.

Another example would be networking code. We must implement the EZProtocol system so iOS and computer versions of the game may interoperate with command sockets. This should be done beforehand.

The biggest problem I can see right now is math support. SilverCreator uses left to right processing of math, while other languages will typically process in PEMDAS order.

[Gan]

Code: [Select]

For example, instead of outputting the code to handle SPRITESTOUCHING every time that command is used, the runtime should have a method to handle that command, which can accept parameters such as which sprite number is involved. 

Indeed. Something like that could be whipped up.

Code: [Select]

Some things that you take for granted in Cocoa are written differently in REALbasic. These things must be rewritten in the runtime to act the same as in REALbasic. For example, although Cocoa may have some better way to determine sprite collisions, we must determine them identically to how the current REALbasic Runtime does so. Otherwise, cross-platform computer & phone games will not work correctly, and you will not be able to rely on the built-in debugging. 

It'd just have to be made to work exactly alike. Though Xcode comes with a powerful debugger.

Code: [Select]

Another example would be networking code. We must implement the EZProtocol system so iOS and computer versions of the game may interoperate with command sockets. This should be done beforehand. 

I don't even want to think of networking. Networking works on the iPhone quite well but... I have no idea how it'd be paired to work with the EZ Protocol.
For making iPhone compatible games, it'd probably be best to not have networking enabled till it was sorted out.

Code: [Select]

The biggest problem I can see right now is math support. SilverCreator uses left to right processing of math, while other languages will typically process in PEMDAS order.

PEMDAS is the way to go. It really screws me up when I'm coding in Sc and it doesn't follow that. Especially when programming something math intensive.


-Gan

[GMG Mike]

It'd just have to be made to work exactly alike. Though Xcode comes with a powerful debugger.

We can't use any Xcode stuff though except for the command line compiling/app signing stuff. The idea is the user never has to touch Xcode. We can maybe have one special menu item like "Run in iPhone Simulator" or something like that, so they can do a quick check, but it should be written as such that the logic operates the same on iOS as it does in the debug mode (which would be augmented with a few extra features to act more like an iOS device when debugging in iOS mode).

I can imagine easy cross-device games, with finger input for the iOS and keyboard/mouse input for the computers. Some of SC's command really lend themselves to similar ideas on the iOS, such as PROMPT$ and even PROMPTCHOICES.

Code: [Select]

Another example would be networking code. We must implement the EZProtocol system so iOS and computer versions of the game may interoperate with command sockets. This should be done beforehand. 

I don't even want to think of networking. Networking works on the iPhone quite well but... I have no idea how it'd be paired to work with the EZ Protocol.
For making iPhone compatible games, it'd probably be best to not have networking enabled till it was sorted out.

EZ Protocol is just on top of regular TCP/IP. I don't think it would be too hard, but it would be something for the runtime.

Code: [Select]

The biggest problem I can see right now is math support. SilverCreator uses left to right processing of math, while other languages will typically process in PEMDAS order.

PEMDAS is the way to go. It really screws me up when I'm coding in Sc and it doesn't follow that. Especially when programming something math intensive.

Except if I switch SC to PEMDAS, all existing games will break. I also can't have PEMDAS for iOS and left to right for computers - then you can't easily compile the same game for both. Even if I have a checkbox for each game - "Use PEMDAS" - what if they don't check it and want to compile for iOS?

[Gan]

Code: [Select]

We can't use any Xcode stuff though except for the command line compiling/app signing stuff. The idea is the user never has to touch Xcode. 

True, after a google search I've found ways to make and run an iphone app via command line though... if they had the source they could easily switch from Sc to learning Obj-C in Xcode.

Code: [Select]

EZ Protocol is just on top of regular TCP/IP. I don't think it would be too hard, but it would be something for the runtime. 

I'm mostly worried about how time outs, data encryption, and the handshake would work.

Code: [Select]

Except if I switch SC to PEMDAS, all existing games will break. I also can't have PEMDAS for iOS and left to right for computers - then you can't easily compile the same game for both. Even if I have a checkbox for each game - "Use PEMDAS" - what if they check it and want to compile for iOS?

Best chance is to just take the jump to PEMDAS. Existing games will either have to be compiled with an older version or updated to support PEMDAS.


-Gan

[GMG Mike]

Code: [Select]

We can't use any Xcode stuff though except for the command line compiling/app signing stuff. The idea is the user never has to touch Xcode. 

True, after a google search I've found ways to make and run an iphone app via command line though... if they had the source they could easily switch from Sc to learning Obj-C in Xcode.

If SC is meeting their needs, why would they switch? The idea is that SC is easier. Anyone can switch to Xcode right now, but a lot of people are put off by it. SC is the solution.

Code: [Select]

EZ Protocol is just on top of regular TCP/IP. I don't think it would be too hard, but it would be something for the runtime. 

I'm mostly worried about how time outs, data encryption, and the handshake would work.

There is no encryption of EZ Protocol, and no handshake. Timeouts are dealt with in the normal TCP manner. The primary benefit of EZ Protocol is to be able to send data in "key, value" pairs, and receive data on the other end in the same exact manner.

Code: [Select]

Except if I switch SC to PEMDAS, all existing games will break. I also can't have PEMDAS for iOS and left to right for computers - then you can't easily compile the same game for both. Even if I have a checkbox for each game - "Use PEMDAS" - what if they check it and want to compile for iOS?

Best chance is to just take the jump to PEMDAS. Existing games will either have to be compiled with an older version or updated to support PEMDAS.

I'll look into it. I think I still want to support some kind of legacy mode though for old projects. New projects would only use PEMDAS, but old ones would be recognized by a flag set in the project, and would support switching.