Pages: 1
  Print  
Author Topic: new Build mode  (Read 2701 times)
Offline (Unknown gender) TGMG
Posted on: September 22, 2010, 09:30:01 AM

Developer
Joined: Jun 2008
Posts: 107

View Profile WWW Email
This is just a suggestion for the future which I think would be quite nice.

The idea is this: click 'play in build mode' it will start the game as a frame in lgm, there will be play pause and stop buttons in lgm toolbar, when 'pause' is clicked it will pause the game and allow it to be edited with lgm. Click play and the changes will be loaded into the game. Also a way to save the game states and load them, so if something doesn't work you can go back and test it again with the changes over and over.

Basically very similar to Unity.

Possible way to implement:

The game can be rendered in an lgm frame fairly easily, Lwjgl does this, and so does the android port of enigma. It just calls the c++ enigma function render() through JNI every frame.
When paused it simply won't call render() so it won't update the game loop, until play is pressed.

Now to allow the changes in lgm to be sent to the enigma game, somehow the enigma plugin needs to be able to execute a function when the save button is pressed for that resource. If that is possible then, simply pass the parameters of that resource (or a bytestream to be read) to a c++ function in enigma through JNI.

Example:
Lets say the user paused the game, opened a sound, loaded a different sound and changed the kind. When they click save it should call a JNI function in enigma to update the data in game.

bool jni_update_sound(index, sounddata, kind, effects, volume, pan, preload) {
// update data for sound index
// could even call sound_replace(index, fname, kind, preload)
}

Now for objects, timelines and scripts or anything else with code.
something similar to: http://www.codeproject.com/KB/cpp/gecko1.aspx?msg=2531522
Where each resource is actually its own dynamic library, when the user clicks save for that resource it will compile it then call a JNI function to reload the dll.

I'm not sure if that would work in practise but it would make it much easier to build games imo.
Just an idea  :)
Logged
me
GMbed 2.0 :: Embed you gm games in websites.
Offline (Female) IsmAvatar
Reply #1 Posted on: September 22, 2010, 02:01:30 PM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 886

View Profile Email
It's called Design Mode now. The way it usually works is that it's entirely the responsibility of Enigma to interpret the game and display the window and the Design buttons, so we bypass all those dll calls.

JNI has proven too difficult to develop in, so we've opted to use JNA instead, which is how LGM calls Enigma for various things like syntax checking and compiling.
Logged
Offline (Male) Josh @ Dreamland
Reply #2 Posted on: September 22, 2010, 09:46:35 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2956

View Profile Email
First, for those who don't know, the original Build mode was designed for live-action development. For one thing, it was made to be largely hot-key based. Imagine you are one of the brave ones developing Sonic clones in Game Maker. Sonic is running through the course at 50 miles an hour, then he hits a springboard and goes flying. He's about to fall off the screen, but right before he does, the user presses Ctrl-Space and places a new springboard. Or a new piece of earth. Or a new anything.

Design mode, the new, less-ambiguously named Build mode, was meant to incorporate features that the IDE component simply couldn't offer; the simplest example of that is non-orthographic design. And I chose to say non-orthographic instead of 3D to imply that even in 2D games (which are, yes, technically orthographic), some trait of the game could make it exceedingly difficult to accurately place objects, such as rapidly changing levels or simulated 3D layers. In perspective 3D, this problem becomes even more apparent.

Now, TGMG's proposal appears to be to keep the outputted game in communication with LGM via JNI. We run into a number of problems if we want to try that, particularly;
  • As Ism hinted, JNI is a little bitch. So she's using JNA. I'm not a Java person, so this is out of my scope and falls entirely on Ism. However, the same principle applies in the end for the callback functions TGMG mentioned; ENIGMA has such callbacks as JNI offers provided via JNA. So we could work around this, for the most part. Rendering inside the LGM window, however, wouldn't work.
  • Even if rendering in the LGM window were possible via JNA (or if we got JNI working), we're also assuming that all VMs by which ENIGMA can be emulated (Android and iPhone included) would be capable of accessing thread information from the running operating system, which I think is highly unlikely. Not to mention, an emulator will not always be available, where writing the data to a file is -always- an option as the game will -never- be on ROM (Honestly, how would the typical user put it there? [Okay, yes, discs, but those are totally unnecessary]). I have a very special plan in store for build mode that would not be able to work alongside LGM.
  • If the user doesn't like the changes (s)he made, there will be a lot of backtracking involved to revert them. A file makes it easy to say "Accept Changes?": if they say no, the file is ignored and deleted.
  • I would like build mode to offer a tile and instance creation API. For example, instead of dynamic rendering of "tiles" for auto-generated levels, the user could make calls to an API to remove them all, then re-create them according to their surroundings instead of drawing them as they do in Game Maker. I am unsure of the implications of allowing users to make calls to JNA willy-nilly; perhaps there are no further implications than having them do so with the file interface.

Basically, to get the most out of cross-compilation with this mode, the game needs to be dependent on the smallest number of items possible. Including the IDE. The two should shake hands after the fact, and not rely on each other in the mean time.
« Last Edit: September 22, 2010, 09:49:44 PM by Josh @ Dreamland » Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) Rusky
Reply #3 Posted on: September 23, 2010, 09:56:23 AM

Resident Troll
Joined: Feb 2008
Posts: 955
MSN Messenger - rpjohnst@gmail.com
View Profile WWW Email
Rendering the game in the IDE is more of a screen-estate problem than anything- if you have a way to show them both on the screen it's not really a problem. The real issue is using the same methods to edit the game in both design mode and the regular IDE- that is a very important point in UX.

Storing game data in such a way that it could be put in version control would be a far more general and flexible solution than putting design mode changes in an extra file. Design mode could just put in its changes normally and then the IDE could provide a repository browser to allow the user to revert them.

Getting design mode on e.g. the Wii is a good idea, but in general it only needs to work for the developer, who has the IDE. The convenience of editing things the same way in design mode and the IDE far outweighs, in my opinion, the convenience of running it on actual hardware.
Logged
Offline (Unknown gender) luiscubal
Reply #4 Posted on: September 23, 2010, 12:10:12 PM
Member
Joined: Jun 2009
Posts: 452

View Profile Email
At least on Windows, putting the game window on LGM should be possible(since TGMG has done GMBED, I'll take his word on the difficulty or simplicity of doing this). On *NIX systems, I have no idea. But, at least on X11, it is *possible*(though it might be ugly and weird).

As to IDE <-> game communication, I'm guessing this should be fairly easy. I mean, at most you'd have to make the game set a server at localhost:1234 and stream the changes(and I believe there are easier ways to deal with this problem).
Logged
Offline (Unknown gender) TGMG
Reply #5 Posted on: September 23, 2010, 02:02:22 PM

Developer
Joined: Jun 2008
Posts: 107

View Profile WWW Email
Quote
First, for those who don't know, the original Build mode was designed for live-action development. For one thing, it was made to be largely hot-key based. Imagine you are one of the brave ones developing Sonic clones in Game Maker. Sonic is running through the course at 50 miles an hour, then he hits a springboard and goes flying. He's about to fall off the screen, but right before he does, the user presses Ctrl-Space and places a new springboard. Or a new piece of earth. Or a new anything.
Yes, this made me realise a huge gap in my idea, LGM wouldn't know about all the instances created/moved at runtime so it would be hard to place the springboard.

So my idea has now changed, not to replace the current build/design system, but to allow LGM or any other process to stream data to the game, the game picking up the data at the end of the game loop, maybe display an updating message/image then changing the resources and continuing. Not for tiles and instances as that is covered by the current design mode, but for resources, like sprites (bounding box, images etc), paths etc.

1) I just mentioned JNI as it is the api i have the most experience, afaik JNA would work fine.
2) The rendering in the lgm window would only work for windows, mac and linux and wouldn't render other platforms. But the rendering in the window was only to save switching between the lgm window and the game constantly to make changes. if the data was sent through the network technically it could send the changes to the actual device, saveing the long process of compiling, linking, building package, installing package and running, on mobile devices, ever time thee is a change.
3) That is true, but still possible to work around, like Ruskys idea, or creating a snapshot *.gb1 type file just before it is run.
4) Yes i realise that, so this system wouldn't replace the current, but just be a kind of way to update resources like sprites, bounding boxs, paths and hopefully scripts without going through the whole process of compiling and running.

Quote
At least on Windows, putting the game window on LGM should be possible(since TGMG has done GMBED, I'll take his word on the difficulty or simplicity of doing this). On *NIX systems, I have no idea. But, at least on X11, it is *possible*(though it might be ugly and weird).
Most opengl based java games actually do this, any games based on LWJGL, Jmonkey or slick all are using a opengl context and rendering it in a java panel using JNI.

Quote
As to IDE <-> game communication, I'm guessing this should be fairly easy. I mean, at most you'd have to make the game set a server at localhost:1234 and stream the changes(and I believe there are easier ways to deal with this problem).
Ah yes i much prefer this idea to my JNI idea, being able to stream data to the game and checking for that data at the end of the game loop would be a much better idea. It wouldn't technically be tied to LGM either as any process could stream data to it, users could even make there own specialised game editor if they wanted.
It would allow enigma games on iphone, android and wii to be developed on pc and stream the changes to the device. It could even allow developing on windows for example and streaming the changes to a remote computer such as a mac. Without having to either change the game on mac or constantly moving the game from windows to mac to test it.
Or even having the game running on multiple platforms at the same time (android, iphone, wii) changing the data in lgm and seeing the results instantly on all of them.

Ofc the real power of this would be if it was possible to change and interpret scripts. A system where at the start the game is compiled normally, so all scripts are actually compiled as they would normally be for performance. But if a script is changed and streamed to the game, it will change the function pointer to that script to the interpreted script instead. So all normal scripts will still be executed as c++ apart from the changed ones which will be interpreted.
Logged
me
GMbed 2.0 :: Embed you gm games in websites.
Offline (Male) Rusky
Reply #6 Posted on: September 23, 2010, 08:26:54 PM

Resident Troll
Joined: Feb 2008
Posts: 955
MSN Messenger - rpjohnst@gmail.com
View Profile WWW Email
You could just recompile changed scripts- I know Visual Studio can usually update code while the program is running, GCC should be able to do it as well.
Logged
Offline (Male) Josh @ Dreamland
Reply #7 Posted on: September 27, 2010, 07:59:13 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2956

View Profile Email
I gave this some thought, and I'd like to go through with it. It will need to be set up such that it is -not- mandatory.
I was unaware that VStudio could recompile while the executable runs. I will be looking into that; I was originally planning to do some work with DLLs to load new objects and whatnot, but we'll see what I can't do if I find such a module. Recommendations welcome.
So yes, I have more planning to do for it, and more research to do on it. We'll see what I come up with.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) RetroX
Reply #8 Posted on: September 27, 2010, 08:37:05 PM

Master of all things Linux
Contributor
Location: US
Joined: Apr 2008
Posts: 1055
MSN Messenger - classixretrox@gmail.com
View Profile Email
You could just recompile changed scripts- I know Visual Studio can usually update code while the program is running, GCC should be able to do it as well.
It operates differently under Bash than under Windows.

The currently executing code would be cached; if you updated the executable while it was running, you'd have to start it over again in order to make it run with the new code.  Or at least, I think.  The GCC could modify the actual executable file, but I have no idea if it would be allowed in Windows.
« Last Edit: September 27, 2010, 08:40:49 PM by RetroX » Logged
My Box: Phenom II 3.4GHz X4 | ASUS ATI RadeonHD 5770, 1GB GDDR5 RAM | 1x4GB DDR3 SRAM | Arch Linux, x86_64 (Cube) / Windows 7 x64 (Blob)
Quote from: Fede-lasse
Why do all the pro-Microsoft people have troll avatars? :(
Offline (Male) notachair
Reply #9 Posted on: September 28, 2010, 04:01:55 AM

Definitely not a chair
Contributor
Joined: Feb 2008
Posts: 299

View Profile
You could just recompile changed scripts- I know Visual Studio can usually update code while the program is running, GCC should be able to do it as well.

Since when?

« Last Edit: September 28, 2010, 04:03:53 AM by a2h » Logged
Offline (Male) Rusky
Reply #10 Posted on: September 28, 2010, 05:04:03 PM

Resident Troll
Joined: Feb 2008
Posts: 955
MSN Messenger - rpjohnst@gmail.com
View Profile WWW Email
Updating the executable wouldn't really be the way to do it- you need to compile the code and then write it over the old method in memory. A part of the debug executable (possibly on the debugger side) would grab the new code and do the writing itself. In addition to Visual Studio, you can even do it on a much lower level with DEBUG.

Of course you can't use Edit and Continue it in situations where e.g. there's not enough room to overwrite the old code with the new code or the code you change is running when you change it. However, it does work in other situations: Edit and Continue.

And in any case, if Enigma used a JIT compiler, that kind of behavior would be built right in from the start. ;)
« Last Edit: September 28, 2010, 05:06:07 PM by Rusky » Logged
Offline (Male) Josh @ Dreamland
Reply #11 Posted on: September 28, 2010, 06:27:20 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2956

View Profile Email
If the code is long enough for a CALL, I don't see how its length really matters. Regardless, the whole ordeal could be arranged with a table of function pointers by event ID... there's really no need to waste load time on JIT when you have this much control over the game's assembly. And I mean assembly, not ASM.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Pages: 1
  Print