Video Game Engines: Which Should You Use?

Video Game Engines: Which Should You Use?

by | Jun 21, 2014 | Ascend Blog

Choosing a Video Game engine is an important step in developing and releasing a new video game. The Video Game engine is a software framework, a collection of development tools and reusable components to put together a working game. Using a gaming engine saves time, money, and allows the developers / designers to focus on their ideas taking shape, not actually developing the engine itself from scratch.

Recently, we (Jake and myself from Ascend) began taking a look at various video game engines on the market a user may download and begin using to develop / design a video game. We defined some of our criteria for what a game could do ahead of time before making this decision. We decided we wanted our game to be:

What We Use!

  • Widely Accessible and Playable on a Mobile Device
  • Include minimalistic graphics
  • Built on top of a common programming language

With these criteria in mind, we began our search for the gaming engine which would help put our vision together. We came across three main engines currently hot on the market:

  • Unity3D
  • Unreal (UDK)
  • Cry Engine

The increasing number of Independent (Indie) game developers has led to many companies releasing their gaming engines on the market and (often times for a fee) allowing indie developers to download, install, and develop a game using the engine. Physics is another key factor when evaluating a game engine, for instance if your character throws a bottle, how does the game capture the action of throwing the bottle, the bottle falling, etc. Below lists key points of each of the gaming engines, and how they relate to one another by comparison:

Unity3D:

  • Price – Free to download and install. But add-ons, features, and the professional edition may run up to $1,500 or more.
  • Graphics – Decent. Can do 2D and 3D, but the graphic details are not as strong as other games.
  • Physics – Excellent. Built in physics engine
  • Programming Language Used – C#, very widely used and easy to learn OOP language.
  • Royalty Payments – None until you make some cash ($100,000)

Unreal UDK:

  • Price – $19 per month to rent, $240 total price with one license which can be used in an entire company.
  • Graphics – Amazing. Simply breathtaking.
  • Physics – Excellent. Built in physics engine
  • Programming Language Used – Native script, difficult to learn.
  • Royalty Payments – The page crashed when we looked (haha)

CryENGINE:

  • Price – $10 per month.
  • Graphics – Fantastic. No Mobile capabilities though yet.
  • Physics – Excellent. Built in physics engine
  • Programming Language Used – C++ / C# / LUA. CryMono (C#) is commonly used when starting out.
  • Royalty Payments – None from what we can tell (woo hoo!)

Please note, some of these factors / dollar amounts may have changed since this was last visited / published.

After looking at the three engines in detail, we found Unity3D to be our tool of choice. Its ability to easily port to a mobile device, loads of documentation / tutorials, and use of a common programming language (C#) led us to use this gaming engine as our framework. While we do are not getting the full emersion / details allotted by other engines, Unity3D is built for beginners to learn the ins and outs of developing a game. It’s much more forgiving than Cry or UDK.

What are your thoughts? Do you have a favourite gaming engine?

Health IT Risk Management: Some Key Pointers

Health IT Risk Management: Some Key Pointers

by | May 2, 2014 | Ascend Blog

The Project Management Body of Knowledge (PMBOK) defines risk as an uncertain event or condition. If it occurs, it may have a positive or negative impact on the project or product being developed. Organizations perceive risk differently, either they are risk adverse or risk attuned. So, how does Health IT fall into all of this?

Health IT, by  a complexbeast to tackle, it not only requires a high degree of technical skill, but also a good handle on policies and laws in place to ensure technology developed is compliant.  in Health IT projects is not just at the product level, but often involves or impacts many stakeholders. Ensuring that the project takes maximum advantage of those risks which may have a positive impact while mitigating those risks which will have a negative impact is important in a complex Health IT project. I would like to call out three main factors when it comes to Health IT project risks: a project manager must plan risk management (as the PMBOK says), capture and monitor risks, and communicate risks to stakeholders.

Planning how to perform risk management is important, consistency must be maintained throughout the project to ensure risks are captured, managed, monitored, and updated in a coherent manner.  These ideas must be enforced throughout the project, and documented in the risk management plan. Brainstorming sessions, interviews, etc. must be captured. With all the Health IT policies and technologies floating around, having a good, consistent way to tackle hurtles presented by risks is key to success.

Capturing and monitoring risks allows for a project manager or project team member to capture project risks found, update those existing risks, and provide a risk strategy. Many times, risks are captured in a Risk Register, a centralized area where all risk information is captured. Risks may have Probability / Impact analysis, Qualitative and Quantitative analysis performed on them as well. Risks must also be version controlled, when a risk is updated, changes must be captured. This is not only true for Health IT projects, but any projects.

Finally, risk communication is key to project success, what good is a risk register if no one can access it? Doctors, nurses, billing specialists, etc. must understand risks and weigh in, as they will be the main users of these systems. If these are mission critical systems, regular meetings with stakeholders is important, and risks should be communicated up and handed. With the Healthcare.gov project, many times risks were not communicated properly, and we saw where that landed.

Health IT Project Risk Management is an important aspect to managing a Health IT project, made more important by the growing complexity of implementing a healthcare system.

Be sure to check out our seminar co-hosted with the PMIWDC chapter to learn more about Project Management and Health IT: https://www.pmiwdc.org/2014/05/educational-seminars

Image courtesy of Washington Post
Health IT and Project Management Is Not Getting Any Easier

Health IT and Project Management Is Not Getting Any Easier

by | Apr 23, 2014 | Ascend Blog

In a lead up to my Health IT and Project Management course, I wanted to dedicate a blog post to Health IT and why these initiatives need competent and passionate Health IT Project Managers.

As spending on Healthcare and Health IT continues to grow, so do the number of jobs in the Healthcare industry. Many of these projects and initiatives are complex in nature, and require a great deal of technical and policy knowledge to implement. So, what does this mean for the folks leading the charge? Where are we going to put our $2.8 Trillion (trillion with a “T”)?

There is a theory made popular in the 1980s that a manager did not need to understand the work being performed, only how to manage employee. In stark contrast, the complexities of Health IT require a project manager not only have a strong understanding of the technology being implemented, but also understand regulations, policies, and possess a strong passion for Health IT.

Understanding existing policies and regulations is an aspect of being a great Health IT Project Manager. There are many regulations and policies on the market a healthcare product may need to comply with, should it fall under a certain line of healthcare work. The Health Insurance Portability and Accountability Act (HIPAA) standards must be upheld through strict security measures to ensure patient information is secure. The Health Information Technology for Economic and Clinical Health Act (HITECH) pertains to improving healthcare quality, safety, and efficiency of healthcare delivery. Finally, Meaningful Use (MU) possesses multiple stages in order to enable, digitize, and transport patient records among multiple organizations. This is a small subset of many regulations with cool acronyms. There’s even more, and the Health IT Project Manager needs to understand what they mean, and how they could impact their project.

Many of the healthcare technologies on the market today use a myriad of standards and must communicate (or interoperate) with one another. Any gadget today on the market, whether it be an iPhone, Google Glasses, wearable / portable technology can be leveraged for Health IT in some way. The Project Manager needs to have vision, and understand how technologies today can handle Health IT.

Finally, a Health IT Project Manager must have a passion for healthcare or health IT. Having a story and a reason for working in Healthcare provides motivation for both the Project Manager and the team. What is your passion? Why are you in health IT? Answering these questions and understanding your motivations will allow you to be an effective project manager in a complex industry.

Project Managers need to make sure the project is completed, but they also need to be leaders. Health IT needs its leaders.

To learn more, please come by in May to attend our all-day session co-hosted with PMIWDC on Health IT and Project Management here: https://www.pmiwdc.org/2014/05/educational-seminars.

Hope to see you there!!!

Agility in Requirements and Design

Agility in Requirements and Design

by | Mar 29, 2014 | Ascend Blog

Many organizations rely on heavy documentation for requirements, architecture, testing, and implementation. Often times these documents go largely unread, forgotten and exist for the sole purpose of creating a legally binding document between the IT department or consultant, and the business or organization. Iterative development, and defining solutions with close involvement with the customer is key to the success of an Agile project.

In a way, a Requirements document may be used by the business as a means to state the contractor or IT department did not exactly do everything which was written in the document. My question to that is, so why do we have a requirements document? Is it a deterrence in case an IT Department does not do what they were supposed to do? These documents go largely unread, and the development team is often confused by what is stated in the requirements, leading to longer development time and time to market.

Recently, I’ve had the chance to work with simulation software with several colleagues. Many software applications today are web applications, built using a standard n-tier architecture. At the top of the tier is the presentation layer (what a user sees), in the middle is the application layer (when a user clicks an element in the presentation tier, what it “does” is defined in the application layer), and the bottom is the Data Tier (stores all interactions, information, and interacts with the application layer).

The user (and often times the customer) only sees the presentation layer. So, why not build that first? Your business customer wants to see a solution, help mold it, shape it, and see what it will look like. The business logic is often times already defined; it is the way the user interacts with the system which will involve the customer into the design of the solution.

Many simulation tools and Integrated Development Environments (IDEs) provide the ability to build out a custom user interface with some functionality. It can be built on the fly, quickly, and demonstrated to the customer. A development team can then take software developed in the simulation environment, and build out functionality and code behind the presentation code. This increases agility, providing the customer with a functional prototype which can be quickly built with a level of functionality behind it. Developers can take it, and understanding how the presentation tier works define the application and data tiers.

The requirements document is key to documenting all requirements, but often leads to a large, unusable document for the development team. Creating software within a simulation environment provides a method for IT departments to quickly deliver a working prototype and functional software. Ultimately, this deters the customer’s notions “I’ll know it when I see it.”  Forward to Agile!

Enterprise Architecture: After the Executive Buy Off

Enterprise Architecture: After the Executive Buy Off

by | Mar 8, 2014 | Ascend Blog

What is it that an Enterprise Architect (EA) does? Why do we need EA’s? After these questions are presented, answered, elaborated, and elaborated some more, hopefully the executives will give in and say ‘go do your EA’.  Now, what is the first step?

The importance of leaders embracing and understanding EA cannot be underestimated; aligning business objectives with technology allows organizations to make better use of their existing technology, providing a clear strategic, technology driven path going forward.

Technology enables the achievement of business objectives, a key statement applicable to the first steps in establishing a true Enterprise Architecture. Isolating the business goals and functions from the technology currently utilized within the organization is key in developing an enterprise architecture. A strong understanding of business requirements and objectives is required.

Discovering business objectives, drivers, and goals may be a complicated task when there is limited technology or a small, mostly operational / help desk Information Technology (IT) department. There are several techniques, both technical and non-technical an EA may utilize in obtaining and understanding business objectives. These skills and techniques are often used by Business Analysts today.

  • Interviews: Interviewing key managers (CIO, CEO, CFO, CTO), leaders, and stakeholders provides a wealth of information on business objectives or goals.
  • Company Mission Statements / Documentation: Review organizational documentation which may be found internally or externally. Different branches of a large corporation may be responsible for different business objectives or goals.
  • OMB Guidance and Definitions: For Federal Enterprise Architecture, the Office of Management and Budget (OMB) provides guidance and definitions on various objectives and goals Federal Agencies posses.

Another, however lower level aspect which must be understood while establishing an Enterprise Architecture: the business processes undertaken to meet the business objectives and goals. Business Process Modeling (BPM) is an excellent technique to create Business Process Diagrams (BPD). These diagrams display a step-by-step process for achieving a particular business goal or objective. BPM’s are often completed using the Unified Modeling Language (UML) based Business Process Modeling Notation (BPMN) depicting flow elements, swim lanes, and artifacts utilized and completed throughout the execution of the business process.

From these, a Business Reference Model (BRM) may be created. The BRM is one of the most important artifacts in establishing an Enterprise Architecture within an organization. The BRM concentrates on both the functional and organizational aspects of the business and helps establish the Business Architecture.

Having a clear understanding of the Business Goals and objectives is important to establishing an excellent Enterprise Architecture, and eventually aligning business goals with Information technology. The technology supporting the business is then defined in the Technical Reference Model (TRM), Application Architecture, and Data Architecture.

What are your first steps to establishing an Enterprise Architecture?

Agile and Associations

Agile and Associations

by | Feb 15, 2014 | Ascend Blog

Many key differences exist between organizations which fall under the category of a “Non-Profit” or Association, and a For-Profit corporation.

Many of these Associations exist to unite a key group of members or employees in a specific industrial or government sector. For instance, the National Association of Realtors (NAR) unites Realtors across the nation. One of the main purposes of NAR is to encourage and advance education on Real Estate for both Association Members (Realtors) and non-members alike. Like many associations, NAR exists to further the cause of a specific industrial group, Realtors, and benefit home owners through educational pieces. The Healthcare Information and Management Systems Society (HIMSS) is another example of an association or non-profit, furthering the education and promoting Health IT.

With this in mind, it is not possible to approach an association the same way to approaching a For-Profit corporation. They possess an absolutely different business model and often times contain a very different culture from corporations. If consulting with a Non-Profit or Association and implementing agile methodologies, it is important to take the following into consideration:

  1. Meet the IT Department: Many Associations use Information Technology (IT) in more of a support role and purchase many COTS products. IT”s job at times is to simply keep the lights on. It is important to meet with the IT Department and work closely with them. As an Agile Consultant, you are a teacher, and take the time to teach and introduce Agile to the group.
  2. Gauge the Acceptance of Change: Determine how accepting the IT Department, and the business line is accepting of change. Many associations may be slow to accept change. If an organization is not ready for Agile, but is willing to accept slow changes, it may be important to start with a waterfall process and slowly introduce new ideas. Iterative Waterfall, Iterative, to finally Agile.
  3.  Be a “Teacher” and Listen to Your Client: Associations are academic in nature, proposing new ideas in their line of work or certifications. When working with your client, be a teacher but also be a good listener. You need to understand their model and culture (which once again may be different from a typical corporate or Federal customer), and how to approach a problem.
  4. Take time to Work with the Business as Well: IT in many associations may be in more of a support or research role. Take time to also work with the business (those producing reports, content, marketing, or articles for the association). Determine what their pain points are in regards to technology and make note of them. Track your correspondence and information in a centralized tracker, matrix, or repository. This will help when speaking to IT and beginning to plan out changes to a widely used Corporate system

Developing this repertoire with both IT and the Business will increase your visibility in the association. While you are there to implement an “Agile” process, you will also begin bridging potential gaps between IT and Business, acting as an intermediary between the Technology and the Business needs. IT is about enabling and supporting Business goals, agile helps do it faster and better.

Be the Agile PM, but also be a teacher, leader, and intermediary and you can successfully establish an Agile Methodology in your association.

Is your association agile? What changes or technology pain points do you see which could be alleviated? 

Image Source: Dreamgrow.com