XYG Studio [Game Development Kit]

[Kelvin]

eXperience Your Game

What is it?
XYG Studio is a runtime-based game development kit that uses SDL and the Squirrel scripting language. When it is done, the editor will run on Windows, Mac, Linux, Open Pandora, and Pyra. The runtime environment itself will be open-source, allowing it to be ported onto any platform, and even rewritten to run using different languages (it's being written in C++, but could be rewritten in C# for XBox or Java for browsers and whatnot). It can even be rewritten to work with other graphics APIs like SFML, OpenGL, SDL2, etc. so it'll work on virtually any platform.


What does it do?
The editor aims to feel as much like Game Maker's as possible while addressing a few issues and adding a bit more control to the way the game works. Although the game structure will be different, the required skill level will be about the same. Rather than mislead users by saying they can make a game without a single line of code (action icons follow the same logic as code, so they're really the same, just with different presentation), the included tutorials will teach how to code in Squirrel while building a game from the ground up.

Some issues found in Game Maker include things like always-on code that does not always do as the developer wants, and causes bloat and overhead when circumvented. XYG solves this by being as minimalistic as possible. Actors, the objects that are placed in a map via the level editor, will only start out with the most essential variables, and leave everything else to the developer to define (i.e. gravity, speed, direction, etc.). Components are like actors, but they have no physical body, so variables like x, y, sprite, shape, etc. are free to be redefined.

The room editor is split into two: a map editor and a level editor. The map editor is just for tiles and solid geometry. The level editor is where actors and components are placed, allowing multiple levels to use the same map. For instance, houses could share a common design and just use different characters to live in them, so recycling maps becomes an effective means of saving file space.

How much will it cost?
Nothing. You don't even need to pay for a license to make commercial games. You are, however, allowed to redistribute it, so long as you don't try to sell the editor or runtime. The project will be entirely donation-funded.

How do exports work?
Games can be exported by building a .xyg file that the runtime will open and play from. This file contains the game's resources and game-specific code, but does not include the standard code found in the editor; the runtime provides this to help trim down file size. If you're worried about players not having the runtime installed or that a new version may make your game unplayable, simply distribute the required version with your game. The editor will feature an option to create a batch/shell file to handle launching your game for you, so you don't have to reassociate with the old version every time you want to play your game.

Can I help?
The code has not been released yet. I'll post a link as soon as it's up.



Currently, the runtime is stable. I'd been having trouble with a few things earlier, but that's all fixed, so I'm progressing once again. The sprite class is working beautifully, and even cleans itself up at the end of execution. The RE also produces a log file that lists events and their time of execution. Shape classes are almost done. I'm working on using the separating axis theorem for hit detection, since it looks fast and reliable. Keyboard controls are working perfectly now, and I'll be working on the map editor after I've done hit testing. Essentially, I'm doing it in this order:

*Graphics
*Keyboard
*Collision
*Files
*Maps
*Levels
*Scripting
*Joystick
*Sound
*Networking

The editor will be written in Qt, and I'll start that once I've gotten maps implemented. Oh, also, levels will be able to have their own variables as well.

Change log:

Spoiler

V 0.0.7:
~Fixed all graphics glitches. Sprite rotation and pivot position now match up perfectly.
~Fixed all input glitches. Key release checks now work properly.
~Rewrote collision code to be faster and more simple.
~Removed string input handling. String input methods vary from game to game, so it's better to let users define how this works.

V 0.0.6:
~Created new class xyShape as parent for all shape classes.
~Hit test functions have been merged into a single function.
~Hit test can now be called through the shape instance.
~Temporarily removed support for OpenGL.

V 0.0.5:
~Merged window, string input and camera classes into a single game engine class.
~Added linked list to sprite class for data management and endgame cleanup.
~Turned shape structures into classes and rewrote hit test functions to fit.
~Revised most of the library so it's more organized.
~Removed Box2D for the time being.

V 0.0.4:
~Created sprite class.

V 0.0.3:
~Included Box2D.
~Created camera class.
~Organized functions into separate files.
~Created a function that flips an image.
~Included SPriG.

V 0.0.2:
~Added function to force a bit depth on loaded images.
~Turned vector structure into a class.
~Deleted vector-related functions and made better versions in the class.

V 0.0.1:
~Added basic graphics functions, shape handling, basic collision, and window class.
~Started actor and block classes.
~Actor class is complete enough to be useful.
~Image load functions include options to preserve or optimize file format.

[blazekick]

cool i love the idea of this project by any chance may have have a pic of the UI. i think this make this difference between good or bad well difficult to get in to programs like blender look to cluted up (but good program) hope this is not.

[Neweegee]

Networking? Like online features? If so, perhaps you could add functions specifically for making online Multi-player easier to add, because I wanted to do it in Game Maker, but it takes a ton of code in almost every corner of the game to make it work properly.

[Kelvin]

cool i love the idea of this project by any chance may have have a pic of the UI. i think this make this difference between good or bad well difficult to get in to programs like blender look to cluted up (but good program) hope this is not.

The runtime doesn't have a UI. On consoles like Dingoo, I plan on having it automatically launch a "game" that lets you select other games, unless I can figure out file association for those. If you run the runtime without giving it a game as an argument, it'll just flash a screen saying "NO GAME LOADED". I'm doing this to keep the runtime small and not require much change between platforms. If you're asking about the editor, I haven't started that yet; just imagine what Game Maker's UI looks like.

Networking? Like online features? If so, perhaps you could add functions specifically for making online Multi-player easier to add, because I wanted to do it in Game Maker, but it takes a ton of code in almost every corner of the game to make it work properly.

Unfortunately, all games require unique functions for online play. I'll mainly be focussing on IP connections and FTP/HTTP protocols. If I were to do some kind of client/server-type connection, it would take a lot more time and have to come later.



I'm having a weird problem where the screen surface doesn't want to scale up to the window size. It's weird, since I'm using the same exact code my sprite scaling uses, so it should be working. I've got a friend looking at my code, so it should be fixed in time. Meanwhile, I'm setting up all my shapes to be able to draw themselves, so I can start the hit test tests. ^^

[Kelvin]

OK, so update time. I fixed the screen scaling; not entirely sure how I did it, but it works now. ^^ I also fixed sprite rotation/scaling, and did a little test of scaling.



The screen can be set to interpolate, if wanted, and does a good job of rendering without losing frame rate, even when Midi is scaled to ridiculous sizes. I know it seems choppy here, but that's because I forgot to set the frame rate on Gif Cam.

Next, I'm finally gonna get off my procrastinating butt and do the shape hit checks. After that, I'll be moving on to the Squirrel bindings, and then I'll make a test game.

[Kelvin]

Added a change log to the OP so people can follow development with each version.

[~Axis~]

Wow I cant wait for this to be completed. It seems very very useful. Thank you for starting something like this. I hope the tutorials will go in depth to how to use the app properly.

Will the app take alot of space?

[Kelvin]

Nah, altogether, it should just be a couple megs. Even Game Maker is only 3MB, so this may be smaller, depending on how much I decide to put in.

[Kelvin]

Small update, my friend showed me JSON, and I've changed the game definition file from XML to JSON. The game definition tells the RE certain details about the game, such as what title to display on the window or game selection for console/handheld versions, a description of the game for the planned market, the game's internal ID to differentiate it from other games, particularly those that have a similar or identical title (because so many people are gonna come up with Sonic: the Overused Title anyway), and requirements of the game to run, such as hardware rendering, network features, gamepad initialization, etc.

Here is the template for the JSON file:

Code:

{
    "XYG" : {
        "app" : {
            "id" : "appname.author.0001",
            "appdata" : "gameName"
        },
        
        "version" : {
            "major" : 1,
            "minor" : 0,
            "release" : 0,
            "type" : "alpha"
        },
        
        "author" : {
            "name" : "Author",
            "website" : "website.com",
            "email" : "author@email.com"
        },
        
        "runreq" : {
            "resx" : 320,
            "resy" : 240,
            "bitdepth" : 32,
            "opengl" : false,
            "network" : false,
            "gamepad" : true,
            "usef4" : true
        },
        
        "title" : {
            "en_US" : "App Title",
            "en_UK" : "Program Title"
        },
        
        "description" : {
            "en_US" : "A game where you drive trucks.",
            "en_UK" : "A game where you drive lorries."
        },
        
        "categories" : [
            "RPG",
            "FPS",
            "Puzzle"
        ]
    }
}

I find it's a lot easier to read than the XML I was using before, and until I get the editor up and running, this will make manually assembling the files easier.

You might notice the file makes no mention of icons or resource data. Those are automatically put into a folder tree by the packer, and icons are simply a file called "icon.png" placed in the root folder. Since the game file is basically just a ZIP containing resources and scripts, similar to an APK or JAR, they can be made by hand with relatively little trouble.