Jump to content

- - - - -

CAG Game-Dev Interest

game development indie hobby engine 3D 2D

#1 Richard Kain   The Kaiser CAGiversary!   2937 Posts   Joined 13.8 Years Ago  

Richard Kain

Posted 28 March 2017 - 05:41 PM

There's a thread for a similar subject in the PC forum, but I feel that this topic has become general enough to warrant inclusion in the general topic thread.

Game development is becoming an increasingly popular way to participate in gaming culture. Once restricted to those with the expertise and technical skill to hold a professional position, modern tools and technology have opened up this field for broader participation. Most significant to CAGs, the price-related barriers to entry have reduced considerably. These days there are many low or even no-cost options for the interested game-developer-to-be on a budget.

In this thread I would love to discuss the various options available, their strengths and weaknesses, and offer suggestions as to what solution is right for individuals interested in dappling in game development. This is a topic that I've been enthusiastic about for some time, and have managed to accrue some pretty extensive experience with over the years. With the dwindling costs of getting into this particular hobby, I think the community interest will also be increasing over time.

#2 Richard Kain   The Kaiser CAGiversary!   2937 Posts   Joined 13.8 Years Ago  

Richard Kain

Posted 28 March 2017 - 06:23 PM

For reference, here's a list of modern, supported game engines/frameworks/systems that anyone interested in game development would probably find useful.



Unreal Engine 4



GameMaker Studio 2  steam link

Godot  steam link

Visionaire Studio

Adventure Game Studio

RPG Maker  steam link

TyranoBuilder  steam link




Some of these are free to use, some of them are free to develop your own games with. Some of them are for-pay, and have different tiers of licensing. Some of them are actually available for download on Steam, and in those cases a steam link has been provided. All of them represent some fairly hefty potential tools for dipping your toe into game development.

#3 Richard Kain   The Kaiser CAGiversary!   2937 Posts   Joined 13.8 Years Ago  

Richard Kain

Posted 29 March 2017 - 05:46 PM

As an intellectual exercise, let's imagine a hypothetical user who has the least amount of money possible to invest in game development. We're not talking zero currency, but at most the current content of their wallet. We're going to assume that they are starting from square one, with virtually no resources, and yet they still want to wade into the world of developing some manner of game or digital entertainment.

For such a scenario, I would recommend starting off with Twine. Allow me to go into why.

For someone starting from nothing, we have to assume that they don't necessarily own a computer. A computer would normally be the pre-requisite for handling something like this, but not everyone can afford a PC. Yes, desktop PCs, laptops, and netbooks have all plummeted in price over the past decade. But they still aren't free, and even the cheapest of these will likely run you no less than $200. But personally owning a PC is not required, simply having access to a PC of one sort or another is enough. Many public libraries frequently have publicly available PCs, usually with some manner of internet connection. So access to a PC is possible without spending money, you simply have to assume that the PC is not going to be particularly powerful or advanced.

Twine works well with this sort of scenario. It is free, there is no paid licensing, and you are free to do whatever you please with the content you create. It is also web-based. Thanks to this, you aren't required to download and install software, you can simply run the web application right from the web-page. In the case of a PC you don't own, you might not have the privileges necessary to install software. Twine's web-option deftly side-steps this problem. You can download Twine if you want, to have a local copy, but it is not required to make use of it.

The one real monetary requirement for using Twine is storage. For a PC you don't own, you might not have the permissions necessary to download content to the hard drive. For a tool like Twine, the content you generate can be downloaded and saved locally, but you can't always depend on that ability for a publicly available PC. So the one thing you would have to buy in this scenario is some manner of external storage. Thankfully, the web/text based nature of Twine makes it quite minimal in terms of its data footprint, so the content you generate with it doesn't take up a lot of room. Your best bet would be acquiring a USB thumb-drive. Thankfully, these are fairly innexpensive these days, and you could easily make do with a smaller model. Currently, numerous 16-32 Gig thumb drives can be had for $10 or less. Any of those would give you more than enough space to download and store a local copy of Twine, and contain more content than you could generate with Twine.

There are a few other reasons for recommending Twine, but they don't relate to the financial cost, so I'll just save those for later.

#4 Richard Kain   The Kaiser CAGiversary!   2937 Posts   Joined 13.8 Years Ago  

Richard Kain

Posted 31 March 2017 - 07:01 PM

Today's appraisal is for Unity, one of the usual go-to engines for small-scale indies and hobbyist developers. It will also be a bit of a personal example. Unity is the engine that I've been focused on using for my own projects for the past few years.

Once upon a time, Unity was a lot less accessible, at least as far as financial investment was concerned. While it was always one of the cheaper middle-ware engines, it was still a for-pay license, usually on the order of several hundred dollars for a single seat. Four or five years ago, Unity announced an "indie" license for their engine that allowed a slightly stripped-down version to be used without any up-front cost. Developers interested in using Unity for their project could do so without paying, so long as any project made with it earned less than $100,000 USD annually. About a year and a half ago, Unity introduced version 5 of their engine, and with that reveal they also removed the feature limitations from the free license, allowing the indie crowd unrestricted access to all of the engine's bells and whistles. The lack of up-front costs has made Unity extremely popular with hobbyist developers and smaller to mid-scale indie developers. It is now one of the most broadly used middle-ware game engine solutions. Even larger developers/publishers will often turn to Unity when working on smaller-scale projects. (a modern example being Blizzard using Unity to develop Hearthstone)

From the beginning, one of Unity's biggest strengths was its broad support of numerous different platforms. It was originally designed to support Mono, a cross-platform port of the C# .NET framework. As far as modern object-oriented programming languages go, C# is fairly popular and easy to learn. The Mono framework first allowed C# to be implemented on multiple platforms. Unity took advantage of this to create an engine that could build executables for numerous different platforms with minimal changes to code and resources. When developing with Unity, you can usually port your game to any number of different platforms with very little extra effort. Modern Unity supports all three major PC operating systems, as well as both of the most standard mobile operating systems. It also enjoys broad support for the majority of major video game consoles. Using Unity for your development projects is a virtual guarantee that you will be able to distribute your project as extensively as possible with little to no effort.

#5 Richard Kain   The Kaiser CAGiversary!   2937 Posts   Joined 13.8 Years Ago  

Richard Kain

Posted 31 March 2017 - 07:01 PM

A particular feature that Unity is frequently praised for is its strength as a prototyping tool. This is a natural extension of Unity's underlying component structure. The way that Unity is structurally designed makes it very easy to cook up interactions quickly and efficiently. It is a very efficient tool for trying out different ideas and approaches without having to devote too much time to experimentation. Some studios will even use Unity for initial prototyping before porting their efforts over to another engine, simply because of the time they save.

This is where my personal story comes in. Yesterday, Thimbleweed Park was released. I've always been a massive fan of point-and-click adventure games, so the release of a title like this caused me to remember. A few years ago, I exprimented with creating a point-and-click adventure game with Adventure Game Studio. In particular, I experimented with using a 3D model as a basis for generating animated sprites. Animation is one of the biggest time-sinks in game development. 2D animation in particular can take a mind-numbing amount of time. I wanted to take a shortcut by creating and animating a 3D model, and then using that to generate a sprite sheet that I could use in the engine. (similar to how sprites where created for Donkey Kong Country)

My experiment was a success. I was able to create sprites that had far more detail and far more frames of animation than what had previously been possible. Most importantly, I was able to automatically render the sprites from multiple camera angles, which saved a huge amount of time. However, there were still some drawbacks to the approach, and while the sprites were more detailed, I didn't necessarily like the visual style that they presented.

When Thimbleweed Park came out, I saw the pixel-based sprites of the game, and thought back to the experiment that I had conducted. And I thought to myself, "with the tools I have available to me now, I bet I could come up with an even better solution." So I fired up Unity and took a crack at it.

Before Unity version 5 was released, some of the more advanced features of the engine were locked for the free version. But with version 5, all restrictions were lifted. One of those previously unavailable features was something called render textures. Render textures are very useful, and were most frequently used for certain special effects, most notably the implementation of mirrored surfaces, and in-game security camera footage. They basically let you take the output of a virtual camera, and stretch that rendered image across an object in the game. You are generally encouraged to use them sparingly. Since they require additional rendering to be performed, they can end up being a serious drain on a game's performance if you just throw them all over the place. But the drain they represent is directly proportional to the complexity of the scene you're rendering, and the size of the texture you are planning on rendering it to. If you can reduce either of those factors, you can reduce the cost of using render textures.

With access to this new and powerful tool, it occurred to me that I may be able to replicate my earlier sprite-rendering experiment, but this time I could do it in-game, and with much greater efficiency, and even a few extra features. The challenge I decided to set for myself was to simulate the style of classic 2D point-and-click adventure games, but do so with the efficiency of modern 3D modeling and animation. I wanted to create a quick prototype that would prove I could construct game assets in 3D, but render them in such a way that they would both look and move like classic 2D point-and-click sprites.

I began by cobbling together a basic human-style shape out of Unity cube objects that I scaled to roughly resember a standard human model. Then I stuffed them all under an empty game object so that I could treat them as a single unit. I created a new Layer, and assigned all of the cubes to this layer. Then I created a new camera, removed the audio listener component, and changed the rendering filter for the camera to only render objects assigned to my newly created layer. I created a render texture, set its resolution to roughly encompass the rendered shape of my human model, and set it as the render target for my new camera. Finally, I created a standard Quad object, and assigned the render texture to a material that I applied to the quad object.

This part of the experiment worked. The camera I created rendered the human-cubes to the render texture, which was in turn displayed on the 2D quad object. I was rendering a 3D object as a 2D sprite, and I was able to do it in real-time. Thanks to the display layer, I could insure that my render-camera wouldn't acknowledge anything else in the scene, only rendering the 3D "character." By adjusting the settings for the render texture, I could simulate the lower-resolution pixel-based style of older adventure titles.

But one problem still plagued me. If you moved the camera to a different angle, the render texture would be updated at the same rate that the game was running at. This would create much smoother animation than what was possbile in older games. (outside of a ridiculous budget) I needed a way to insure that rendered animation that went to the render texture could be throttled back to a more modest rate. Everything I had done up to this point was purely in the standard Unity visual interface. But there are no proper tools in Unity for this kind of specialized functionality. It was time for me to crack open the code editor.

I created a basic Unity script, and fired up Visual Studio. A quick trip to the Unity API documentation showed me everything I needed to know. In order to limit rendering for a render-texture, all you have to do is disable the camera that is doing the rendering, and then call that camera's render function manually. In the script's start function, I accessed the camera component, disabled it, and then called it's rendering function once. Then I defined a couple of variables for my script, including a float for my desired frame-rate, a float to keep track of time that has passed, and a boolean to determine whether or not I want the rendering to occur. In the scripts update function, I added a conditional to check if my rendering boolean was true, and then some conditionals to check if the current delta time added to the current elapsed time was greater than 1 divided by the desired framerate. If that condition was true, the elapsed variable would be reset to zero, and the camera's render function would be called.

When I dropped my newly created component script on the render camera, it worked like a charm. When I tested the scene the render camera would start off disabled, and would take a single snapshot of the human-cubes just to populate the render texture with something. If I switched on the rendering flag in the script, the render camera would start rendering again, but only at the rate I had set in the script. (which was now available for editing in the visual inspector) Not only could I render my sprites at lower framerates, but I could dynamically change those framerates at run-time. (just in case a particular effect or sequence called for it)

All of this took me less than two hours. And the coding for this feature was minimal, I barely had to dig into the more advanced implementations at all. This is one of the primary strengths of Unity. It allows you to cook up and test functionality very quickly.

#6 Sir_Fragalot   wants Startropics 3. CAGiversary!   8827 Posts   Joined 15.3 Years Ago  


Posted 02 April 2017 - 03:08 AM

Great series of posts. Something I would like to add to the conversation.


Something I noticed for me is I looked at a few engines over the past 12 months, and well while I don't want to list the strengths/weakness of each, I will say that before choosing an engine you need to think about yourself and your future. What I mean first think about what type of game you want to make. Then think about what games do I want to make after this, and is it important for me to be able to use the skills I leaned outside of game development.


The reasons I find that to be critical is I do non game related development in my day job. Now before ever anything related to game development, I was already fluent in a few programming languages so switching was not hard. With editors like Unity, your going to be learning on programming languages like C# which in all purposes you can take those skills and apply them to non gaming development work. If you just plan to have game development as your only ever programming experience then that's fine but it's something to think about when development market is growing. Some editors like Game Maker use their own language where you might learn a few concepts but no one else besides Game Maker will use that language. Others don't even use any programming or very little at all.


Second, it's important to choose an environment that will be open to the games you want to make. If you want to strictly do adventure games or 2D games, then you can pick a specific environment tailored to that, but if not look at something more open like a Unity. Your going to be day in and day out, learning the ins and out of the program. Trying to master it to be able to make something great. You don't want to get really good at an environment then all of a sudden decide oh I should be using another editor. It will be going backwards for a bit. I mean nothing wrong if you do that (especially for people who are experienced in game development), but for beginning, if you can stick with one environment, I find it to work better.


One final note. Remember that your game idea might be amazing, but put into perspective how big of scope your project may be. If you have this game with a big, vast world with lots of dungeons, great graphics, etc. You will probably need a team to accomplish this in a reasonable amount of time. You may need to start with something small to get your feet wet, learn how fast you work and go from there. Not to discourage anyone from learning game development, but game development is hard work. The payoff is great of course, but I can't stress how much effort can and will go into a good game.

#7 Richard Kain   The Kaiser CAGiversary!   2937 Posts   Joined 13.8 Years Ago  

Richard Kain

Posted 03 April 2017 - 05:52 PM

I appreciate the response, Sir_Fragalot. You make a lot of good points. In fact, any one of these points you bring up deserves it's own dedicated "wall-o-text" response.

For now, I'll address learning curves and the time investment they represent. Any game engine or framework you delve into is going to have it's own learning curve. None of them can be mastered in an afternoon. The more time you are able to commit to learning one of these systems will improve your work in that particular system. Ideally, you would choose one and stick with it indefinitely, eventually becoming a true master in that particular engine or framework.

But reality is rarely ever so kind. It's personal example time again. The first major game project I ever tackled was created using Actionscript 3, and made use of the Flixel engine. AS3 was the native programming language for Flash. You remember Flash? It used to be huge, and was the go-to solution for on-line animation and video. At the time, Flash was considered the de-facto solution for creating a web game that could run in a browser. I actually created my game as part of an on-line contest/competition, and using Flash was one of the requirements. I had learned AS3 at a previous job, so I had a decent familiarity and didn't have to start from scratch.

However, in the intervening time, Flash crashed and burned. I won't go into the details, you could write a whole novel about the rise and fall of Flash. The point is that I invested a certain amount of time and effort at becoming exceptionally proficient in Flash, but then that technology went away. While I was able to learn several non-Flash-specific skills that I could transfer to other disciplines, there was also a lot of Flash-specialized knowledge and experience that I picked up that is now useless. At least a portion of that time investment was negated, through no fault of my own.

These are the sorts of things you need to consider when considering what you should be learning. It applies to most technology-related fields, and is a constant considertation that developers have to weigh. If you start trying to learn a particular engine, how long will that engine be viable? Will it continue to be supported years from now? Will it even be available for the next version of your computer's operating system? Companies come and go, for all we know the engine you settle on might get abandoned just a year or two from now.

If you aren't attempting to develop games professionally, it isn't quite as extreme of a decision to make, but it is still worth considering. Any of these engines and/or frameworks takes time to learn and master, and even someone who is just pursuing this sort of thing for fun would want their tools of choice to still be viable for as long as possible.

This thread isn't getting a lot of feedback just yet. If the community interest in this subject is a bit more limited, I will consider shifting this content over to a personal blog instead of a community discussion. It might be a more appropriate format for this kind of output. I have plans to add all of this to an external website with more in-depth tutorials as well as some multi-media content mixed in. (possibly some video tutorials, and definitely some sketches to go along with text tutorials) I just haven't had time to flesh that sort of thing out. I've been doing some spring cleaning, and it is eating up most of my free-time.

#8 nitrosmob   CAGiversary! CAGiversary!   10510 Posts   Joined 14.8 Years Ago  

Posted 22 April 2017 - 12:42 AM

Honestly just haven't gotten into game development. I do like to learn languages and create my own projects for them for fun. It's all just to keep my knowledge going on them. Game development sounds interesting for sure though.

Also tagged with one or more of these keywords: game, development, indie, hobby, engine, 3D, 2D