Criteria and priority

I was reading through that article again, at 23 Recommended 3D Game Engines (Updated) (worldofleveldesign.com).

The author listed criteria...

Criteria used to include a 3D game engine in this list were:

• Available to download
• Affordable, free (easy access) or open source
• I have used it myself and recommend

... and I realized I should probably have some criterial as well.  My criteria are:

• Available to download.
• Affordable or free.
• Ability to change source code or add custom, low-level features (for the weird gameplay mechanic I have in mind).  If I can implement the gameplay mechanic without modifying source, then that's fine.
• Ability to store and retrieve game data (volatile and static).  I don't think I care about the data storage, though AWS or Azure would be nice.
• Ability to allow for the usual MMORPG features.  Ie,
• Chat and chat options (safe, filtered, and unrestricted).
• Purchasing gear, or perhaps server space, or subscription, or whatever I decide on later.
• Dungeon instances.
• Inventory.
• Playing with other people.
• Grouping.
• Etc.

My priority with this whole endeavor is to actually make my game, but a close second priority is to experience multiple engines and be able to speak to their suitability from the perspective of actual experience.  I read through some more articles on World of Level Design - Tutorials for Becoming the Best Level Designer and Game Environment Artist, and I realized, this guy has already done this--learning multiple engines and speaking to their suitability.  He did it to become a great level designer and write for his website.  I'll be doing it to make one specific game and code the weird mechanic.

In my game, the priority of the game features are as follows:

1. Code and make functional my weird gameplay mechanic.  This is my highest priority because it can be stand-alone, and gives me coding experience, and might make a worthy game.
2. Create an immersive world that is based on the Raksuran novels by the amazing Martha Wells.  (She long ago gave me permission, as long as I didn't publish anything publicly until she got to see it and give further permission.)  This is second priority because it'll take the most tedious work.  But it's nice to have the background story and world rules already specified--by the novels.
3. Include the Emeralda story somehow, maybe for solo questing or just for play-learning.  (This might not make sense to anyone but me, but that's ok for now.)  This kinda requires #2.

New Inspiration to Start Again

Owing to years of talk therapy, recent effective health treatments, and the free time afforded by having no stinking job (thanks, covid-19), I have some new inspiration that's making me want to start again.

I've gotten loose permission to base the game in Martha Wells's Three Worlds.  I can't make it public til she gives the go-ahead.  So, I should make sure I can flip a switch and change the location/appearance.

I've got an interesting idea for gameplay.  But also, I want to weave print-making into the story.  If I can't make the gameplay work, it'll just be another MORG, but I'll put in real herbalism.

I found a cool (though old) article comparing game engines.  I wanna move slowly, comparing the top three that I choose--probably Unreal, Unity, and Source.  Something is blocking me from choosing CryEngine.  Probably something silly.

https://worldofleveldesign.com/categories/level_design_tutorials/recommended-game-engines.php

It warmed my heart to see Torque3D there.  I LOVED that game engine, and I loved writing the tutorial they published back in 2012.  I wonder what became of that.  Looks like the engine is open source now, under MIT license.  Hmmmmmmmmmm.  Their networking code (for multiplayer services) was ahead of the other game engines at the time.

Maybe I should start with, like, 5 game engines, and then let 2 drop off over time, based on the ease of use.

Man, there's so much to learn.  I've just gotta remember--I don't have to know everything before I need to know it.  I can learn JIT.  :D

Update:  12/31/2020

I just spent an hour online, chatting with old friends and co-workers from a game company I worked for a few years ago.  The consensus seems to be: 

• Unity
• Unreal
• Source
• CryEngine/Lumberyard
• Torque3D
• Godot

I hadn't heard of Godot before, but this comment had me putting it on my list, "Chances are if you like the Node based approach to game development, you will love Godot".  Not sure I'm familiar with the "node" context, but I'm excited to learn about it.

One person thought I would come to eliminate all but Unreal fairly quickly.  :)  Some also said the proprietary engine we all worked on would be choice #1, and I agree, but unfortunately I can't use that.  :(

Some interesting aspects were brought up which might effect my list, like target audience (ie, GameMaker isn't really for AAA game makers, but has been used as such), and track record for publishing (ie, Lumberyard, or rather Amazon, has had some challenges when trying to publish a game that they eventually cancelled altogether).  Sounds like I need to keep my ears open for game and game engine news while I do this.

Validation

Heh. I was reading Clark Aldrich's Simulations and the Future of Learning, and I saw this image.



Boy, does that ever look familiar. :)

Tool chosen, storyboard written...

A lot has happened.

Bill and I met with Tiffany McVeety. Bill worked with her years ago. Now, she's an entrepreneurial mentor, and she's written two books. She gave us some good advice--some for Bill and some for me.

I started looking for learning games that were similar to ours. There aren't many, and they're all designed quite differently. I also found the http://www.elearningguild.com/, and through them, found a line on other resources to find more learning games. In short, I came away confident that the learning mechanisms I have in mind are pretty unique.

I also started looking for an "advisory board", or just a collection of mentors that could help me with game design and implementation. Bill started building his advisory board too, but in the business arena. I found GameMentorOnline, and signed up with a mentor. Since my hubby is making his own game, he's now on my advisory panel too. Thirdly, once I have a prototype, I'm going to pay for a review and advice from Clark Alrich Designs, since I've become a huge fan of his books and ideas.

My GameMentorOnline mentor helped me choose a tool by suggesting questions that I needed to prioritize. I was looking at tools in terms of what would be the most prevalent/popular in the coming years (hint: HTML5 and Javascript). I was also omitting 3D tools because Bill and I got some rather curt feedback from a Game Startup Bootcamp judge, "the very subject matter is naturally 2D". Uhm, what? I must've written the game description very poorly, then. Anyway, my mentor said I should be focusing on these high-priority questions:
- What tool will help you make your game faster and closer to your mental picture?
- How do you intend to distribute it?
- Do you want to ship it on multiple devices?
The answers for me were: Torque 3D, stand-alone install, and no.

To answer those questions, my hubby said, "You need to make a storyboard. How do you know what you need in a tool without making a storyboard for your game to expose issues you don't yet know about?" I resisted at first, because in all the game design books I read and courses I took, none talked about making storyboards. Then I realized, of course they didn't! They're based on FPS games! Mine's a mystery-driven learning game. So, I made a storyboard for my ideal game, but keeping things very simple, and WOW, progress!! Some issues with gameplay came up, but then so did some spontaneous solutions that I never would've thought of otherwise. Plus, gameplay patterns started to emerge that will define our mechanics. Plus plus, I realized 3D is the way to go. It's how you get deep immersion in a story.


It's so strange, but now that the storyboard and tool decision are done, they're like the framework to hang other stuff on. Like, when I get an idea about the visual design of the world, I now have a way to record it and judge if it'll work. If I think of a challenge for the player, or a cool aspect to add to the game, I can see where/how it'll fit in.

Cool. Onward and upward. I took another contract with Garage Games so I need to drop the game for a week to get a strong foothold on the project there, but hey, my job is symbiotic with the game. :) Can't wait to start building the world. Oh, but first, the next challenging task is to design the database of game and player data, cause that'll tell me if the structure of events, prerequisites, clues, etc, that I pictre is going to work.

Wish I'd gotten together an "advisory board" sooner. :)

Game v1 -- HOGs rule

Bill and I had a long chat. He's done some market research about the types of games that are appreciated by the main demographic that buys his presses. They like HOGs and other minigames. If we test out the backstory and game mechanics and learning mechanics in a simpler-to-develop game like that, that's a pretty good way to go. Then, we might have some minimal revenue to support making the 3D version.

I found a tutorial for Silverlight. So I made a demo HOG here, http://www.godreaming.com/emeralda_v3/default.html, in about 2 hours.



Now, all we have to do is wrap it in the backstory, add some more minigames that are targeted at learning what we want to teach, and add language support. (Bill sells presses to people all over the world.)

This is pretty do-able. Not sure how easy it is to publish a Silverlight game though. When Bill and I spoke with Scott Kirk from GameGurus.com, who specializes in bringing people's game ideas to life, he said that the most popular engines were Flash and Unity. Ick. Unity. But those are your choices if you want to have some other distributor sell your game for you. I guess there's also Shockwave.

But I digress.

Onwards and upwards!

There's always an excuse not to work on a personal project

Wow. I looked at my last post from when I worked for the Microsoft Surface team. Now I work for Garage Games, creating tutorials for Torque 3D. I keep saying, "Once this contract is over, I can focus on Emeralda." Riiiight. I've said that for 6 contracts now. As soon as I stop working, I panic about money, and find another gig.

Time to start working on this in the evenings. We've got no kids yet, so now's the time, before my stupid inherited 24/7 defacto maternal responsibilities come into play. (Grrrrr. Let's face it, as egalitarian as my hubby is, who's going to be the one assumed to be on-call?)

I went to a Serious Play Conference last week that provided me with some awesome nuggets of info about where to go from here, so now I'm all inspired again. I found out about a book that is already giving me good guidance, Unschooling Rules by Clark Aldrich.

I also came across an article, How to Build a Game in a Week from Scratch with No Budget.

Nope, not going to be done in a week, nor from scratch, but it gave me an idea. One of the things I learned at the conference was that a game demo is perceived to be a good demo if the art is near-production quality. If you want to get people emotionally invested in a game, have the art up-to-snuff. I'm not sure how true that is. I mean, I met the students at DigiPen who created the game that was purchased by Valve and turned into Portal. Their game had completely different graphics--sort of a medieval dungeon. The Valve people zoned in on the portal gameplay mechanic and saw its potential. So, what's true? Is art quality important or not?

I figure I'll take art completely out of the equation by purchasing it all. I'm gonna use the art packs at http://www.garagegames.com/products/browse/artpacks and assets from http://www.turbosquid.com/ and http://www.frogames.net. My internal compass will be, "How Fast Can I Build a Serious 3D Game Demo with a Middling Budget". :)

Redesign

I've had no large chunks of time to play with this lately. :(

However, now that I work for the Microsoft Surface team, I'm surrounded by game designing enthusiasts! One of them runs the local game designers/developers meetup group! She's amazing. She has one social meetup per month, and one workshop meetup. I find myself among people who design games in XNA, in WPF, on the Surface (wouldn't I love to make a 3D model of a press you could play with on a Surface!!!), on Xbox, on Windows, on Windows Phone, etc.

It's been a very encouraging environment. One guy who's developing my all-time favorite game for the Surface (can't say which one) said he just tinkers when he has 20 minutes, without hoping for any outcome. That's quite a mind-shift for someone like me. I'm gonna try it. I had a couple hours tonight. I sat down without any expectations and just dinked around.


I've decided to create the UI in the new Metro style. I can't find a link to the Metro design principles. Mainly, you want to help your user focus on content rather than get them distracted by decoration. Plus, you should only make UI elements appear to your users when they're needed. There are a few other principles, like using natural and intuitive gestures and not trying to contstrain yourself by mimicking realism when it would be more convenient for the user to be true to the technology, etc. One of my team mates is creating a booklet illustrating the whole Metro idea. (Man, I'm lucky.)

I've posted an app that's just the menu. Emeralda v2 - Metro menu idea. My next task will be to wrap it in the cool code I created while going through Michael Snow's book that allows you to make the Silverlight control fill your screen, create a game loop, etc.