next »

[GlyphGryph]

Eidolon. It's totally not pokemon! (More like Monster Rancher, really...)

This is a game I've been thinking about, reworking designs for, and hoping to someday build for something like a decade. And the time is right, so that's exactly what I'm going to do.



I started development a bit over a month ago, and I've actually been keeping a devlog since then, which I'm going to share here. My intent was to have a playable prototype so I could start playtesting the battle mechanics and have a base to work from for further development. I'm building this with online multiplayer and also a multiplayer focused mode planned from the getgo, and in fact I already have multiplayer functioning in the prototype. Which is why it's taken me twice as long as I'd hoped, but about as long as I expected. Don't expect too much from things visually yet - pretty much everything is placeholder, from the graphics to the code. (I probably won't want this to be a Ruby on Rails project for much longer, much as I love the language and framework)

You play as an orphan, and one lonely night you catch a glimpse of the spirits that flit between this world and another one. You encounter a man who makes you an offer you cannot refuse, who sees in you incredible potential (potential for what left unspecified, but it's something nefarious).

And so you find yourself in another world, built from echoes and remnants and fragments and memories of our own, populated by ghosts that are not quite people and the monstrous remnants of the worst and best parts of humanity given physical form and incredible power, with no one to help you except a monster of your very own, a weak and pitiful echo of your own desperation and shattered dreams.

You start alone and abandoned with little more than a desire to escape, but it won't end until you find a place you can truly belong and companions to share it with.

Once the prototype is done, I will continue to post development logs for as long as I continue development of the game. I'll also hopefully be pulling in a few other people for development, but... well, my experience relying on other people for major projects is that I can't, so I'm getting into this with the full expectation that I'll be doing everything myself. (except sound, thankfully I have someone I know I can count on for that because it's literally the only thing of which I am completely incapable).

I don't expect this to go quickly - my plans are ambitious, and I'm expecting at least a couple years worth of effort, maybe more. So there should be plenty of devlog to read!



And yes, it will be playable in your browser. (I also plan on building a downloadable client-side version of it for desktop and mobile, but we'll see how that goes)

I hope you guys enjoy the ride and, in the end, the result.

Playable prototype:
https://whispering-mountain-88337.herokuapp.com/

Features:
3 (almost) fully implemented species, each of which has 2 additional fully implemented subspecies!
1 kind of implemented species.
6 half-assed fragments
32 fully implemented moves (ones that are unimplemented will be marked as incomplete)
Experience gained you fight, and creatures that evolve and change based on what they've defeated
Multiplayer support! Challenge other players to fights and get your ass kicked.
NOTE: This shit is not optimized in the slightest, expect it to be slow. Everything is processed server side and I am on a free shitty server running really bad code that does way too many database calls!

UPDATES:
Week 1-3 (Start Date: August 1st, 2016)
Week 4.1
Week 4.2
Week 5.1
Week 5.2
Week 6
-Thread Starts Here-
Day 57, September 26th

[GlyphGryph]

Historical Dev Logs begin here
Things are taking roughly twice as long as I'd planned for, so I'm glad I doubled my estimate when I set the deadline for this thing.

That's just the multiplayer though, I think. It's a lot of work getting that infrastructure set up. I've currently got an action-cable based rails server running on the backend, with a javascript client app on the front end. I spent some time last week rebuilding a lot of how it worked since I'd been doing a full update and rebuilding of client state every time something changed on the backend, but that was quickly getting unwieldy. Now I send off queues full of events at regular intervals and let the client figure out the details of what to do with it.

Still, progress has been going pretty steady. I'm about three weeks into things, and I have the basic multiplayer and fighting mechanics working, so that's something. I'm hoping to have a functioning prototype that will let me start get genuine player feedback on the base mechanics by the end of the month - at which point I'll probably gut and replace most of what I've written so far and rebuild it in a less stupid way.

Here's a quick summary of the initial three weeks beyond being short on time and setting up my tech stack:

Got a basic "move around a map which is actually just an html table" setup going, and used it as my test base for the websocket-based multiplayer architecture. If I want to do multiplayer, though, I've got to have it in the plan from the get go, and even if basic level of stuff took like half my current dev time.

I've also begun searching for artists and other programmers, and that's... going. I have an artist interested, but we'll see how they handle a creative lead position - I get the feeling they'd be happier doing a bit of concept art and asset generation, but it's not exactly a pressing matter at the moment. I'll be doing a lot more of this once I'm done with the prototype.

What's more important is that I spent some time Playtesting last weekend!

Of course, I don't actually have any playtestable code yet, but that's not going to stop me!

I implemented the entire battle system in a series of index cards. Despite the complexity of the actual fights, there really aren't that many moving parts or things to keep track of. The playtest went well - people were swapping out abilities, looking for broken combos, and then finding hard counters to them. It was actually the most fun I've ever had seeing people play a card game I've built, and I've built quite a few, so uh, I'm not sure if that says something bad about my ability to make fun card games or something good about the conceptual mechanics? Probably both. I also included progression mechanics - every time you defeated a monster, you had the option of leveling up and taking on that monster as a sub-type, and the team sizes increased over time. It helped my get a really good feel for how the battle system is going to have to work, and was immensely valuable.

Here's some blurry photos of the results! Individual monsters sheets and the associated move lists they could pull from.



Jackhammeril and Penis Fly Trap proved a pretty effective matchup for Biggun and Cloud at first, but a Cunning-based lockdown build of Cloud eventually shut down the Rage-reliant strategies the first team was using, allowing Biggun to make short work of the both of them.

I think the actual figurines we used (from the Reaper Miniatures kickstarter mega sized box set a while back) made things even more fun,. Hopefully my actual monster designs will be able to hold a candle to theirs.

[GlyphGryph]

Since the "golden path" (killing the other guy with direct attacks) part of battles are working, I'm currently coding in all the different abilities and status effects I've designed.

I am probably not doing this the best way I could! That's alright though, I fully expect that almost 100% of what I write for this prototype will eventually be replaced.

I've got a "Move" class that has a few basic methods for executing actions and communicates a lot with battles and spirits, and inside it is...

an enormous associative array (or Hash, in Ruby) of OpenStructs (generic objects built-to-purpose without a meaningful associated class) that looks like this:

Code:

{ 
  move_id: OpenStruct.new(
    name: 'Move Name',
    description: 'Move Description is here',
    time_unit_cost: 2,
    types: [:attack, :special, :debuff], 
    damage: 5, # This attribute only exists if the move is an attack type
    special: lambda do  |battle, owner, enemy|
      # Something special goes here, this is called if the move is a special type
   end
  ),
  move_id: OpenStruct.new(
    name: 'Move Name',
    description: 'Move Description is here',
    time_unit_cost: 2,
    types: [:hidden, :trap, :temporary], 
    expired?: lambda do  |battle, owner, enemy, token|
      # Returns true or false based on whether certain conditions are met, 
      # usually the owner taking another action
    end,
    expired: lambda do |battle, owner, enemy, token|
      # Actually run if expired? is true
    end,
    triggered?: lambda do |battle, owner, enemy, token|
      # Like expired, but watches for different conditions, specifically for enemy actions
    end,
    triggered: lambda do  |battle, owner, enemy, token|
       # Handles what actually happenes when triggered
   end
  ),
)
...
}

types is an array of symbols used as flags for which bits of logic should be hit when this code is executed, and which triggers should be checked. Some traps, for example, only respond to enemy attacks, not to other types of moves - the types array is how that's determined.

Attacks use the associated damage value to deal a chunk of damage directly without any complicated logic
Specials use their associated special functions immediately upon use (right after running the attack code, if they are also an attack)
Hidden moves always display as "Blah prepares a hidden technique" or something equally vague
Temporary moves expire when their expired? method returns true, and also add a special 'token' to the spirit using them with a record of the turn it was created
Trap moves expire when their triggered? method returns true, and also add a special 'token' to the spirit using them with a record of the turn it was created

time unit cost, description, name, and types are the only attributes shared by every possible action. Pretty much everything else is expected conditionally based on those types. I plan on adding a validator tomorrow night for when this thing first boots up that throws an error if I've added a type to a move but haven't provided the needed components to run it as that type (or if I've provided components that won't be needed by the listed types), instead of finding out I fucked up the data entry in the middle of doing something else.

various lambdas are called as needed. Lambdas are pretty great. I have to constantly fight the urge to build entire projects out of openstructs and lambdas. I'm not entirely sure what this says about me - maybe I've been spending too much time writing javascript. There's actually quite a bit of battle logic that wraps around these, doing things like setting up the persistence tokens and removing abilities from tracking when appropriate. Most of what these lambdas do is call various battle methods with various parameters, and check state - they don't directly manipulate anything.

Ah OpenStructs. These things are actually pretty cool in Ruby. I love them. You can customize them with your argument hash, but if you have chunks of shared functionality you can still include modules and stuff pretty easily! Very nice to use for things you expect to change a lot in the near future or whose design you haven't nailed down quite yet.

Like I said, probably not the best data structure! But it works fine for now, and I'm glad to have gotten that far. Traps and Temporaries aren't triggering/expiring correctly yet, but should be soon, and then it's largely a bunch of data entry of the remaining behaviours.

[GlyphGryph]

So, not much to write about on the technical front - I've been completely overhauling the battle system, which was mostly placeholder logic before - laying the groundwork for PvP and for teams with more than one spirit per side. Users have characters, characters have teams, teams have spirits (at specific positions). The bulk of the broadcast logic has been rewritten to be easier to handle and and change and to support multiple players.

I have been working on some more monster designs though, specifically the creatures the player will encounter in the two areas I'll be building for the second stage milestone (although I won't be starting work on that until next month)

Nellaf

Hovers far above it's chosen prey, observing and waiting for an opportunity. Sees itself as superior to all others, but especially impure Eidolons. It seems harmless at first glance... but it has a burning heart that will scorch those who get too close, reducing them to a cinder.

Has a special ability that deals damage to both itself and it's enemies based on the number of buffs/debuffs and subtypes.

Heglugrub

A ravenous creature that grows the more it eats, and eats the more it grows. It lives to consume, and will just as happily devour mortals as it does spirits. If you get in between a Heglugrub and it's meal, you will quickly find yourself an appetizer.

Has a special ability that let's it gain a big increase in power each time it kills an enemy, for the duration of that battle and a limited time afterwards.


These are Figments - three "Fear" figments on top, and three "Faith" figments on bottom. Figments are weaker than Eidolons and can't be captured, but can still be fought and devoured to gain strength and type affinity. As you grow more powerful, figments will actively seek to avoid you, so you won't be fighting them unless you're seeking them out. In the early game they make up the bulk of the enemies you'll fight, while actual Eidolon's will be more rare.

[GlyphGryph]

So, after spending a night and a half working on a proper nested menu system for Eidolon moveset customization when I realized I absolutely do not need one for this prototype, at least for this, and since all this code is probably going in the dustbin sooner or later even if I keep working on this game, it was a huge waste of time.

So tonight I ignored the menus, built an exclusively click-based placeholder, and focused on functionality... and what do you know! I'm done in a matter of hours.



You can now equip and unequip the moves you want an Eidolon to know in battle. Eventually the number of these you'll be able to equip will be influenced by the specific Eidolon you're managing, but there's no real differentation between them yet - that's up next after I finish the battle system.

Lost a lot of progress potential this week due to life concerns and other obligations, and what time I did spend programming was largely spent lost in the weeds of websocket logic, specifically related to the order events were being sent out in, what events were being remembered, states being updated in some places but not others... I finally decided I was too confused by what I had built and drew out a bunch of diagrams of all the connections and sequences, and then pruned the whole thing down to a smaller, much more sensible series of interactions.

That took some time to implement, but it's almost done now, and when it's done multiplayer will be working, and all the actual transition logic will be complete. It will be nice to put it behind me.

After that, I plan on working on Eidolon customization - right now, all the Eidolons are ad hoc generic creatures. I originally wanted one test Eidolon for each of the six primary types for the prototype, complete with stat progressions and move lists. I need to implement them in such a way that they can be sub-typed as well, and I need to include the ability for them to grow and improve as a result of battles.

With the time remaining, that's a bit too ambitious, so I'm going to reduce the scope to three primary Eidolons (which means each will have two sub-types). This means I can safely skip a huge chunk of the other bit of remaining work, finishing the move implementations - at least for this milestone.

[GlyphGryph]

Finished rebuilding the battle system for the... third time? Also added in the customization stuff.



Got multi-member teams and swapping out (both manual and auto on death) working correctly. Also I think this is the first time I've shown the visual status effect indicator, although that's been in for a while.



Added figment type enemies, which are smaller and weaker.
Defeating enemies now grants experience to the Eidolon that landed the killing blow.
Gaining enough experience allows you to learn new moves.
You can also capture enemies, adding them to your team (up to a max of three guys on your team)


Progress on subtypes is going well, but it's only about half done. It's correctly grabbing subtypes, but it's not yet grabbing the correct subtype, and I haven't even started implementing the logic for learning moves from subtypes which is the point of the whole thing. Good progress was made, though - should be done with this tomorrow night logic-wise (not data wise).

[GlyphGryph]

Things I've got done that you can see:
Sub-selection targeting: Selecting certain moves will open submenus of possible targets. You can see that below for the "swap" command, where being able to choose who you want to switch to is pretty important! But it's also needed for a lot of the actual Eidolon moves as well.
Fleeing: This one was pretty simple, but it works.
Dismissing Captured Eidolons: Pretty easy, destroy and cleanup.
Moving Eidolon positions: This one took longer than expected - had to remove some of my data validations, and do some cleanup afterwards to avoid bugs.
Limiting when moves display: Passive moves only display outside of battle, Capture and Swap will only display when the move can actually be used, and the infrastructure is in place to easily do other moves the same way.
Implemented the "..." thing in battle when waiting on a response from the server. Makes it feel a lot snappier when you select options now and get that instant feedback even if the server is being lazy.



Things I've got done that you can't:
Moved all the definitions for moves you and your spirits can make out into data files to make them easier to work with. Although this data files are still also scripts - need those juicy lambdas. Also wrap them up in actual proper objects now instead of temporary OpenStructs, which means no more "calls" in my my main code area to access those lambdas and much simpler argument handling outside of the definition files.
Did a major overhaul of menu handling - it's now got it's own dedicated controller script, and I can pretty trivially add menus in wherever I want and have them function properly now. That will be nice for later improvements. The logic isn't tied to the display except insofar as activating the "selection arrow" when and where appropriate, that's still built in a handlebars file, which is a good thing since it should work fine for the visually distinct nested worldmap menus as well despite them looking very different. Always important not to leave more work for yourself in the future if you know where you're going.
Added full learnsets: This will probably be tweaked during playtesting, but right now all Eidolons learn their moves at the "right" time, and only start with their actual starting moves. Just basic data entry, really, but it's done!

Historical Dev log ends here

[GlyphGryph]

Spent more work on PvP - you can now invite other players to battle.



As you can see towards the end there, there is some bug that sometimes causes problems I need to figure out. I also need to disable the challenge button after a challenge is sent to prevent those invites from stacking up, although that's also partly due to my capture program.

Also implemented the "Shroud" ability, which conceals a lot of information. It involved changing the way I push display update events, but that's probably for the best, the new way is actually better.

[GlyphGryph]

Here it is!

An actual, playable prototype!
https://whispering-mountain-88337.herokuapp.com/

Features:
3 (almost) fully implemented species, each of which has 2 additional fully implemented subspecies!
1 kind of implemented species.
6 half-assed fragments
32 fully implemented moves (ones that are unimplemented will be marked as incomplete)
Experience gained you fight, and creatures that evolve and change based on what they've defeated
Multiplayer support! Challenge other players to fights and get your ass kicked.
NOTE: This shit is not optimized in the slightest, expect it to be slow. Everything is processed server side and I am on a free shitty server running really bad code that does way too many database calls!

Gonna be updating it pretty regularly the next few days.

[Connor]

okay, looks good; problems with the name.

eidolonS is a game on tigsource from another dude thats about a year old, so id suggest you maybe rename this. EDIT: the games a year old, the dudes like, what, 30? lmao

still, seems fun, not many pokemon style games on tigs right now.

[GlyphGryph]

okay, looks good; problems with the name.

eidolonS is a game on tigsource from another dude thats about a year old, so id suggest you maybe rename this. EDIT: the games a year old, the dudes like, what, 30? lmao

Looked it up. Ironically enough, it's a completely different meaning. I think it's fine for now, it's a working name, but thanks for pointing out that I will definitely need to change it before release. Damn.