• Advertisement
  • entries
    503
  • comments
    1888
  • views
    334589

About this blog

Mostly technical ramblings through the years of indie game development

Entries in this blog

In part 1, I wrote about a difficulty endemic to just about any porting project,
the importing and trans-coding of data to different formats.

Here in part 2 I'll cover a few of the trickier engine architectural differences that exist between 
the original engine for Static:IT (Selenite) and the new engine that will support it (base-code from 96Mill and Revel Immortal)

 

Different Origins

Originally designed to support editor-only development of Adventure and RPG games,  Selenite
was a successor of the S3Engine (The Lost City of Malathedra); and shared many simularities
with the primary exception being that S3 was designed such that scripts and associated resources
were to be written in external tools, and the S3Engine was a pre-compiled exe run-time, that read and 
executed the scripts and resources.

Selenite on the other hand, was an IDE, where game objects were added via a tree-view interface, along
with resources; and the IDE was responsible for processing and packaging these resources for optimal end-use.
The resulting resources were likewise run next to a pre-compiled SeleniteWin32.exe

There is a relatively large expanse of time between the creation of Selenite in 2009, and the creation of Engine4
(or EngineIV ...it's not really important) in 2013; E4 represents several massive shifts in the way I build engines
at least as of the time of this writing.

  • It's in HTML5/JS, runs in the browser, and is 'wrapped' for platforms/services that only except exe, etc.
  • It's heavily designed around The Trinity Pattern which is a design pattern I developed to aid in making a game
    expandable, without breaking save-games, or amassing technical-debt with each release.
  • Dependency Injection and Law of Demeter are used heavily to reduce coupling
  • It's a series of engines, where for each new game we clone the engine code of a game most like it;
    and features are selectively merged backwards if they're desired.
  • Each game's run-time is optimized to that game, without regard for other games. This is to avoid
    having to square new features or feature modifications/removals against existing games.

 

The Problems

It became clear early in the port, that I was going to have an issue with the difference each engine handles 
a concept which I refer to as residency.

In Selenite, there is the the Game class, which has a list of Room classes, and each of these rooms had a list of Actor classes;
and when the game was loaded, that tree structure would be created and resident in memory; addressable at all times.

...not a terrible design, but one I had departed from a while ago; the primary issue is that Selenite mixes the issue of State 
and Runtime ...that is, objects are in charge of their runtime representation, mechanics and non-persistent state and 
they also hold their persistent (save game) state as well.

In Engine4, the there is a separate class for a game object's persistent state, as well as its runtime.

This allows an object's state to be retrieved, and passed into the construction of a newly minted runtime object.
runtime objects can be created and destroyed at will, with its separate persistent state living on.

This explicit separation of persistent state, as well as the tear-down and reconstruction of game objects 
is really helpful in allowing for game changes, additions/updates; without breaking previously saved game-state.

...however!  That is really not important in the context of porting Static:IT

So, the residency scheme in Engine4 (well new Static:IT's copy of it at least) needed to go, it simply wasn't worth
trying to massage the wealth of code to deal with alternate mechanisms for modifying non-resident runtime state
when I could bring the engine into alignment with the original needs.

...and thankfully, due to dependency injection and law of Demeter; the change was easy.

Instead of creating and destroying each room, and its actors as the player traversed them, I was able 
to shift the code, changing mostly top-level factory functions, to create and maintain the total list of rooms
and actors at start.

...in Part:3 I'll cover issues pertaining with porting the scripting from Lua to JS
 

'lo again all.

I mentioned in my previous entry that I've been porting our 2009 release, Static: Investigator Training
which is a C++/Direct3D/lua fmv horror adventure; to html5/js (canvas)
using the base code from 96Mill and Revel Immortal as a starting point.

The process has been going well, however there have been some sticky spots.

  • extracting the original data from binary files
  • atlasing approximately 300mb of png compressed graphics
  • mimicking synchronous co-routine functions lua provided in JS
  • differences between the original engine and the new engine
  • re-re-remembering that everything takes way longer than you think it will

I attacked what I thought would be the hardest problem first, which was extracting the original binary data.

There were two forms of binary file classes.bin and game.bin; where classes.bin represented the data classes or 
'templates' that described static, shared (by flyweight pattern) attributes for all three object types; game, rooms and actors.

...and where game.bin was in the exact form of a save-game, that represented a new-game initial state. That is representing the 
actual objects, their relationships (game has rooms, room has actors), starting attributes (position, animation, alpha, etc.)

I used NodeJS to parse both of these files and export json equivalents of each file for easy access of data; I also took this opportunity
to have computer assistance for renaming/transforming members to better match what the new engine would expect.

 

Next I began to import the existing resources, which involved preparing them for a lot of atlasing

Audio was simple, save for the shear amount of it; when starting a new HTML5 project; you always take size and amount of 
resources into consideration; it's like climbing Everest (not that I ever have) but everything you include needs to be downloaded by the user
who is expecting a snappy game on their probably outdated tablet ...so you're careful.

I didn't have any such luxury in the port, the final sound effect atlas came to 10 minutes; which should be fine.
...thankfully voice files are not atlased, as there is over 500 of them.

In addition to atlasing, all of this data must be trans-coded as well, from source formats such as .wav, to deployment formats of .ogg and .mp3
...why both? because depending on which device/browser/version you encounter some are only  capable of running one or the other ...and some 
which are capable of playing both, are better at playing one than another ...and some devices outright lie.  But this has gotten better over the years.
 

 

What am I up to?

Hi everyone!

Been a while since I've posted here, however those that follow me elsewhere know I've been quite busy.

I really want to get back into regular posting on technical aspects/happenings of edigames.com

I've finally come to accept that people on Facebook are not interested in how the 'sausage' is made.

...so then, the news:

 

My wife and I have consolidated our separate companies and collaborations into a parent brand

DualVisionaries.com

We'll be maintaining specific brands where appropriate, Ethereal Darkness Interactive, JackiJacobs Photography, etc.
DV will serve as a catch-all for weird things/collaborations that aren't worthy of their own brand; and deal with multi-disciplinary
needs of EDI and JJP


We released an update for 96Mill

It was great to revisit the game, add a few more alternate endings, additional puzzles, and record/add some 
voice acting that was absent in the 2016 release.

The release didn't really move the needle in terms of sales, however, existing owners seemed to appreciate the additions
so I consider it a win; even with the investment of about a month.

We are porting 'Static: Investigator Training' to html5

Believe it or not, the first game that we applied our 'three month development' process to; and which was very short
in terms of gameplay time, compared to our previous titles; has turned out to be our most profitable game.

Note that I highlight profitable, it hasn't sold the most units (though it is probably second by now), nor has it generated the most revenue
but the time/revenue ratio was great, compared to say Morning's Wrath, which made a lot of revenue, but took over four years to develop.

So with that in mind, we think it is worth the investment to re-master some aspects of static:it, improve some of the maligned aspects; and
allow it to be played on a myriad of platforms/devices; not just windows.

We're targeting Q1 2018, and are pretty far along but, as usual, the port complexity was a bit underestimated.

More on the specific complexities in my next post.

 

Morning's Wrath II: Revel Immortal is alive and well

It's the project that really just needs to die, it will never recoup the development cost we've sunk into it, but the best part is
that doesn't matter.

We have a fairly solid plan to adhere to our 'three month development' process to finish up revel, and release it as a single
appropriately sized product; the idea of producing 'endless' content within a single game is great, but in addition to its complexities
we don't believe the market reacts as strongly to 'a new paid dlc' vs. 'a new sequel' even if content wise they are equal.

Several contractual complexities also have compelled us to put other projects first; So, expect revel, but don't expect it
until probably after Static 2 

Greetings All,

Just wanted to mention that 96 Mill is nearing the end of it's beta phase, and will be out for release soon!

If folks are looking for a last minute beta peek, please message me today or tomorrow (Friday) with an email address.


Feels good to be near the release phase!

"In EDI Games' upcoming 96 Mill, players are sent in to assist a demolitions expert in bringing down a building with a troubled history of scandal and mysterious disappearances. What could go wrong? If you're an adventure gamer (and you are), here's hoping the answer is "plenty!" when the new horror adventure from the creator of STATIC: Investigator Training is released this fall."

Full story at AdventureGamers.com

96Mill Testers Wanted

Greetings All,

Interested in alpha/beta testing our upcoming game 96Mill?

We have several slots open, just message me with your email address.

And I'll send along a beta key.

(email address is used for key recovery and communications relating to the game or platform)

Greetings All,

It's been a good three weeks, and things are finally at a point where I can start talking about them.

First things first:

Revel Immortal

Revel is at an interesting (good interesting) spot right now; we've made all of the changes and porting that we set out to accomplish Jan 1.

This doesn't mean it is 'done' by any stretch, however while still in Alpha it is looking pretty decent; and though we're not planning to popularize it at this point, the new version of Revel should be going live sometime this evening (eastern time).

the 'play now' link for revel on http://edigames.com/ will be updated (it currently points to the old version)

For those following Revel this is a great chance to have a look and send in some feedback.

96 Mill

Those of you who have followed our developments closely, will remember our 2009 title STATIC: Investigator Training.

You could certainly say it stands out among our other games, being an FMV horror adventure.

But there are some noteworthy aspects of StaticIT


  • it was made in three months, design, casting, filming, implementation, testing
  • it was our shortest game
  • the tooling was already developed before the game was started
  • the game was fully designed before development started
  • it has sold the least amount of units of our other games (though its catching up to Malathedra)
  • despite this, it has been our most profitable product
    That last item might be somewhat confusing, but it has everything to do with just how much time an energy goes into a product.


    And while I'm not really all about splitting hairs in terms of revenue and profitability; there comes a point where the development time investment grows to a degree that you're never going to see anything resembling a profit.

    Much like code, the less code the fewer bugs; it doesn't matter how good the code is.

    So that brings us to the next six months.

    We've been planning, since roughly this time last year to do two games, each with three month development schedules; like Static.

    The first of these two games is 96 Mill, a first person horror adventure.

    We have a development cycle spanning July 1 through Oct 1; and I am happy to say, even only two weeks in we're ahead of schedule, with all locations having been photographed.

    Here is a bit more about 96 Mill, but you can expect to hear more about it on our facebook page.


    "HDC (Hamilton Demolition Company) Limited, contracted by the city to deliver a demolition plan of the infamous Edmont Worsted Industrial Complex; former site of the Unified Electric Corporation (UEC), and before it the Edmont Worsted Company, constructed in 1820; with a 1920 brick addition; utterly abandoned in 1996 and decaying for twenty years.

    Strictly off limits to the public for reasons of health and safety, HDC has sent in lead engineer and demolition specialist Frank Galvani; and you (the player) have been tasked to assist him in documenting the structure and rigging it for implosion.

    At around 500,000 square feet, the complex is massive; spanning four floors in the main building, and a 5th floor tower.

    Through its history the site has been plagued by strange, or unexplained happenings, and Disappearances, before its closure alongside the liquidation of UEC in 1986.

    Alleged pollution of the abutting Peter's River, via industrial waste (developer, pcb's etc.); brought an EPA investigation that ultimately sent several UEC executives to prison.

    Disappearances of employees beforehand and during this investigation are alleged to be foul play; but extensive search recovered no bodies; and locals seems to suspect something darker and keep clear of the building.

    In 1996 a small portion of the building was partially destroyed by fire, arson was assumed, but inspection by firefighters of the building proved dangerous and caused the mayor to issue a standing order of 'do-not-enter' for all police and firefighters less life be at stake.

    Despite such orders, and especially due to its dilapidated 'spooky' nature; various paranormal groups and investigators have conducted illegal trespass and collected evidence and personal accounts.

    Such 'evidence' has been non conclusive."

Update

Dang, I can't keep a journal to save my life!

Well hopefully some folks are subscribed to our Facebook group, it details more regular, though less in-depth happenings.

So notably, end of May through June 16th I was away, a bit of business, and a lot of fun; trying to get in a few weeks of vacation.

Though I wasn't completely idle on gamedev during that period; I produced and submitted Morning's Wrath 1.4, Release Candidate (RC) 7

Hopefully someday our publisher will get that added to steam, it has some serious improvements over the current version (1.3) which has been the only release since roughly '06

Hopefully soon this version can be purchased standalone on our site, and we'll provide the update for free, for any past purchasers (just drop an email to raymond@edigames.com with full name and purchase details).

As for Revel, we've been working to get more systems implemented and 'draw' everything together, in hopes of a near term version update.

I've laid out an internal development schedule that is very aggressive, in hopes that it will really spur some action; I guess we'll see.

A bit more on change

Let's start with a new screenshot, showing some of the 'human/male' graphics I did over the weekend; and the new 'name ribbons' for portraits.

p3WqvH3.jpg

Images aside, I wanted to formally touch upon why I've chosen this new graphical and gameplay style for Revel Immortal.

It can really be boiled down to content being too 'expensive' to create that is, too time consuming for the benefit; as well as several of the systems pertaining to that content being significantly flawed.

In late December we basically did a half-year evaluation of how much progress we made with content creation in the old system.

We found that the majority of our time was going to developing the isometric environments; and very specific systems and technical issues pertaining to that (sorting, occlusion, lighting, portals, interior dissolves, performance, etc.)

The result was, a lot of time spent and not a lot of content created; basically not getting much closer to people playing and enjoying Revel Immortal in its current form.

...and for all that time and effort, play-quality was not really exceptional; a number of systems (npc dialogue, equipment, quests) were quite good, but other things (isometric interactions, control scheme, combat, character size) were not very good at all.

To make matters worse, our progress should have had a significant jump-start, as we re-used practically all the environments from existing Morning's Wrath; in hind-sight this did give us a boost, but once we encountered the challenge of making new locations from scratch (notably the Garranshall marketplace) productivity was horrible, with an estimation of maps/locations taking months to potentially complete graphically and functionally.

In short things were not good; for a very key part of the game, it was too hard to author, and the results weren't very good.

Technical issues, limitations of HTML5 and 2D engines; all the usual suspects, depth sorting, behind wall occlusion, lighting; really limited our ability to solve these problems as well.

Naturally they could be solved; there are plenty of excellent 2D Isometric RPGs, but could we solve them? in reasonable time?

We rightly received harsh criticism for control aspects of Morning's Wrath, (and Malathedra, AND Static) and I saw that becoming a repeat issue, which I felt was not acceptable.

All of this evidence forced me to take a really hard look at what we've been doing, and how we can change things to get things moving a lot faster; and showcase what really matters in Revel; that is, the story, quests, exploration, combat, equipment/item management, character progression.

Building 'vast' isometric maps felt like the right thing to work on at the time; but wasn't getting us there.

Faced with potentially calling it 'quits' on the project (which for those keeping track, has technically been in the works in various forms for about 6 years (8 in the absolute, but i technically did not do game development for about 2 years during this time), that's 1 more year than it took to write Morning's Wrath from concept to ship) I opted instead for drastic measures.

I had identified the major aspects that were giving us trouble; and now I was desperate enough to go ahead and act on those issues in a way that I haven't dared to before.

The plan?


  • Drop all of the isometric areas
  • Use single image backgrounds instead
  • Have a single large overland map of graph connected locations
  • Have pc/npc/enemies use dynamic portraiture
  • Have battle play out in a 'planner' type mode (think FTL-ish)
  • Keep all the existing content, quests, npcs, etc. all the good stuff that works
  • Make the changes fast and get moving.


    Its a gamble, but so far; in terms of performance, it is working; the result was overwhelmingly a 'technical shed' removing tons of complexity.

    Two months in, and we're essentially back where we left off; which is a great turnaround time, given that previous revamps have taken roughly a year.

    It is clear that while I was able to recognize the need to revamp and cut, I simply did not cut deep enough.

    It has been clear to me since I released Morning's Wrath, that it needed, and was going to get a sequel.

    Hopefully I've set things on a path towards real productivity.

    Look forward to more regular content in the near future.

    All questions are welcome in the comments below.

Greetings all,

It's been roughly a month since my last update; though I've been giving detailed updates via the edigames Facebook page, mostly weekly; mostly uninteresting.


While I didn't mention it in my last post; it has been necessary to modify the format or 'style' of Revel Immortal, such that the content creation is doable ...and when I say doable, I mean doable by me *looks around* cause that's who is actually doing the designing, rendering, coding, writing and integration.

Some of you might remember there was a large revamp, around April '14 which lasted through Dec. '15; it was both revamp and new content creation; but that span of time, and the content that was able to created during that time was simply not sustainable.

There were also several problems with the technical aspects of the design (controls, character size, etc.) but I won't go into detail on that, since it really doesn't matter.

The real killer was that the effort required to author content for Revel in that form, was simply too much effort; if I ever hope to see it finished (hopefully no one is keeping count).

Since a large revamp was done already, there was really only one solution, a much more drastic revamp; one which I don't think I'd have even considered some years ago.

In any event, I'm not going to explain most of the changes; I'd like them to speak for themselves via video or animated gif as they become finished; however, I will show this, still very early screen cap, that shows a few of the new aspects.

Naturally this is a dev wip screenshot, you know the drill.

1vNvcAr.jpg

I'm not dead...

Though it depends on your definition of dead, in some ways I might as well be.

Content? There's been a startling lack of it.

Why? Life as an employed 32 year old husband and property owner ...and probably some general laziness.

So yeah, sorry, progress has been very slow; I am working on Revel Immortal; as like any game project it would like nothing more than bleed every drop of life from me ...and Revel is a very ambitious project.

In closing, if you're still reading this, thanks!

-Raymond

Update 7/6

Hello All,

Just got back from a trip to Chicago; I highly recommend Lou Malnatti's deep dish pizza; should anyone get the opportunity!


Progress:

So progress has been singularly focused on finishing my office space; as I've said before, it is a big job, but I can thankfully say as of right now I am doing final sanding and priming of the drywall.

Still a lot to be done; but now is a good time to do it, summer is slow and non-productive for me in game development anyway.

I am getting the itch to get back on to Revel; but I know I have to see the finishing of the office space through.

Update 6/16

Greetings All,

Time for a bit of an update.

Not much progress on Revel; I am doing a good job of taking the summer off from it.

...but tons of work in other areas.

My previously mentioned open source project 'object model serializer' is now in fairly complete and stable condition; I am looking for some real world test cases to help make it better; if anyone is interested, do please let me know.

The vast majority of my work recently has been the finishing of my office space; sadly it takes a lot of work and time, as well as any software project.

Hopefully that will close out in a month or so.

In about two weeks we'll find ourselves in July, summer in full swing; no doubt side projects will prevail through then and into August.

-Raymond
Greetings All,

Part of our summer project plans are to get some older projects onto GitHub with free permissive licenses for both private and commercial works (Currently we are using MIT license).

Our first offering is something I've wanted to see become a common library for a long time.

Serialization of object models in C++

...that is an easier route to save game files for complex game states;

without having to understand the nitty gritty of object model serialization techniques.

https://github.com/edigames/object-model-serializer

First off, there are better known, more complete (at least as of this writing), and far more complex implementations out there.


But a key element for us was to adhere to a few guiding principles:

  • It should be tiny (2 files)
  • It should be non-intrusive, procedural style no base class inheritance requirements
  • It should internally handle references and cycles ("saving pointers")
  • It should be 'soft serialization' ability to add/remove and out-of-order members without 'version blocks'
  • It should come with a complex use case example (see simple_rpg folder)
  • It should use standard streams, for file and in-memory serialization.
  • It should be a lightweight binary format (soft serialization is 'easy' in something like json/xml)
  • It should not use external pre-processor, or code generation techniques (gross.)

    Some future goals...

    • It should be endian/architechture agnostic (this should be relatively simple)
    • Higher level interfaces should be optional to reduce syntax and mundane routines

      It is still a work in progress, but I have overcome a sticking point which made me question feasibility (without excessive overhead), such that I now feel it is ready for folks to have a look and even begin using.

      I ask everyone willing to have a look, comment, rant, contibute etc.

      Problems, specifically in usage will be addressed as quickly as possible.

Update 6/3/15

Greetings All,

Time for an update!


As I said in an earlier post I am technically 'off' from EDIGames until autumn rolls around.


...that being said, this is sure some busy time-off.


In addition to the usual necessities of life, I've been doing a bit of work finishing up my new office space; drywall, tape and mud; that sort of thing.

I'm very excited as this will hopefully be my first space where I set up a semblance of... culture; with a bookcase or two displaying some of my favorite reference; and maybe a case to display our magazine article and first copy Morning's Wrath.


Nesting aside a good bit of technical work has been under way.


We have a new, but still a bit WiP website at http://edigames.com

Still keeping with the one-page site for simplicity, this one is based on a template however that is better for mobile devices and wont be penalized by the new google indexing criteria.

We're still working (currently in testing) on the steam release of Morning's Wrath; again with StrategyFirst

I'm pretty excited about this release (designated 1.4 at the moment) because we chopped the entire antiquated back-end (D3D8, DSound, etc.) and the Win32API in exchange for SDL2.

This means we're seeing a big performance increase with their much better sprite batching system; and not having to support a lot of bygone video hardware that can only do 256x256 textures.

Another big improvement is support for widescreen displays.


Revel Immortal has gotten a bit more content; and we are working down the bug list; currently for technical features.

We're overdue on a release, but I'd like to make sure this next one is a bit more worthwhile.



We've created a proof of concept for getting our HTML5 based games (Revel, and the foreseeable future) on Steam; and so far it has passed muster with our Steam rep. we'll have to see what further testing proves.

I've been investigating three.js a bit as part of two new projects that will hopefully be announced in Autumn; longer term goals but pretty exciting prospects.


Well I think that is all for now, keep an eye out for new content soon!

-Raymond
  • Advertisement