Derelict Online Project(WIP)

0 favourites
  • 7 posts
From the Asset Store
Derelict Hulks™ is a fun RPG tactical wargame inspired by Games Workshop's
  • http://c2.studioryu.net/?p=90&preview=t ... t=standard

    Hello every one. I'm starting up and opening a Devlog for my Derelict On-Line Project. DOL is a space online multi-player game similar to PSO in structure, but has a heavy board game and astrological theme design. I'm doing this to share with the community the development of large project, to get feedback as development occurs and the writing to help formalize ideas as they are implemented and or thought of at the time.

    My devlog is at my new wordpress website http://c2.studioryu.net/. It's a growing website so don't expect to find hours of content. I will also be putting some linkies in my sig.

    Derelict is a galaxy that is descending spiral of lost technology. As centuries go by a little more of the advanced technology that the greater empires created become harder to maintain and slowly become unusable. This has led to many taking up the the profession of Divers. Women and Men who go out into the worn torn stretches of space to scavenge useful commodities, supplies, artifices from derelict ships and stations.

    Players will have access to a series of staging areas where they can deal with equipment, shops, upgrades, character design, banking, ship purchase and design and spend leisure time in sci-fi space bars to gather together. While this is all the nice elements of hanging out the game is presented in the classic Point and Click adventure style view and interactive play. When the adventure game play begins the game will be a strong board game elements of room and event randomization, but still play in real time Point and Click adventure style.

    Now I am not an artist I am pretty bad at art. So a lot of prototyping and early visuals will be collected pictures from the internet. They won't be in there long they are place holders.

    This is the starting image. Total of 6 clients. No hard feat of course, but I want to start capturing the feel of what the game is aiming for. Some of you might recognize the Spriter character. That's because the game is going to use Spriter. new characters will come later.... much later <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">

    This is the image of the game on the tablet. It's an Acer A500 running with a Tegra2 220 model chip. This is the device that is currently hosting the prototype room.

    The catch to all of this is that this isn't the project at the top of my list. It is as of right now my ideal project, just not the one that occupies all my time. However I will be updating the devlog when I can along with the project. I will also be putting the game online with the first Master Host when I can. So everyone will be able to participate by trying the project as it develops.

    Here is that link http://c2.studioryu.net/?p=90&preview=true&preview_id=90&preview_nonce=d5cad28980&post_format=standard

  • Looks cool, will you be scaling the sprites and movement based on their depth/Y in the background?

  • Hey all. Progress is going forward. I will be working on Part 3 for my Devlog shortly. Although I'm currently debating on how to execute the first MasterHost. The idea of this host is to be a bot to maintain stability by just existing and providing a communal in/out for players. However since MP Plugin doesn't support multi connection I've been thinking of a way around that. Here are my thoughts and input would always be fantastic.

    Instance handler

    MasterHost with logistics to handle each area(a layout) as a form of internal sub room. This will require creating the same type of logic as the signalling room server.

    Pro: A MasterHost can be used to instance large number of players. Similar to how GW2 has zone instances. A MasterHost can be one world instance.

    Con: Extra work to create a sub room system and more custom messages.

    RoomHandler

    This form of MasterHost would require that a host connection would be required per layout or room. This offers the benifit of no additional coding for players going in and out of rooms. no need for extra messaging. however as a room handler each room would be it's own instance and as more players are playing this would bloat up the number of connections.

    Pro: Easier to develop, Ashley would be happier I don't bloat the rooms

    Con: annoying manager backend

    So after that it is safe to assume I will be tackling the multiroom master host rather than just do more prototyping. I will be putting up the first public results in the next few days for everyone to play.

    I was originally going to skip scaling. Primarily because I don't want players to be too small. Also because PathFinder is doesn't scale the speed vertically very well. However I change my mind the other day.

    1. I'm going to limit depth. Unlike some adventure games where you can get very small. Players will only depth down to 75% of the base size. So some depth will be provided for the illusion of depth, but not enough to spoil the graphical looks.

    2. I'm going probably not use PathFinder in the end, but create a regional node traversal. Pathfinder is nice, but I want more speed in path finding. I have a node pathing demo on my website. I'm going to use the principle, but make the nodes areas.

  • I'm hoping for a solution such as the one you've mentioned you are going to tackle the problem with.

    I hope you succeed man! The future of C2 multiplayer seems a little bleak if this can't be solved

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Rory

    I found a a working solution. I wrote Part3 and I managed to get a Single MasterHost that would manage each game area. As I started implementing the client side of the code I found the overheard of re-making what Scirra Plugin already did to get tiring. I also found that at each step to maintain the 1 room host and handle everything that's going be required was getting nuts.

    So instead I'm going back to the 1 connection per room. Which means running 1 host on my server computer per area/room. I'm thinking of using some other communication tool to cross communicate between rooms for shared information. I have an idea.

    Part 4 is in the writing now. However I think there is a bug regarding private messages between peers. :\ going to have to create stripped down test version and find out. Once I have cross room travelling working I will put up the demo.

  • Well an update. Part 4 is on the dev log. This post is an overview of of what I did for Part 4. The good news is that this is also the release that now lets players jump in. It's simple, bug filled, still using ripped art from the internet and the chat is missing. The next step will be to add local room chat and cross room chat along with the chat bubbles. FYI I have not done exterior testing, the dedicated server is running from my computer. So I have no idea at this time when my screen saver kicks in if the server will still be accessible.

    Part 4 Devlog: http://c2.studioryu.net/?p=127&preview=true

  • This is a small post. One of the major designs for DOL is run on mobiles. Including being playable on my A500(Tegra2) for now. I may not hold to this in the future. However one of the simple eye candy was a simple rotating background. For anyone who has tried the demo you will have seen this.

    Well this was achieved by a large sprite with the Rotation behaviour. And I am kinda surprised, but I shouldn't have been. Doing trig mathematics is expensive, doing trig every tick hurts performance. We can just ignore this on PC. However weaker devices are another matter. We need to avoid trig or use trig only at required intervals. Rotation uses a lot of trig.

    So here are the tests on performance. Control where nothing is rotated, Rotation Behaviour(1angle/sec), EveryTick and TimerBehaviour.

    Control(Nothing): 60FPS, 10%CPU

    Rotation: 30FPS, 45%CPU

    EveryTick(0.033): 60FPS, 22%-30%(25)

    Timer(0.033): 60FPS, 22%-30%(25)

    Rotation calculates everytick doing trig mathematics. It's too expensive. Best to avoid Rotation if you plan on hardware from -2012. Lesson. Don't use Rotation Behaviour for mobile. It's too expensive.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)