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
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
Profile
Locker
Play ListsSDHAWK'S PROFILE
SDHawk
2362
CloseSearch
Filter
All
Game Pages
User Statuses
Schatz-Jäger
It was cancelled in like 2004 or so. Basically it started as a test to see if I could write an action RPG system for another game that I'd be doing later and then branched out into its own crazy thing and died for who knows what reason.
Summer Screenshot Spectacular!
Release Something! Day VII: Advent Children [Releases]
http://www.youtube.com/watch?v=ZeKIUk22wiI
With the king gone mad it's up to Marcus to find an alternate water supply. Includes innovative real time battle system, partially random maps, and hydration system where you have to conserve your skill usage to make it out of the desert alive.
Hydration 2: Oasis
http://www.rpgmaker.net/games/1223/downloads/
Size: 6mbs
Engine: ika
by Gizmog1 & SDHawk
Summer Screenshot Spectacular!
Screenshot Superbowl Sunday
Screenshot Superbowl Sunday
ikaDB Preview
We've been working on this for awhile so I'm pretty excited to start showing it off. Basically, it's a tool for automatically generating a user friendly GUI for manipulating an ika game's data. After reading it I'd like for you to consider the following questions if possible:
-Is the presented interface adequate compared to the tools you're currently working with?
-Bearing in mind that you'd still have to program all the core functionality of your game, does a tool like this make the intimidation of such a task any less? In other words, does this tool make you consider trying out ika to be more appealing?
-If you're already used to programming most of your games, does a tool like this appeal to you and make you consider switching to ika for it? (Remember that the GUI generated is based on your own code so it's very flexible)
Of course the ultimate goal of this is to eventually make it possible to make an ika game with very minimal programming, but that's a long ways off requiring many more tools and a game library. Still, we're curious as to whether this makes ika any more appealing to you in the present. Thanks for the responses!
Here's some basic code for a hypothetical game database concerning items and a basic enemy.
Let's take a look at it from the editor.
The editor categorizes data by whether it's a parent data model or not- whether it descends from any other data models or not. From these it builds a tree view of all the instances of data. Above is where you select which parent model to work with.
Here are all the operations you can do on the tree- adding or removing data model instances, moving them around, and categories. Categories are basically non-data that's solely for in-editor categorization (though games can access them if desired)
Here we have a simple database filled in by me so you can get a feel for how categories work. As you can imagine, these would become quite useful in a larger database. We also see how the DB generates the UI in fairly obvious ways from the example code. All fields from the parent are inherited by the child so you can have a basic item class just for displaying its name/text and then create more detailed models for when it comes time to actually use the item, rather than having one giant data model for every type of item.
Here we have the Monster model. The important part here is the MultiForeign field that essentially allows you to store instances of other DB items. It has two main modes- new and set. New mode lets you create a brand new model instance then and there. Set allows you pick an existing one in the database. The two can be mixed if desired. Here we're about to see the new mode in action:
As you can see, it simply generates a panel identical to the others for inputting the new object's data. The drop-down box is so you can choose from multiple model types to create if desired. Next let's see how the set foreign field mode works.
As you can see it's much like the main tree view, except you can't edit objects. You simply double click to select the desired item. One last look at how it ends up inside the monster model instance:
That's pretty much how it works, I hope you like it. While it's functionally finished it's far from completely stable or polished, something I hope to correct while I work on my game and WIP works on integrating with his own. The release will be delayed until I'm comfortable with its stability. The other factor is that it's so tied with the new iked functionality that I'd like for ikedv2 itself to be further along before release as well.
-Is the presented interface adequate compared to the tools you're currently working with?
-Bearing in mind that you'd still have to program all the core functionality of your game, does a tool like this make the intimidation of such a task any less? In other words, does this tool make you consider trying out ika to be more appealing?
-If you're already used to programming most of your games, does a tool like this appeal to you and make you consider switching to ika for it? (Remember that the GUI generated is based on your own code so it's very flexible)
Of course the ultimate goal of this is to eventually make it possible to make an ika game with very minimal programming, but that's a long ways off requiring many more tools and a game library. Still, we're curious as to whether this makes ika any more appealing to you in the present. Thanks for the responses!
Here's some basic code for a hypothetical game database concerning items and a basic enemy.
Let's take a look at it from the editor.
The editor categorizes data by whether it's a parent data model or not- whether it descends from any other data models or not. From these it builds a tree view of all the instances of data. Above is where you select which parent model to work with.
Here are all the operations you can do on the tree- adding or removing data model instances, moving them around, and categories. Categories are basically non-data that's solely for in-editor categorization (though games can access them if desired)
Here we have a simple database filled in by me so you can get a feel for how categories work. As you can imagine, these would become quite useful in a larger database. We also see how the DB generates the UI in fairly obvious ways from the example code. All fields from the parent are inherited by the child so you can have a basic item class just for displaying its name/text and then create more detailed models for when it comes time to actually use the item, rather than having one giant data model for every type of item.
Here we have the Monster model. The important part here is the MultiForeign field that essentially allows you to store instances of other DB items. It has two main modes- new and set. New mode lets you create a brand new model instance then and there. Set allows you pick an existing one in the database. The two can be mixed if desired. Here we're about to see the new mode in action:
As you can see, it simply generates a panel identical to the others for inputting the new object's data. The drop-down box is so you can choose from multiple model types to create if desired. Next let's see how the set foreign field mode works.
As you can see it's much like the main tree view, except you can't edit objects. You simply double click to select the desired item. One last look at how it ends up inside the monster model instance:
That's pretty much how it works, I hope you like it. While it's functionally finished it's far from completely stable or polished, something I hope to correct while I work on my game and WIP works on integrating with his own. The release will be delayed until I'm comfortable with its stability. The other factor is that it's so tied with the new iked functionality that I'd like for ikedv2 itself to be further along before release as well.
ika: Animations/frames
To be more specific about writing an animation system, you'll basically want a sprite object. Said object should have an array of images for each frame (ideally, you'd load a single image file and splice it down to each frame using surfaces but you can use single image files for each frame for testing purposes). You'd then want a Draw function in the sprite object that calls something like:
self.MyImages.Draw(self.x, self.y)
Where self.Frame is a number representing which frame is currently being drawn.
Next you'd want an Update function that increments the frame number with a slight delay. You'd also want it to decide which frame number it starts incrementing from based on the direction it's facing, so have a Direction property as well. You'd probably want a dictionary of lists containing the frame list for each direction. ie,
MyFrames = { 'left': , 'right': }
then turn your drawing function into:
self.MyImages[ self.MyFrames ].Draw( self.x, self.y)
Presto, you have animation!
See the 3 part tutorial on the ika website for how to create a basic Sprite object and get it drawn/updated.
Alternatley you could use the built-in sprite system ika has, try finding the rho software (PROBABLY included with ika) to import stuff. It's a beta and somewhat broken but workable.
self.MyImages.Draw(self.x, self.y)
Where self.Frame is a number representing which frame is currently being drawn.
Next you'd want an Update function that increments the frame number with a slight delay. You'd also want it to decide which frame number it starts incrementing from based on the direction it's facing, so have a Direction property as well. You'd probably want a dictionary of lists containing the frame list for each direction. ie,
MyFrames = { 'left': , 'right': }
then turn your drawing function into:
self.MyImages[ self.MyFrames ].Draw( self.x, self.y)
Presto, you have animation!
See the 3 part tutorial on the ika website for how to create a basic Sprite object and get it drawn/updated.
Alternatley you could use the built-in sprite system ika has, try finding the rho software (PROBABLY included with ika) to import stuff. It's a beta and somewhat broken but workable.
Getting started with Verge
While it's true that Verge has better introduction documentation (ika is about on par for API reference and language tutorials since it uses Python which has a plethora), it's not all sunshine and roses. Mostly in its language.
VergeC is essentially a Verge-specific scripting language that has all the ease of use of C (not much) with all the speed of being slower than just about any standard scripting language (ie, Python, JavaScript, Ruby).
While it has made a lot of improvements over the years it still has a lot of wonkiness to it and, worst of all, is procedural. This makes it far worse for writing/using libraries, team programming, long-term code maintenance, and general readability. While you can make a lot of arguments for procedural vs. object-oriented they're pretty much all rendered null when the procedural is slower than the OO and when the point of the engine is to speed up and ease game creation- object oriented is just plain easier to wrap your head around, especially as a new programmer. VergeC also has concepts such as types which make it even worse for new programmers along with missing easier ways to work with loops and the like.
Because it's a custom language you also miss out on any third party libraries for extending the language for things not provided by the engine. Furthermore, a language like Python allows importing C/C++ libraries if you need custom routines to run faster. This would be impossible in Verge without adding the functionality to the engine itself.
Recently Verge has added Lua which helps quite a bit in some of these areas but support is still flaky since only a hand full of people use it (read: it has little documentation and potential for problems using it). Plus, it's still procedural and has all the problems that go with it.
I could probably make some arguments regarding ika's API, hardware rendering, etc, but it really does pretty much just boil down to the language difference. It's not necessarily just because one has language x or y, but by having x or y the entire engine's design becomes affected by it. And it really is that big of an advantage, you can make games more maintanable, faster (in running AND actually writing them), and learn the language quicker with ika than Verge.
Considering you spend 98% of your time programming in either engine, the language really does make a huge difference. Jump ika's unfortunate gap in introduction documentation and you'll be far better off in the end.
VergeC is essentially a Verge-specific scripting language that has all the ease of use of C (not much) with all the speed of being slower than just about any standard scripting language (ie, Python, JavaScript, Ruby).
While it has made a lot of improvements over the years it still has a lot of wonkiness to it and, worst of all, is procedural. This makes it far worse for writing/using libraries, team programming, long-term code maintenance, and general readability. While you can make a lot of arguments for procedural vs. object-oriented they're pretty much all rendered null when the procedural is slower than the OO and when the point of the engine is to speed up and ease game creation- object oriented is just plain easier to wrap your head around, especially as a new programmer. VergeC also has concepts such as types which make it even worse for new programmers along with missing easier ways to work with loops and the like.
Because it's a custom language you also miss out on any third party libraries for extending the language for things not provided by the engine. Furthermore, a language like Python allows importing C/C++ libraries if you need custom routines to run faster. This would be impossible in Verge without adding the functionality to the engine itself.
Recently Verge has added Lua which helps quite a bit in some of these areas but support is still flaky since only a hand full of people use it (read: it has little documentation and potential for problems using it). Plus, it's still procedural and has all the problems that go with it.
I could probably make some arguments regarding ika's API, hardware rendering, etc, but it really does pretty much just boil down to the language difference. It's not necessarily just because one has language x or y, but by having x or y the entire engine's design becomes affected by it. And it really is that big of an advantage, you can make games more maintanable, faster (in running AND actually writing them), and learn the language quicker with ika than Verge.
Considering you spend 98% of your time programming in either engine, the language really does make a huge difference. Jump ika's unfortunate gap in introduction documentation and you'll be far better off in the end.
Lexico Review
Games - Tester
Games - Other
