Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

3681 Excellent

About EDI

  • Rank

Personal Information

Recent Profile Visitors

19080 profile views
  1. EDI

    96 Mill

    At 96 Mill Street, Woonsocket, Rhode Island, sits the Edmont Worsted Industrial Complex, a derelict, condemned building with a checkered past of unexplained events since its construction in 1820. You are an employee of Hamilton Demolition Company, tasked with assisting demolitions expert Frank Galvani in rigging the building for implosion. Click here to play 96Mill on Features Multiple endings with 10 different outcomes A genuinely creepy environment, with over 50 locations to explore An interactive story where your choices affect the outcome Familiar point and click gameplay with quests and objectives Play in Browser, many platforms many devices Fully Voiced Dialogue
  2. anyone else experiencing this, or just me?
  3. I've noticed that after saving a blog post I am no longer able to edit it, I get the error: Sorry, there is a problem This content can no longer be edited. It may have been moved or deleted, or too much time may have passed since it was posted for it to be edited. Error code: 2S136/E
  4. 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'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. Part:3 I'll cover issues pertaining with porting the scripting from Lua to JS
  5. '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 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.
  6. EDI

    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 I've finally come to accept that people on Facebook are not interested in how the 'sausage' is made. then, the news: My wife and I have consolidated our separate companies and collaborations into a parent brand 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
  7. Assume the role of Princess Morning of the Leowyn Kingdom and guide her on a quest to master the ways of magic and save her kingdom from invasion. Click here to play Morning's Wrath! Features Classical Adventure/RPG Story-driven gameplay with puzzles Dynamic spell system, use 24 different magic runes to create countless spells in facing a host of enemies. Newly re-designed game engine, better and faster than the original!
  8. Assume the role of Julie Masters, a new Berkshire Paranormal investigator as she explores and investigates the Houghton Mansion using all the ghost-hunting tools of the trade! Click here to play Static: Investigator Training Features Use various tools to collect evidence of ghostly phenomina Fully-Voiced Dialogue
  9. This is a technique I employed with decent success this past summer, in developing 96MILL   I went for a short-form first-person adventure, few mechanics, photography instead of modeling. Used the existing engine tech i'd already sunk for a more complex project. Managed to bring it from concept to release in three months.
  10. EDI

    96 Mill is now on Steam!

    @Navyman Thanks, We went with the publisher we worked with for getting two of our back-catalog titles on steam - StrategyFirst
  11. ...and on sale, 15% off!
  12. EDI

    96 MILL Released!

    Thanks Ashaman! ...and thanks for all of the great testing you did! -Raymond
  13. EDI

    96 MILL Released!

    Thanks Navyman! That first slide is a youtube video, with a bit of gameplay; but you're right i need to change the height, thanks! The game is written in a fork of the 'Revel Editor' which is a custom ide/engine pair written in C# and HTML5. you might say it was written in the '96 MILL Editor' This set of technology is what we're referring to as our '4th generation engine' no real snazzy name; and it is designed to be forked and modified (and reintegrated) per game, in the interest of not trying to create an 'all things to everything' game engine, where you end up spending a lot of time trying to square features across an ever growing catalog of games. Our current focus, as of 2016 has been to focus on 2-3-4 month release length projects, rather than larger monolithic releases.
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!