download alpha build 2007_12_7
After quite a bit of work, we've released our first build. Needless to say, the project is still far from complete. The current build shows a simple demo of our graphics plugin. It can render vector graphics quite similarly to Cairo or Flash. It can bevel lines of different thickness which is actually pretty difficult to acheive with DirectX alone
You can find out more about the engine at http://www.2dengine.com
Looking forward to all feedback, especially if the engine fails to run on your machine
[Edited by - dopeman on December 8, 2007 8:42:40 AM]
AGen, a new 2D game engine
Author
As the description of this board says, I'm basically here to plug a project that I've been involved with for a while. It's a 2D game engine that I'm working on along with my partner. I plan to post here periodically with updates about our latest progress.
AGen was built in C++ but runs Lua scripts directly from a source file. There's no need for a compiler as you'll be writing your games entirely in Lua. You don't have to know anything about DirectX, OpenGL or other graphic libraries.
2007.12.7
download alpha build 2007_12_7
After quite a bit of work, we've released our first build. Needless to say, the project is still far from complete. The current build shows a simple demo of our graphics plugin. It can render vector graphics quite similarly to Cairo or Flash. It can bevel lines of different thickness which is actually pretty difficult to acheive with DirectX alone
You can find out more about the engine at http://www.2dengine.com
Looking forward to all feedback, especially if the engine fails to run on your machine
[Edited by - dopeman on December 8, 2007 8:42:40 AM]
download alpha build 2007_12_7
After quite a bit of work, we've released our first build. Needless to say, the project is still far from complete. The current build shows a simple demo of our graphics plugin. It can render vector graphics quite similarly to Cairo or Flash. It can bevel lines of different thickness which is actually pretty difficult to acheive with DirectX alone
You can find out more about the engine at http://www.2dengine.com
Looking forward to all feedback, especially if the engine fails to run on your machine
[Edited by - dopeman on December 8, 2007 8:42:40 AM]
A few comments on the site: a screenshots and features page would be nice, with those titles - about sounds more general. The front of the site is artsy, but doesn't really show what your engine is about. Making the top image link back to the main page would be a convenient addition, too, and the diagonal lines make some of the text hard to read. I know, this is about your engine, but it's presentation is important too, right? :)
Now onto the real deal. The project sounds pretty interesting, especially the scripting part. If you can pull it off, it's probably going to be a nice little engine. I'd like to see an interactive demo, though - some real-time movement on screen. Currently it looks more like a static rendering engine. I'd also like to have some more information, such as which platforms will be supported, what licenses will be used, and so on. And once the engine gets into a more stable state, some examples that show how to get certain things up and running would certainly be nice. :)
All in all, I think it's a bit too early to tell which direction this is going to take, but it does look interesting. The engine ran fine on my system, bytheway (AMD 1800+, 384 MB RAM, GeForce FX5600, Win XP). Keep us informed! :)
Now onto the real deal. The project sounds pretty interesting, especially the scripting part. If you can pull it off, it's probably going to be a nice little engine. I'd like to see an interactive demo, though - some real-time movement on screen. Currently it looks more like a static rendering engine. I'd also like to have some more information, such as which platforms will be supported, what licenses will be used, and so on. And once the engine gets into a more stable state, some examples that show how to get certain things up and running would certainly be nice. :)
All in all, I think it's a bit too early to tell which direction this is going to take, but it does look interesting. The engine ran fine on my system, bytheway (AMD 1800+, 384 MB RAM, GeForce FX5600, Win XP). Keep us informed! :)
Author
Hey, Captain P, thanks for the comment.
I agree with what you're saying, the website should be better designed. I mean there are is no menus or anything. I really tried to put something out as soon as possible, just to get the word out. But yeah, I'll have to address the usability issues that you mentioned on the next update. The index page too, as you said is not very descriptive.
There are ways to animate the sprites right now, but it's not frame independent. Once we figure out the right interface for frame independent movement then we will put up another demo. Maybe you have some ideas? So far, we're thinking of either allowing the developer to manipulate a velocity vector or to have a "set_target" method for each sprite. Or possibly both.
We do have long-term plans for cross-platform development, specifically for the Mac. Each system component is a plugin so that the framework is seperate from the platform.
As for licensing, I can't really say much. I haven't spoken to my partner about it. :)
Take care
I agree with what you're saying, the website should be better designed. I mean there are is no menus or anything. I really tried to put something out as soon as possible, just to get the word out. But yeah, I'll have to address the usability issues that you mentioned on the next update. The index page too, as you said is not very descriptive.
There are ways to animate the sprites right now, but it's not frame independent. Once we figure out the right interface for frame independent movement then we will put up another demo. Maybe you have some ideas? So far, we're thinking of either allowing the developer to manipulate a velocity vector or to have a "set_target" method for each sprite. Or possibly both.
We do have long-term plans for cross-platform development, specifically for the Mac. Each system component is a plugin so that the framework is seperate from the platform.
As for licensing, I can't really say much. I haven't spoken to my partner about it. :)
Take care
Good point about frame-rate independency. It makes sense to let your engine handle all of that underwater. Simply modifying a velocity sounds like a good solution, as well as a set_target() function besides it - though this could also be implemented as a point_at() Point member function, because that's probably all it does. I think it's also a good idea to allow people to manually modify a sprites location when they need to.
As for the code, how did you envision a game working? I saw a main function in the example Lua script. I assume we can write an update function that will be called each frame, and input functions that are called whenever a key is pressed or released?
Oh, and are you planning to support image loading and such, or will this engine be strictly vector-based? In either case, it might be interesting to write something that can read data from popular vector art formats, since such art can be quite difficult to create with code alone. :)
As for the code, how did you envision a game working? I saw a main function in the example Lua script. I assume we can write an update function that will be called each frame, and input functions that are called whenever a key is pressed or released?
Oh, and are you planning to support image loading and such, or will this engine be strictly vector-based? In either case, it might be interesting to write something that can read data from popular vector art formats, since such art can be quite difficult to create with code alone. :)
Author
In my opinion, the developer shouldn't even know about 'delta' values between frame intervals. So far, we discovered that this has some pretty big implications. In the case of moving sprites around it means that editing a velocity vector wouldn't be enough. You also need an acceleration vector PLUS a "friction" property for each sprite. Yeah, I know, it's not a very elegant solution, but it's better than having to manually multiply (in Lua) each of your vectors by a 'delta' value.
How an entire game actually work is a very difficult question to answer at this point. :) We strongly believe that your program should be entirely event-driven. That is, you should almost never have to write a general "update function" which is called on every frame.
We have no choice but to add image support sooner or later, I mean 99% of all 2D games are texture-based. You're also right about having a vector format converter - a game engine is as good as its supporting tools/utilities... but for now all I can say is, the next demo will be interactive and will rock your socks off. ;) Well, it probably won't be THAT impressive but we've made a lot of progress. It should be out by tomorrow or the day after.
How an entire game actually work is a very difficult question to answer at this point. :) We strongly believe that your program should be entirely event-driven. That is, you should almost never have to write a general "update function" which is called on every frame.
We have no choice but to add image support sooner or later, I mean 99% of all 2D games are texture-based. You're also right about having a vector format converter - a game engine is as good as its supporting tools/utilities... but for now all I can say is, the next demo will be interactive and will rock your socks off. ;) Well, it probably won't be THAT impressive but we've made a lot of progress. It should be out by tomorrow or the day after.
It's an excellent idea to hide tedious and repetetive tasks, but it's also very easy to become overly restrictive. I like to use platforms and engines that do a lot of hard work for me, but sometimes they don't do exactly what I want, so I'd like to be able to work around them.
For example, not every game will need accelleration and friction - not every game will even need a velocity. And while events are perfectly usable, some games can handle certain things more efficient with a manually written update function. Hey, why not allow that function to be called whenever a NEW_CYCLE event occurs? :)
Anyway, I'm looking forward to the next demo. :)
For example, not every game will need accelleration and friction - not every game will even need a velocity. And while events are perfectly usable, some games can handle certain things more efficient with a manually written update function. Hey, why not allow that function to be called whenever a NEW_CYCLE event occurs? :)
Anyway, I'm looking forward to the next demo. :)
Author
Yep, if you say "game:on_update ( handle )" in Lua, the engine will call your handler function on every tick. But generally, you shouldn't NEED to do that.
As we start adding timers/triggers this should be even less necessary. The performance is also pretty bad for C to Lua calls (and vice versa). We've already looking for possible optimizations
Yeah you're right of course. The logical solution was to add two separate classes: sprites and vehicles. Vechicles are basically sprites that have acceleration, velocity, etc...
Download 2007_12_16.zip (421 Kb)
Anyways, behold - our new demo. :) Sorry, but I'm probably a little overexcited. We couldn't put in nearly as many things as we would have liked.
The most important changes in this demo include the addition of two new plugins: OpenGL and DirectInput
You can change the number of rotating triangles using PageUp/PageDown (by default they are only 100). The little red circle is a vehicle that can be controlled using the arrow keys. All of this is scripted and you can alter everything by changing the "Scripts/main.lua" file. I tried to comment as much as I can in the script file, so please check it out.
Also, it would be cool if you could post your FPS is at the maximum number of triangles. The max is 3000 I believe.
As we start adding timers/triggers this should be even less necessary. The performance is also pretty bad for C to Lua calls (and vice versa). We've already looking for possible optimizations
Quote:For example, not every game will need accelleration and friction - not every game will even need a velocity
Yeah you're right of course. The logical solution was to add two separate classes: sprites and vehicles. Vechicles are basically sprites that have acceleration, velocity, etc...
Download 2007_12_16.zip (421 Kb)
Anyways, behold - our new demo. :) Sorry, but I'm probably a little overexcited. We couldn't put in nearly as many things as we would have liked.
The most important changes in this demo include the addition of two new plugins: OpenGL and DirectInput
You can change the number of rotating triangles using PageUp/PageDown (by default they are only 100). The little red circle is a vehicle that can be controlled using the arrow keys. All of this is scripted and you can alter everything by changing the "Scripts/main.lua" file. I tried to comment as much as I can in the script file, so please check it out.
Also, it would be cool if you could post your FPS is at the maximum number of triangles. The max is 3000 I believe.
Ah, looks good. The performance varied from roughly 50 fps for 100 triangles to 13/14 fps for 3000.
I tried building a small evade-the-falling-blocks game, but noticed that the game silently fails when it encounters errors in the script. That makes things pretty hard to debug. Any solution for that?
I tried building a small evade-the-falling-blocks game, but noticed that the game silently fails when it encounters errors in the script. That makes things pretty hard to debug. Any solution for that?
Author
Hey, thanks, captainP
The Lua plugin for the engine is in release mode and doesn't have any typechecking at all. So it's quite easy to crash the entire engine if one of your arguments is the wrong type, for example. In the next few weeks, we'll probably be releasing a second, "debug" version of the plugin. The debug version will report errors/it will log memory and stack information/etc... but for now, there is no simple workaround.
I'm really curious about your script by the way. Do you ming posting the code on here? I'd love to look at it and plus I'll help you debug it ;)
The Lua plugin for the engine is in release mode and doesn't have any typechecking at all. So it's quite easy to crash the entire engine if one of your arguments is the wrong type, for example. In the next few weeks, we'll probably be releasing a second, "debug" version of the plugin. The debug version will report errors/it will log memory and stack information/etc... but for now, there is no simple workaround.
I'm really curious about your script by the way. Do you ming posting the code on here? I'd love to look at it and plus I'll help you debug it ;)
Sure, here's the code:
enemies = { }player = { }function main() createPlayer() game:on_keydown ( keyDown ) game:on_keyup ( keyUp ) game:on_mousedown ( mouseDown ) game:on_update ( update ) game:start ( ) endfunction update() -- Remove enemies that move outside the screen here -- Create an enemy every now and then if (math.random(0, 20) > 18) then createEnemy() endfunction createPlayer() player = new Vehicle() player.maxvelocity = 4 player.friction = 1 player.velocity.y = -3 player.position.x = 0 player.position.y = 220 player.canvas:clear() player.canvas:move_to(0, 0) player.canvas:circle(20) player.canvas:set_line_style(4, Color(255, 0, 0), 0.8) player.canvas:stroke() endfunction createEnemy() enemy = new Vehicle() enemy.maxvelocity = 3 enemy.friction = 1 enemy.velocity.y = -3 enemy.position.x = math.random(-320, 320) enemy.position.y = -240 enemy.canvas:clear() enemy.canvas:move_to(0, 0) enemy.canvas:circle(20) enemy.canvas:set_line_style(4, Color(255, 0, 0), 0.8) enemy.canvas:stroke() table.insert(enemies, enemy) endfunction keyDown(key) if key == AG_KEY_LEFT then player.velocity.x = player.velocity.x - 4 elseif key == AG_KEY_RIGHT then player.velocity.x = player.velocity.x + 4 elseif key == AG_KEY_ESCAPE then game:quit() end endfunction keyUp(key) if key == AG_KEY_LEFT then player.velocity.x = player.velocity.x + 4 elseif key == AG_KEY_RIGHT then player.velocity.x = player.velocity.x - 4 end endfunction mouseDown(button)endThis topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
