curiosity

Thanks for sharing the video. What I'm the most impressed with is how authentic you've managed to keep the graphics to the original game's artwork. Not bad, but let's not hijack this topic.

Try this and report the result: Start rAthena Start Ragnarok in windowed mode and enter the game Open Resource Monitor (Win+R -> resmon.exe) Go to the "Memory" tab Find your client exe in the list Watch the numbers in the column "Hard Faults/sec" while playing a little bit Edit: Another thought: try going into your BIOS/UEFI settings and preallocate 512MB or so for the graphics card and see if this changes anything.

Looking great, @MaterialBlade. If the client starts getting unstable, keep in mind that clients made before the new Prontera update have a hard limit of 3000 vertices per RSM node. More than that and things go haywire pretty fast. Also RGBA sprites are really bad for the client in comparison to indexed sprites, although I don't think there are any memory leaks. Props for sticking with this. I wanted to make a little Paper Mario demo (I even built OBJ to RSM and spritesheet to SPR converters), but working with BrowEdit made me want to throw my computer out the window pretty fast.

Yeah, I noticed it would occasionally stop seemingly for no reason. Should be fixed now. Though I haven't fixed recovery in situations where it wants to kill something on-screen that it can't reach. E.g. a lone pupa on top of a cliff is currently very dangerous. There are also certain situations where the atrocious path finding of the Ragnarok client can't find calculate a path to enemies that not far away. If it works with some - but not all - 2015 clients then it may be because the sections (or simply the section names) weren't restored by whoever unpacked the client (i.e. removed the Themida protection).

I made a couple of bug fixes, updated the download. Worked for me. It worked with a 2015 client? I expected maybe late 2013 at most in it's current state

About [Only tested with 2012-04-10aRagExeRE - will likely currently be broken on new clients (though it won't hurt to try)] With this extension installed, players can use the new chat command /auto (alias /idle) to initiate a simple auto pilot mode. When activated, the message [AUTO MODE] will appear above the player's head, and the player will proceed to attack any visible enemy and otherwise roam around on the map. The mode is deactivated by typing the command again. One use case could be to make grinding less tiresome on low rate servers without allowing full bots. Please note that you can't access any GUI elements while /auto is active, except for typing in the chat window. In contrast with bots, this: Works through the client, rather than as a separate layer between the client and server Is limited in terms of functionality (e.g. no item farming) and can be further restricted by modifying the source code (e.g. if you want to exclude certain maps) Easy to use, and can be switched on and off through the chat window This release is the culmination of a few experiments modding the client. If you can program, you might want to consider using the source code as a base for other projects. One idea could be to use the code to easily swap packet headers as to make life harder for bots and similar tools. Installation Download the binary below and put rextensions.asi in your main Ragnarok folder. Files with the .asi extension will automatically be loaded by the client if sound is enabled. The DLL can also be added as a static dependency to the client by using a patcher such as NEMO. Download Source code Binary download

Looks like it loads the correct texture, but the composition is wrong as if it's using the wrong blend mode. Graphics card drivers will occasionally have issues with old versions of Direct3D. Try running the same client on another PC and see if you get different results. Or you could perhaps try changing settings in your graphics controls panel.

Guys, I'm still working on the project on my own phase. If you are desperate to get access right now and happen to be a reputable member around here, PM me your GitLab user. Note that you gain nothing from code access at this point unless you're comfortable with C++ development. It's not a ready client replacement for your server.

Looking good. Maybe we can get you some custom UI once my client is ready.

You can add a command handler like this: ACMD_FUNC(mypoints) { int points = pc_readaccountreg(sd, add_str("your-script-variable-here")); char buffer[32]; sprintf(buffer, "You have %d points.", points); clif_displaymessage(fd, buffer); return 0; }

Alright. Here are patches for main and Sakray service. Not that much interesting in them. I think kRO runs a pretty tight ship compared to other regions.

Anything specific? For kRO I have mid 2004 to end of 2008. Missing 2009, 2010 and first half of 2011.

Load times are probably only slightly better than the regular client, since it's the same approach. The ground mesh is built on the main thread and must be completed before the map is displayed, while model loading runs on a separate thread and finishes later. On mobile phones it takes a couple of seconds to load a map, and on my PC a typical map loads in under one second. I believe map loading is mostly bound by I/O. No problems with FPS so far and so I haven't bothered to measure it. As mentioned I have both Direct3D or OpenGL implementations to support the renderer. I believe OpenGL is the most performant one since I've made some adjustments to heavily batch render calls. Effects are for the most part identical to their originals effect. I can't quite copy-paste from the original client, but I can borrow the approach. Here's an example of how a simple effect is implemented: void CRagEffect::IncAgility(void) { matrix vtm; tlvertex3d vert; vector3d src; src = m_master->m_pos; vtm = g_modeMgr.GetGameMode()->m_view->m_viewMatrix; g_renderer->ProjectVertex(src, vtm, &vert); m_tlvertX = vert.x; m_tlvertY = vert.y; m_pos = m_master->m_pos; if (m_stateCnt == 0) { auto player = g_modeMgr.GetGameMode()->m_world->m_player; float z = m_pos.z - player->m_pos.z; float x = m_pos.x - player->m_pos.x; PlayWave("effect\\EF_IncAgility.wav", x, 0.0f, z, 250, 40, 1.0f); g_prim = LaunchEffectPrim(PP_2DTEXTURE, { 0, 0, 0 }); g_prim->m_duration = m_duration; g_prim->m_longitude = 0; g_prim->m_speed = 1.5f; g_prim->m_accel = g_prim->m_speed / g_prim->m_duration * -1.2f; g_prim->m_widthSize = 40.0f; g_prim->m_heightSize = 20.0f; g_prim->m_alpha = 0; g_prim->m_maxAlpha = 200.0f; g_prim->m_alphaSpeed = g_prim->m_maxAlpha * 0.06666667f; g_prim->m_fadeOutCnt = g_prim->m_duration - 15; g_prim->m_texture = new CTexture*[g_prim->m_totalTexture](); g_prim->m_texture[0] = g_texMgr.GetTexture("effect\\agi_up.bmp", false); } if ((m_stateCnt % 2) == 0) { g_prim = LaunchEffectPrim(PP_3DCROSSTEXTURE, { 0, 0, 0 }); g_prim->m_duration = 50; g_prim->m_matrix.MakeYRotation(GetRadian(rand() % 360)); g_prim->m_deltaPos2 = vector3d(0.0f, 0.0f, (float)(rand() % 7 + 2)) * g_prim->m_matrix; g_prim->m_matrix.MakeXRotation(GetRadian(90)); g_prim->m_speed = (rand() % 50 + 20) * 0.01f; g_prim->m_widthSize = (rand() % 60 + 30) * 0.1f; g_prim->m_heightSize = 0.18f; g_prim->m_alpha = 0; g_prim->m_maxAlpha = 200.0f; g_prim->m_alphaSpeed = g_prim->m_maxAlpha * 0.05f; g_prim->m_fadeOutCnt = g_prim->m_duration - 20; g_prim->m_texture = new CTexture*[g_prim->m_totalTexture](); g_prim->m_texture[0] = g_texMgr.GetTexture("effect\\ac_center2.tga", false); } }

It's very helpful that Athena developers have attempted to keep backwards compatibility with older clients -- all despite an increasing pile of spaghetti code as seen in functions such as clif_set_unit_idle. With rAthena you can ostensibly compile the server for any given version network protocol. Of course, as people move on to newer clients, the old clients aren't really tested anymore and many things can go wrong. The result is that rAthena supports a lot of strange packet versions that are something of a mix between old and new. But in the end, the only thing that matters is that the server and client understands each other. Luckily it didn't take too much effort to get my client working with the latest trunk revision. Renewal seems to work also, although I got resource crashed from some new monster called "little poring" or something?? Below: me battling it out @ glast with rAthena pre-RE

To settle the question of open source once and for all: I'm planning to release the full source code sometime in the future. When the code is released, anyone who wishes to do so will be free to fork the project, add renewal features, organize their own development teams and whatever. As I've already stated, I will not be interested in collaboration. I will release when I've reached my milestone for feature completion, and this will be the first and final release.

That is about right. All effects (CRagEffect) simply configure instances of effect primitives (CEffectPrim), with the only exception of effects based on the STR format (what Gravity calls the "EZ effects" ). Effect primitives are animated in code, and buffers for effect primitives are constructed on a per-frame basis. Making these effects is basically like working with a 3D canvas from the code, where everything is dumped in the renderer's queue. In many cases an effect primitive is something non-specific like a half sphere, where properties like radius and opacity is changed over time. There are also many primitives specific to individual skills. A skill can have multiple effects, which in turn can use multiple effect primitives and STR effects. For instance, Acolyte's Heal uses four different effects based on the amount healed. A rough description of how the skills you picked out are implemented: Magnum Break - Two expanding spheres and a 3D circle on the ground Cold/Fire Bolt - The bolts are just textures moving towards the target, combined with an expanding 3D circle on target Frost Diver/Grimtooth/Frost Nova - just multiple spikes growing in random directions, spawned one by one for the duration of the skill Safety Wall/Heal - 3D cylinder changing height with the texture fading out in the top, plus some floating particles here and there Cart Revolution - Combination of STR effect, an expanding 3D sphere and an expanding 3D circle Attack skills will often have one part for the skill itself, and one for when the target is hit. Damage effect is also varied, often based on the element of the attack. Most skills will additionally have a special effect on the player, like the glowing cylinder around the magician when a spell begins. There are lots of different ones. Skills using only a simple STR are relatively uncommon. By the way, looking forward to updates on your project.

That depends on what you mean by Renewal client. Ragnarok's Renewal upgrade was predominantly a change in game mechanics and an overhaul of the game content. This is for the most part independent of the client. My client could connect to a renewal-based server in its current state if I updated the networking protocol. The major differences between RagExe and RagExeRE were the introduction of the Lua interpreter and the overhaul of the user interface. I will be implementing neither of these, and probably nothing related to the 3rd classes. As for customization, that is done by changing build parameters before compiling. You can think of it as a config file like Athena uses. Client patchers provide a dead simple way to customize the client, but most people are unaware of the staggering amount of work that goes into making a tool like NEMO. These customization patches have made out of necessity, and with source code available that necessity is gone. Implementing skills is one of the biggest tasks in creating a client, simply because there are so many of them. Skills come in many different varieties, some requiring additional UI (e.g. warping, Graffiti), some need special character animations, some combine multiple effects, sounds, special damage and special hit effects. In addition to the player skills there are also many skills only used by monsters. At the moment I have about 14,000 lines of code just implementing the various visual effects, so it's easy to forget what's ready and what's not. Here's an overview of the current state of the 1st and 2-1 classes. ✓ means 100% done, ✗ means unimplemented or partially unimplemented. Most skills can be used just fine without implementing an effect, but for my 1st milestone I want to have at least 1-1, 2-1 and 2-2 skills fully implemented. Swordman ✓ Bash ✓ Endure ✓ Increase HP Recovery ✓ Magnum Break ✓ Provoke ✓ Sword Mastery ✓ Two-Handed Sword Mastery ✓ Berserk ✓ Fatal Blow ✓ HP Recovery While Moving Magician ✓ Cold Bolt ✓ Fire Ball ✓ Fire Bolt ✓ Fire Wall ✓ Frost Diver ✓ Increase SP Recovery ✓ Lightning Bolt ✓ Napalm Beat ✓ Safety Wall ✓ Sight ✓ Soul Strike ✓ Stone Curse ✓ Thunderstorm ✓ Energy Coat Archer ✓ Arrow Shower ✓ Double Strafe ✓ Improve Concentration ✓ Owl's Eye ✓ Vulture's Eye ✓ Arrow Crafting ✓ Repel Merchant ✓ Discount ✓ Enlarge Weight Limit ✓ Item Appraisal ✓ Mammonite ✓ Overcharge ✓ Pushcart ✗ Vending ✓ Cart Revolution ✓ Change Cart ✓ Crazy Uproar Thief ✓ Detoxify ✓ Double Attack ✓ Envenom ✓ Hiding ✓ Improve Dodge ✓ Steal ✓ Back Slide ✓ Find Stone ✓ Sand Attack ✓ Stone Fling Acolyte ✓ Angelus ✓ Aqua Benedicta ✗ Blessing ✓ Cure ✓ Decrease AGI ✓ Demon Bane ✓ Divine Protection ✓ Heal ✓ Increase AGI ✓ Pneuma ✓ Ruwach ✓ Signum Crusis ✗ Teleport ✗ Warp Portal ✓ Holy Light Knight ✓ Bowling Bash ✓ Brandish Spear ✓ Cavalier Mastery ✓ Counter Attack ✓ Peco Peco Ride ✓ Pierce ✓ Spear Boomerang ✓ Spear Mastery ✓ Spear Stab ✓ Twohand Quicken Wizard ✗ Earth Spike ✗ Fire Pillar ✓ Frost Nova ✗ Heaven's Drive ✗ Ice Wall ✓ Jupitel Thunder ✓ Lord of Vermillion ✓ Meteor Storm ✓ Quagmire ✗ Sense ✗ Sightrasher ✗ Storm Gust ✗ Water Ball Hunter ✓ Ankle Snare ✓ Beast Bane ✓ Blast Mine ✓ Blitz Beat ✓ Claymore Trap ✓ Detect ✓ Falconry Mastery ✗ Flasher ✓ Freezing Trap ✓ Land Mine ? Remove Trap ✓ Sandman ? Shockwave Trap ✓ Skid Trap ? Spring Trap ✓ Steel Crow ✗ Talkie Box Blacksmith (Note: Forging items not implemented!) ✓ Adrenaline Rush ✓ Hammer Fall ✓ Hilt Binding ✓ Power Maximize ✓ Power-Thrust ✓ Skin Tempering ✓ Weapon Perfection ✓ Enchantedstone Craft ✓ Iron Tempering ✓ Ore Discovery ✓ Oridecon Research ✓ Smith Axe ✓ Smith Dagger ✓ Smith Knucklebrace ✓ Smith Mace ✓ Smith Spear ✓ Smith Sword ✓ Smith Two-handed Sword ✓ Steel Tempering ✓ Weapon Repair ✓ Weaponry Reasearch Assassin ✓ Cloaking ✓ Enchant Poison ✓ Grimtooth ✓ Katar Mastery ✓ Righthand Mastery ✓ Lefthand Mastery ? Poison React ✗ Sonic Blow ✗ Venom Dust ? Venom Splasher Priest ✗ Aspersio ? B.S Sacramenti ✓ Gloria ✓ Impositio Manus ✓ Increase SP Recovery ✗ Kyrie Eleison ✓ Lex Aeterna ✗ Lex Divina ✓ Mace Mastery ✓ Magnificat ✗ Magnus Exorcismus ? Resurrection ✓ Safety Wall ✗ Sanctuary ✓ Slow Poison ✓ Status Recovery ✓ Suffragium ✗ Turn Undead Bonus pictures: Pet capture Rental cart Arrow crafting Cart select

To be perfectly blunt: no. You are not the first to ask, and I feel I should give an explanation as it must seem counterproductive to turn down willing contributors. There have been many client projects over the years, and if my only goal was to produce a working client I would have continued work on an existing project. Open Ragnarok comes to mind. Instead my primary aim has been recreating the game executable, as near as is possible from a binary. Given this particular constraint I believe there are few people who are capable of contributing, and many fewer still who would be interested in doing so. Lastly, I prefer doing my own thing, as I suspect most developers tend to do when it comes to their pet projects. Despite collaboration being pretty easy nowadays, I don't want to bother with it unless I can expect another major contributor.

Very well done. Have you done all the 3D modelling yourself?

You guys are very kind to offer donations, but it's not necessary. I have everything I need to work on this project. I like the shadows idea, may look into that... Yes, of course. Anything is possible, though I don't have any ideas for custom windows other than making a better quick slot for mobile devices.

Forgotten features While revisiting games I've played for years, one of the things I find the most exciting is discovering new features. By this I mean features that were planned at some point, but in the end never made it into the final product. When projects get to a certain size there will always be a few ideas that are rejected - some at a stage where you can still find remnants in the final product. In the case of Ragnarok we even had the lead designer leaving the company relatively early on. Despite the reason for this not being public, one of the reasons I've heard cited is that he didn't get the creative freedom he wanted. Who knows what might have been? In any event, what follows are a few features I've discovered that never made it into the final game. Highly immersive footwear As you're probably aware, the player characters change appearance based on the equipped items. The first layers are the body and head sprites, followed by up to three different accessories (upper, lower, mid). There's the left and right hand weapons, as well as the shield. Different sprites for different shoes were planned as well. In old versions of the network protocol you can even find shoe IDs in the player structures. This feature was most likely eventually left out because it would simply be too much work to animate the shoes for all the different classes. Even special weapon and shield sprites have been somewhat limited in use, and I believe these require significantly less work than it would take to create shoe sprites. Having players leaving footprints was also planned early on. From the looks of it this was originally meant to complement the different shoe types. I think when they scrapped shoe sprites idea they also forgot about the footprints. The effect is still present in the client, although I believe they intended to refine it a bit more. I guess it was eventually used for the Stalker class' Stealth skill. Here's what it would originally have looked like if enabled when normal players walk around: Destroyable maps? In Ragnarok the map is completely static, which is pretty boring. A partially implement feature would allow dynamic changes in the map elevation. It's uncertain how this would be used in practice, and therefore also why they chose to leave it out. Maybe they intended that the map could be destroyed by skills? E.g. have meteor storm leave a deep crater on the ground. That could be a pretty cool feature. Maybe I'll try implementing it myself someday. Model culling Another cool effect that was left out was having static models between the camera and the player disappear so that they don't hide the player. I'm not sure if the models were planned to be completely or just partially hidden. This feature was more or less complete, but the approach used is maybe to simple so that it doesn't always work as intended. I also discovered a bug in the calculation of the bounding box used especially for this purpose. You can actually try out this feature by using NEMO patcher, as I found a relatively simple approach to enabling it. Just enable "Restore model culling" when patching your client. Sky box This one is pretty self-explanatory if you've ever worked with 3D. Instead of having the background of the map be completely black (or blue like in Yuno), the client could instead show a picture of the sky or a landscape in the far distant. It's one of the simplest and most common effects used in video games to improve immersion, so it's a shame they never got around to finishing it. Weather There are some working weather related effects like snow and fog in-game, but a much more comprehensive system was planned at some point. This would include dynamic sun location and a true day/night cycle. One problem was probably that model shadows in Ragnarok are precomputed. A rain effect was implemented, but it was probably never finished as it looks pretty bad. The jRO team used to have some pictures related to this on their news page, and I believe they planned to release the new weather system with the Yuno update. Private server developers took matters into their own hands. If you played on an eAthena server around 2004 you may remember the horrible night effect that was enabled by default: Enabling the blind effect on all players until it was "morning" again! Everything 3D Considering the fact that licensing the RAD Game Tools SDK must have been pretty expensive, it's strange that Gravity never did more with Granny3D than implementing guild flags, the emperium and the castle guardians. (Not to mention Zombie Dragon!) Additionally as I mentioned in a previous post, Gravity already had their own RSX format which would have been sufficient if they only wanted a few simple 3D actors. The obvious explanation is that they wanted to do much more with it. Indeed, it appears that at one point they planned to introduce 3D customizable player characters. Perhaps this was a reaction to contemporary MMO titles, where full 3D quickly became the norm. The results of these experiments were never disclosed, so what it would have looked like is a mystery.

A few reasons: I'm not really interested in making a renewal client. I like the old ones better. There are debug files available for certain older clients. There weren't any major changes in the code base until the renewal clients, so it doesn't take much work to update an "old" working client to use content from newer clients. The difference between "old" and "new" is mostly additive. It's better to start with a smaller goal than a larger one.

Not that much to report, but I do a little work every now and then. I implemented some more UI like storage and added some more skill effects. I have played "single player" from Novice to second job a couple of times now without encountering any missing features or major bugs. I can usually implement skill effects for a class in pretty short order. Since last time I've finished a lot of skills for blacksmith and hunter. No plans at the moment, maybe in the future. Too much good information to be hidden away in a form post. I took the liberty to copy this over the wiki: A brief look at RagExe. Thanks, curiosity! Probably not too many people are interested in reading about things like that. Glad you liked it

Want to try Ragnarok for Android? There are a few bugs, and still some graphical issues with the OpenGL ES rendering, but it's possible to play already. Here's what you need to do: Have a somewhat recent Android phone or tablet. Supported architectures are armeabi-v7a and x86. Download the APK and install it on your device. You will need some game assets. If you have an old GRF around, maybe that will work. The client will look for data.grf and data2.grf. Both need to be present or it will crash on start. You can download this data pack that I'm currently using. Rename the BGM folder to lowercase. (I forgot to do this before uploading...) My client is based on the old Sakray clients and uses an outdated version of the client protocol. I'm not sure if rAthena can work with this packet version anymore. While I plan to add support for more recent emulators at some point, at present I suggest you should use this old version of eAthena for testing. After modifying clientinfo.xml to point to your login server, copy the data to your Android device. The client will request files from the "external" app data folder. Note that on most Android systems this seems to be the internal memory, though it can probably vary. On the devices I've tested, the path you should copy to is /sdcard/Android/data/com.ragnarok.ragexe/files. Just put the GRFs, music and data folder under there. At this point you should be able to play. The app doesn't shut down cleanly at present, so unfortunately you will have to force quit it from the app list if it crashes or you exit the app.

A brief look at RagExe Game Framework Class (GFC) is Gravity's own name for the game engine or application architecture used in Ragnarok Online. With the Ragnarok beta release in 2001, Gravity announced the finalization of GFC 2.0. But what exactly is GFC, and where did it come from? Most game developers use commercial proprietary engines for their games, while GFC is an in-house product by Gravity's RND-1 development division. In truth, it's misleading to call it a game engine, as GFC in its current form has been used in exactly one game and is tightly coupled to it. In all likelyhood the name GFC and the notion of a game engine are just buzzwords Gravity used in an attempt at impressing investors in their early days. However, my client is strictly based on Gravity's RagExe implementation, and I guess it can therefore be said to be a clone of GFC. Here's a brief look at its history. Gravity Corp. was a relatively small developer before Ragnarok Online became an international success. Certainly no one outside of South Korea knew of them. In fact, right up until Ragnarok become ready for alpha testing they were still just Team Gravity. In 1999 they partnered up with Sonnori Entertainment in a joint venture to develop an action RPG. Arcturus: The Curse and Loss of Divinity was released with success in 2000. At this point Gravity obtained the rights to publish a game based on the popular Korean comic Ragnarök. They decided to reuse source code from Arcturus. While Arcturus and Ragnarok don't have much in common in terms of game play, resemblances can be noticed in aspects such as artistic style and music. Making Arcturus into the Ragnarok we know today required a severe overhaul of the code base. However, in many architectural decisions were left intact. What was retained became the base of GFC. Ragnarok, like Arcturus, is a 2.5D game. While Gravity at one point experimented with 3D actors in Ragnarok, the main focus has always been on sprite-based characters in a 3D world. Most of the file formats from Arcturus could therefore be reused directly in Ragnarok. This is one of the reasons why some of Gravity's file formats have strange features. For instance the world resource format (RSW) contains strings pointing to scripts files, a feature not used in Ragnarok. Some formats, like RSX (think RSM for actors) were retained and is still in the code base, but never used. A few formats from Arcturus you may know include: SPR - indexed color bitmap format ACT - actor animation RSM - hierarchical 3D models with basic animation support GND - tile based ground mesh GAT - tile based property map RSW - map format (defines a scene with objects) They also made new formats, like the worthless IMF format that no one understand what is supposed to do... (Just kidding, IMF is used when combining ACT files for player characters, but it turns out it wasn't really necessary or useful. The client uses IMF offsets when drawing the player on the character select, which is probably why headgear sometimes looks a little wonky there. It also uses it for drawing order for player character sprites in-game.) While based on DirectX 7.0, from a modern perspective GFC can be said to be software rendered. If you've ever wondered why Ragnarok uses so much CPU, that is why! Direct3D is only used as a glorified triangle rasterizer with blending and depth buffering. GFC has a fairly large entity-based actor system where every actor is responsible for rendering themselves every frame. There are a few principal object types: ground (GND), models (e.g. RSM) and game objects (actors, effects, etc). Rendering done by registering a render pass from with the renderer - basically a list of screen projected vertices and a texture. The renderer sorts the render passes by depth, opacity and other attributes, and draws everything at the end of each game cycle. This all makes for a pretty horrible design. Easy to work with, but unnecessarily taxing on the system. The only reason it worked in the first place is the low amount of polygons on the screen. (Typically below 10,000 triangles at any time.) Game objects communicate by passing messages around to each other. In Ragnarok, there is also a global state (the session) and the current game mode, which is responsible for tasks like processing input, creating actors, handling network messages and signalling actors. The diagram above shows part of the base object hierarchy in Arcturus, which is pretty tall and convoluted. In Arcturus, each enemy needed its own class specialization. In comparison the diagram below shows the object hierarchy at the time of the Ragnarok alpha release. While simplified, the principal structure is the same. I have colored a few classes that provide similar functionality in the two games. CRenderObject is any type of object that is draw on the screen, while CGameActor is any object that can be interacted with. CPc is the object type for characters controlled by a player. CNpc covers static NPCs and monsters. In Arcturus you could interact with certain 3D models (e.g. doors, chests), so C3dActor was a part of the game object hierarchy. In Ragnarok, all 3D models are just decoration and not part of the game play and aren't considered game objects. (The exceptions to the rule are Granny actors and traps, the latter of which are actually RSM models drawn by a Skill object.) From the Ragnarok alpha to commercial release the renderer was improved a bit, and the 2D actor system become more flexible. A few libraries from RAD Game Tools was integrated to provide sound, video playback and a more practical 3D format (namely GR2, thought it's only been used for a few models). Aside from that, not much has changed.