Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Tutorials
Articles
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Post History
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
IKA ENGINE - EDITOR
Posts
Pages:
1
Scalytank
462
Scalytank
View playlists
CloseHello everyone!
I don't know if this is the right place to post these kind of topics, but sorry if this is the wrong.
Why ika?
Its open source, so free, as this editor
Has hardware acceleration, thus blazing performace
Python scripting is considered more faster than rgss (and JIT compiler is present for it)
Me, and my girlfriend both develop our games in the ika engine. We found hard, to map on the default IkaMap editor, (and even in the new iked... it was incomplete... and i didnt have the time, to look into it...), so I decided to write a full featured new editor for our games, in ika itself. This editor is only half complete yet, but I Will definitely finish this.
In its current state of the editor, it supports:
- Unlimited sized maps
- Up to six layers*
- Autotiling
- 320x1920 tileset, with 40x40 tiles, and 8 autotiles per map, stored in Presets (like in rpg maker XP)
- Storing maps in predefined categories
- Pencil tool (capable of holding unlimited tiles, for drawing, like bigger trees), Rectangle tool, and Flood fill.
- Undo function, supporting up to 200 undo's
*(but the default, and the recommended is 3, for performance reasons.. however with todays hardware, i say, that 6 is possible. But then there are low budget laptops, and such... so...)
Future updates:
- A simple database, for editing obstructions, and tile data, and tile animations
- Full featured event editor, so no programming is needed for making games.(But the game scripts can be edited, if the developer knows to script in python)
- Map preview, zooming out, adding ambient colours, to preview how will that look ingame.
Planned features: (these will take place, after releasing the editor)
- A full featured database edit, for items, and enemies (equipment, combat, and statuses)
- the use of multiple Presets for one map
- Performance patches (currently the editor runs at 210 framerate on my 4 year old desktop pc, but i have ideas how to raise this further.)
Some screenshots from the current state of the editor:
Load map screen:
Map editor screen:
New map screen:
I don't know if this is the right place to post these kind of topics, but sorry if this is the wrong.
Why ika?
Its open source, so free, as this editor
Has hardware acceleration, thus blazing performace
Python scripting is considered more faster than rgss (and JIT compiler is present for it)
Me, and my girlfriend both develop our games in the ika engine. We found hard, to map on the default IkaMap editor, (and even in the new iked... it was incomplete... and i didnt have the time, to look into it...), so I decided to write a full featured new editor for our games, in ika itself. This editor is only half complete yet, but I Will definitely finish this.
In its current state of the editor, it supports:
- Unlimited sized maps
- Up to six layers*
- Autotiling
- 320x1920 tileset, with 40x40 tiles, and 8 autotiles per map, stored in Presets (like in rpg maker XP)
- Storing maps in predefined categories
- Pencil tool (capable of holding unlimited tiles, for drawing, like bigger trees), Rectangle tool, and Flood fill.
- Undo function, supporting up to 200 undo's
*(but the default, and the recommended is 3, for performance reasons.. however with todays hardware, i say, that 6 is possible. But then there are low budget laptops, and such... so...)
Future updates:
- A simple database, for editing obstructions, and tile data, and tile animations
- Full featured event editor, so no programming is needed for making games.(But the game scripts can be edited, if the developer knows to script in python)
- Map preview, zooming out, adding ambient colours, to preview how will that look ingame.
Planned features: (these will take place, after releasing the editor)
- A full featured database edit, for items, and enemies (equipment, combat, and statuses)
- the use of multiple Presets for one map
- Performance patches (currently the editor runs at 210 framerate on my 4 year old desktop pc, but i have ideas how to raise this further.)
Some screenshots from the current state of the editor:
Load map screen:
Map editor screen:
New map screen:
It's been a while since I've heard anything about ika, name's a bit nostalgic. Good luck developing this editor!
Scalytank
462
Yeah... a very underrated engine, because its not user friendly... at least it was not :D
Scalytank
462
author=Overload
I heard that ika was an unfinished engine. Maybe I heard wrong?
This is true, and false.
ika has an unfinished editor, map, and entity system, this is true. But ika also has script commands, for drawing images the way you want, playing sounds, music, and more. Pretty much everything a complete game engine needs.
I use a custom entity (events, objects, npc) system, and a custom map system, and this editor. So pretty much, with this editor, and a default scripts pack, ika will be a finished engine in a short time (and a really powerful one, regarding performance)
Ah, ika. The engine that stole oh so many Sphere users away over the years.
But not without good reason, either.
But not without good reason, either.
Scalytank
462
Just a bit update on this:
I currently work a lot on this editor. Today I finished the first step:
- A simple database, for editing obstructions, and tile data, and tile animations.
Its fully functional now, and can save, and edit unlimited presets.
I also added a new UI to edit categories. (maps will be stored in categories, like "Forest1" will hold all the maps associated with that place)
Currently i work on the event editor now. You can add two types of events here:
- Characters: Will hold several spritesets (like in rpg maker), but you can actually define how many positions that character will have (like attacking, and such), they can also run any event commands.
- Objects: Immobile objects, such as levers, chests, with unlimited frames for animations. These can also run any event commands, but cannot move, or turn around (but can animate in more than four frames).
I currently work a lot on this editor. Today I finished the first step:
- A simple database, for editing obstructions, and tile data, and tile animations.
Its fully functional now, and can save, and edit unlimited presets.
I also added a new UI to edit categories. (maps will be stored in categories, like "Forest1" will hold all the maps associated with that place)
Currently i work on the event editor now. You can add two types of events here:
- Characters: Will hold several spritesets (like in rpg maker), but you can actually define how many positions that character will have (like attacking, and such), they can also run any event commands.
- Objects: Immobile objects, such as levers, chests, with unlimited frames for animations. These can also run any event commands, but cannot move, or turn around (but can animate in more than four frames).
Scalytank
462
Sorry for the double post, i just wanted to bump up the thread, because the editor is
Close to be completed!
The event editor is completed, we just test it now, if it has any major bugs.
Im gonna submit the editor before Sunday. After that, I will implement a basic interpreter for the events in ika, and submit that too.
So ika will be finished soon ^^
Edit: We decided, to not release an interpreter for the event system, until we finish our projects. However, if someone wants to use the editor, or ika, should pm me, and i will supply him with a copy of this editor :)
Best regards!
Close to be completed!
The event editor is completed, we just test it now, if it has any major bugs.
Im gonna submit the editor before Sunday. After that, I will implement a basic interpreter for the events in ika, and submit that too.
So ika will be finished soon ^^
Edit: We decided, to not release an interpreter for the event system, until we finish our projects. However, if someone wants to use the editor, or ika, should pm me, and i will supply him with a copy of this editor :)
Best regards!
I think you should merge objects with characters. Reasons?
1. Sometimes you need to move/turn things like boulder, etc. and don't want to be limited by frames of animation, so movement of boulder will be fluid.
2. Some of characters, especially big ones, like dragons can really use more than four animation frames.
For storing spritesheet I'm thinking about following layout:
up
down
left
right
idleup
idledown
idleleft
idleright*
*plus maybe also diagonal ones
Every direction will be stored in separate row and will have unlimited amount of columns (a.k.a frames). Framesize would be calculated from image's dimensions. Idle* directions are made so character/object can play looped idle animation when he/she/it isn't moving.
To every png file with spritesheet there will be also additional file with same name, but .txt extension.
It'll have info about amount of frames in each direction, in same layout as png file, so following text file:
will inform that character/object has:
- 4 frames of normal movement in each direction (mind you, those numbers may differ).
- 6 frames of idle animation.
Of course space outbounds of character frames (like in above example with 2 additional, unused frames for normal movement (at far right)) will be ignored by engine and can be used e.g. to store artist's credits.
1. Sometimes you need to move/turn things like boulder, etc. and don't want to be limited by frames of animation, so movement of boulder will be fluid.
2. Some of characters, especially big ones, like dragons can really use more than four animation frames.
For storing spritesheet I'm thinking about following layout:
up
down
left
right
idleup
idledown
idleleft
idleright*
*plus maybe also diagonal ones
Every direction will be stored in separate row and will have unlimited amount of columns (a.k.a frames). Framesize would be calculated from image's dimensions. Idle* directions are made so character/object can play looped idle animation when he/she/it isn't moving.
To every png file with spritesheet there will be also additional file with same name, but .txt extension.
It'll have info about amount of frames in each direction, in same layout as png file, so following text file:
4
4
4
4
6
6
6
6
will inform that character/object has:
- 4 frames of normal movement in each direction (mind you, those numbers may differ).
- 6 frames of idle animation.
Of course space outbounds of character frames (like in above example with 2 additional, unused frames for normal movement (at far right)) will be ignored by engine and can be used e.g. to store artist's credits.
Scalytank
462
In fact, objects are designed to not be "heavy" on the engine. So, i will not merge them with characters, But, this is a really good idea.
Our games currently use 4 frame sprites, but the released editor will be redesigned, to use unlimited framed movement, And objects.
Objects are important, because, a chest, or a lever doesnt need to update its direction, speed, or check for jumping, or being moved. (this will cut down lag, when the user places too much events for like teleporting, those events dont need to move, or jump, :D)
Thank you for the feedback ^^ the "community version" Will use unlimited framed movement :)
Our games currently use 4 frame sprites, but the released editor will be redesigned, to use unlimited framed movement, And objects.
Objects are important, because, a chest, or a lever doesnt need to update its direction, speed, or check for jumping, or being moved. (this will cut down lag, when the user places too much events for like teleporting, those events dont need to move, or jump, :D)
Thank you for the feedback ^^ the "community version" Will use unlimited framed movement :)
Thanks ^-^.
Also about the layers, instead of limiting it to 6, maybe you could have up/down-styled editbox where you can use as many layer as you like? It would decrease clutter of interface too (obviously such editbox would be smaller than 6 buttons). And of course empty layers won't be rendered.
Also about the layers, instead of limiting it to 6, maybe you could have up/down-styled editbox where you can use as many layer as you like? It would decrease clutter of interface too (obviously such editbox would be smaller than 6 buttons). And of course empty layers won't be rendered.
Scalytank
462
Currently, only two layers are rendered ingame. Now this is an interesting subject.
There are tiles, marked as upper, and lower. We wanted to create something different, than the default ika editor.
So, when you map in the editor, and put a bush, on the second layer, or the sixth layer, that bush will either be rendered under the player or below the player, depending on preset settings.
So for example, you floodfill a 25*25 map with grass tiles on the first layer. Then, you put some bushes and flowers on the second layer, (both are below the player).
And then you put a tree on the third layer (the tree is defined to be above the player, except its trunk)
Ingame this will result in looping throught the map when loading, from layer 1-6, and either append the tile to the ingame below layer, or upper layer, depending on settings (Ingame layers actually are stored like a two dimensional array, containing multiple tiles, like "tiles{5}{5} = {}")
Then, the rendering engine loops throught the visible part of that layer, and render the tiles stored in that node.
This will result in completely ignoring any "blank" tiles in the layer. We tested this engine, and its really fast now.
Also, we can "buffer" the below layer to an image, on map loading (If we use grabimage, the loading time for a 20*15 map, are 0,02seconds with buffering)
So with a pretty complex map, this map rendering runs at 1050 framerate currently, if we turn on buffering. Without buffering its around 600. Speed was an important factor for me ^^
There are tiles, marked as upper, and lower. We wanted to create something different, than the default ika editor.
So, when you map in the editor, and put a bush, on the second layer, or the sixth layer, that bush will either be rendered under the player or below the player, depending on preset settings.
So for example, you floodfill a 25*25 map with grass tiles on the first layer. Then, you put some bushes and flowers on the second layer, (both are below the player).
And then you put a tree on the third layer (the tree is defined to be above the player, except its trunk)
Ingame this will result in looping throught the map when loading, from layer 1-6, and either append the tile to the ingame below layer, or upper layer, depending on settings (Ingame layers actually are stored like a two dimensional array, containing multiple tiles, like "tiles{5}{5} = {}")
Then, the rendering engine loops throught the visible part of that layer, and render the tiles stored in that node.
This will result in completely ignoring any "blank" tiles in the layer. We tested this engine, and its really fast now.
Also, we can "buffer" the below layer to an image, on map loading (If we use grabimage, the loading time for a 20*15 map, are 0,02seconds with buffering)
So with a pretty complex map, this map rendering runs at 1050 framerate currently, if we turn on buffering. Without buffering its around 600. Speed was an important factor for me ^^
Pages:
1
