• Breaking News

    Wednesday, February 28, 2018

    Home Unlabelled Programming lessons learned from making my first game and why I'm writing my own engine in 2018

    Programming lessons learned from making my first game and why I'm writing my own engine in 2018

    February 28, 2018

    Programming lessons learned from making my first game and why I'm writing my own engine in 2018

    Programming lessons learned from making my first game and why I'm writing my own engine in 2018

    Posted: 28 Feb 2018 05:47 AM PST

    You can see the full blog post with proper links and formatting here https://github.com/SSYGEN/blog/issues/31

    I just released my first game, BYTEPATH, and I thought it would be useful to write down my thoughts on what I learned from making it. I'll divide these lessons into soft and hard: soft meaning more software engineering related ideas and guidelines, hard meaning more technical programming stuff. And then I'll also talk about why I'm gonna write my own engine.

    Soft Lessons

    For context, I've been trying to make my own games for about 5-6 years now and I have 3 "serious" projects that I worked on before this one. Two of those projects are dead and failed completely, and the last one I put on hold temporarily to work on this game instead. Here are some gifs of those projects:

    https://i.imgur.com/dcjo640.gif

    https://i.imgur.com/1UGfm9J.gif

    https://i.imgur.com/Kn2LSAH.gif

    The first two projects failed for various reasons, but in the context of programming they ultimately failed (at least from my perspective) because I tried to be too clever too many times and prematurely generalized things way too much. Most of the soft lessons I've learned have to do with this, so it's important to set this context correctly first.

    Premature Generalization

    By far the most important lesson I took out of this game is that whenever there's behavior that needs to be repeated around to multiple types of entities, it's better to default to copypasting it than to abstracting/generalizing it too early.

    This is a very very hard thing to do in practice. As programmers we're sort of wired to see repetition and want to get rid of it as fast as possible, but I've found that that impulse generally creates more problems than it solves. The main problem it creates is that early generalizations are often wrong, and when a generalization is wrong it ossifies the structure of the code around it in a way that is harder to fix and change than if it wasn't there in the first place.

    Consider the example of an entity that does ABC. At first you just code ABC directly in the entity because there's no reason to do otherwise. But then comes around another type of entity that does ABD. At this point you look at everything and say "let's take AB out of these two entities and then each one will only handle C and D by itself", which is a logical thing to say, since you abstract out AB and you start reusing it everywhere else. As long as the next entities that come along use AB in the way that it is defined this isn't a problem. So you can have ABE, ABF, and so on...

    https://i.imgur.com/D5VHZgl.png

    But eventually (and generally this happens sooner rather than later) there will come an entity that wants AB*, which is almost exactly like AB, but with a small and incompatible difference. Here you can either modify AB to accommodate for AB*, or you can create a new thing entirely that will contain the AB* behavior. If we repeat this exercise multiple times, in the first option we end up with an AB that is very complex and has all sorts of switches and flags for its different behaviors, and if we go for the second option then we're back to square one, since all the slightly different versions of AB will still have tons of repeated code among each other.

    https://i.imgur.com/UupZYZR.png

    At the core of this problem is the fact that each time we add something new or we change how something behaves, we now have to do these things AGAINST the existing structures. To add or change something we have to always "does it go in AB or AB*?", and this question which seems simple, is the source of all issues. This is because we're trying to fit something into an existing structure, rather than just adding it and making it work. I can't overstate how big of a difference it is to just do the thing you wanna do vs. having to get it to play along with the current code.

    So the realization I've had is that it's much easier to, at first, default to copypasting code around. In the example above, we have ABC, and to add ABD we just copypaste ABC and remove the C part to do D instead. The same applies to ABE and ABF, and then when we want to add AB*, we just copypaste AB again and change it to do AB* instead. Whenever we add something new in this setup all we have to do is copy code from somewhere that does the thing already and change it, without worrying about how it fits in with the existing code. This turned out to be, in general, a much better way of doing things that lead to less problems, however unintuitive it might sound.

    https://i.imgur.com/5F8A2Sb.png

    Most advice is bad for solo developers

    There's a context mismatch between most programming advice I read on the Internet vs. what I actually have learned is the better thing to do as a solo developer. The reason for this is two fold: firstly, most programmers are working in a team environment with other people, and so the general advice that people give each other has that assumption baked in it; secondly, most software that people are building needs to live for a very long time, but this isn't the case for an indie game. This means that most programming advice is very useless for the domain of solo indie game development and that I can do lots of things that other people can't because of this.

    For instance, I can use globals because a lot of the times they're useful and as long as I can keep them straight in my head they don't become a problem (more about this in article #24 of the BYTEPATH tutorial). I can also not comment my code that much because I can keep most of it in my head, since it's not that large of a codebase. I can have build scripts that will only work on my machine, because no one else needs to build the game, which means that the complexity of this step can be greatly diminished and I don't have to use special tools to do the job. I can have functions that are huge and I can have classes that are huge, since I built them from scratch and I know exactly how they work the fact that they're huge monsters isn't really a problem. And I can do all those things because, as it turns out, most of the problems associated with them will only manifest themselves on team environments or on software that needs to live for long.

    So one thing I learned from this project is that nothing went terribly wrong when I did all those "wrong" things. In the back of my head I always had the notion that you didn't really need super good code to make indie games, given the fact that so many developers have made great games that had extremely poor code practices in them, like this:

    https://i.imgur.com/Eo8cK0k.png

    And so this project only served to further verify this notion for me. Note that this doesn't mean that you should go out of your way to write trash code, but that instead, in the context of indie game development, it's probably useful to fight that impulse that most programmers have, that sort of autistic need to make everything right and tidy, because it's an enemy that goes against just getting things done in a timely manner.

    ECS

    Entity Component Systems are a good real world example that go against everything I just mentioned in the previous two sections. The way indie developers talk about them, if you read most articles, usually starts by saying how inheritance sucks, and how we can use components to build out entities like legos, and how that totally makes reusable behavior a lot easier to reuse and how it makes literally everything about your game easier.

    By definition this view that people push forward of ECS is talking about premature generalization, since if you're looking at things like legos and how they can come together to create new things, you're thinking in terms of reusable pieces that should be put together in some useful way. And for all the reasons I mentioned in the premature generalization section I deeply think that this is VERY WRONG!!!!!!!! This very scientific graph I drew explains my position on this appropriately:

    https://i.imgur.com/RA7XRUC.png

    As you can see, what I'm defending, "yolo coding", starts out easier and progressively gets harder, because as the complexity of the project increases the yolo techniques start showing their problems. ECS on the other hand has a harder start because you have to start building out reusable components, and that by definition is harder than just building out things that just work. But as time goes on the usefulness of ECS starts showing itself more and eventually it beats out yolo coding. My main notion on this is that in the context of MOST indie games, the point where ECS becomes a better investment is never reached.

    Does this mean I think anyone who uses ECS is stupid and dumb? No 🙂 I think that if you're used to using ECS already and it works for you then it's a no-brainer to keep using it. But I do think that indie developers in general should think more critically about these solutions and what their drawbacks are. I feel like this point made by Jonathan Blow is very relevant (in no way do I think he agrees with my points on ECS or I am saying or implying that he does, though):

    https://www.youtube.com/watch?v=21JlBOxgGwY#t=6m52s

    Avoiding separating behavior into multiple objects

    One of the patterns that I can't seem to break out of is the one of splitting what is a single behavior into multiple objects. In BYTEPATH this manifested itself mostly in how I built the "Console" part of the game, but in Frogfaller (the game I was making before this one) this is more visible in this way:

    https://github.com/SSYGEN/blog/raw/master/images/ezgif-5-7432ab8106.gif

    This object is made up of the main jellyfish body, each jellyfish leg part, and then a logical object that ties everything together and coordinates the body's and the leg's behaviors. This is a very very awkward way of coding this entity because the behavior is split between 3 different types of objects and coordination becomes really hard, but whenever I have to code an entity like this (and there are plenty of multi-body entities in this game), I naturally default to doing it this way.

    One of the reasons I naturally default to separating things like this is because each physics object feels like it should be contained in a single object in code, which means that whenever I need to create a new physics object, I also need to create a new object instance. There isn't really a hard rule or limitation that this 100% has to be this way, but it's just something that feels very comfortable to do because of the way I've architectured my physics API.

    I actually have thought for a long time on how I could solve this problem but I could never reach a good solution. Just coding everything in the same object feels awkward because you have to do a lot of coordination between different physics objects, but separating the physics objects into proper objects and then coordinating between them with a logical one also feels awkward and wrong. I don't know how other people solve this problem, so any tips are welcome!!

    Hard Lessons

    The context for these is that I made my game in Lua using LÖVE. I wrote 0 code in C or C++ and everything in Lua. So a lot of these lessons have to do with Lua itself, although most of them are globally applicable.

    nil

    90% of the bugs in my game that came back from players had to do with access to nil variables. I didn't keep numbers on which types of access were more/less common, but most of the time they have to do with objects dying, another object holding a reference to the object that died and then trying to do something with it. I guess this would fall into a "lifetime" issue.

    Solving this problem on each instance it happens is generally very easy, all you have to do is check if the object exists and continue to do the thing:

    if self.other_object then doThing(self.other_object) end

    However, the problem is that coding this way everywhere I reference another object is way overly defensive, and since Lua is an interpreted language, on uncommon code paths bugs like these will just happen. But I can't think of any other way to solve this problem, and given that it's a huge source of bugs it seems to be worth it to have a strategy for handling this properly.

    So what I'm thinking of doing in the future is to never directly reference objects between each other, but to only reference them by their ids instead. In this situation, whenever I want to do something with another object I'll have to first get it by its id, and then do something with it:

    local other_object = getObjectByID(self.other_id) if other_object then doThing(other_object) end

    The benefit of this is that it forces me to fetch the object any time I want to do anything with it. Combined with me not doing anything like this ever:

    self.other_object = getObjectByID(self.other_id)

    It means that I'll never hold a permanent reference to another object in the current one, which means that no mistakes can happen from the other object dying. This doesn't seem like a super desirable solution to me because it adds a ton of overhead any time I want to do something. Languages like MoonScript help a little with this since there you can do this:

    if object = getObjectByID(self.other_id) doThing(object)

    But since I'm not gonna use MoonScript I guess I'll just have to deal with it :rage:

    More control over memory allocations

    While saying that garbage collection is bad is an inflammatory statement, especially considering that I'll keep using Lua for my next games, I really really dislike some aspects of it. In a language like C whenever you have a leak it's annoying but you can generally tell what's happening with some precision. In a language like Lua, however, the GC feels like a blackbox. You can sort of peek into it to get some ideas of what's going on but it's really not an ideal way of going about things. So whenever you have a leak in Lua it's a way bigger pain to deal with than in C. This is compounded by the fact that I'm using a C++ codebase that I don't own, which is LÖVE's codebase. I don't know how they set up memory allocations on their end so this makes it a lot harder for me to have predictable memory behavior on the Lua end of things.

    It's worth noting that I have no problems with Lua's GC in terms of its speed. You can control it to behave under certain constraints (like, don't run for over n ms) very easily so this isn't a problem. It's only a problem if you tell it to not run for more than n ms, but it can't collect as much garbage as you're generating per frame, which is why having the most control over how much memory is being allocated is desirable. There's a very nice article on this here http://bitsquid.blogspot.com.br/2011/08/fixing-memory-issues-in-lua.html and I'll go into more details on this on the engine part of this article.

    Timers, Input and Camera

    These are 3 areas in which I'm really happy with how my solutions turned out. I wrote 3 libraries for those general tasks:

    And all of them have APIs that feel really intuitive to me and that really make my life a lot easier. The one that's by far the most useful is the Timer one, since it let's me to all sorts of things in an easy way, for instance:

    timer:after(2, function() self.dead = true end)

    This will kill the current object (self) after 2 seconds. The library also lets me tween stuff really easily:

    timer:tween(2, self, {alpha = 0}, 'in-out-cubic', function() self.dead = true end)

    This will tween the object's alpha attribute to 0 over 2 seconds using the in-out-cubic tween mode, and then kill the object. This can create the effect of something fading out and disappearing. It can also be used to make things blink when they get hit, for instance:

    timer:every(0.05, function() self.visible = not self.visible, 10)

    This will change self.visible between true and false every 0.05 seconds for a number of 10 times. Which means that this creates a blinking effect for 0.5 seconds. Anyway, as you can see, the uses are limitless and made possible because of the way Lua works with its anonymous functions.

    The other libraries have similarly trivial APIs that are very powerful and useful. The camera one is the only one that is a bit too low level and that can be improved substantially in the future. The idea with it was to create something that enabled what can be seen in this video:

    https://www.youtube.com/watch?v=aAKwZt3aXQM

    But in the end I created a sort of middle layer between having the very basics of a camera module and what can be seen in the video. Because I wanted the library to be used by people using LÖVE, I had to make less assumptions about what kinds of attributes the objects that are being followed and/or approached would have, which means that it's impossible to add some of the features seen in the video. In the future when I make my own engine I can assume anything I want about my game objects, which means that I can implement a proper version of this library that achieves everything that can be seen in that video!

    Rooms and Areas

    A way to manage objects that really worked out for me is the notion of Rooms and Areas. Rooms are equivalent to a "level" or a "scene", they're where everything happens and you can have multiple of them and switch between them. An Area is a game object manager type of object that can go inside Rooms. These Area objects are also called "spaces" by some people. The way an Area and a Room works is something like this (the real version of those classes would have way more functions, like the Area would have addGameObject, queryGameObjectsInCircle, etc):

    Area = Class() function Area:new() self.game_objects = {} end function Area:update(dt) -- update all game objects end Room = Class() function Room:new() self.area = Area() end function Room:update(dt) self.area:update(dt) end

    The benefits of having this difference between both ideas is that rooms don't necessarily need to have Areas, which means that the way in which objects are managed inside a Room isn't fixed. For one Room I can just decide that I want the objects in it to be handled in some other way and then I'm able to just code that directly instead of trying to bend my Area code to do this new thing instead.

    One of the disadvantages of doing this, however, is that it's easy to mix local object management logic with the object management logic of an Area, having a room that has both. This gets really confusing really easily and was a big source of bugs in the development of BYTEPATH. So in the future one thing that I'll try to enforce is that a Room should either use an Area or it's own object management routines, but never both at the same time.

    snake_case over camelCase

    Right now I use snake_case for variable names and camelCase for function names. In the future I'll change to snake_case everywhere except for class/module names, which will still be in CamelCase. The reason for this is very simple: it's very hard to read long function names in camelCase. The possible confusion between variables and function names if everything is in snake_case is generally not a problem because of the context around the name, so it's all okay 🤗

    Engine

    The main reason why I'll write my own engine this year after finishing this game has to do with control. LÖVE is a great framework but it's rough around the edges when it comes to releasing a game. Things like Steamworks support, HTTPS support, trying out a different physics engine like Chipmunk, C/C++ library usage, packaging your game up for distribution on Linux, and a bunch of other stuff that I'll mention soon are all harder than they should be.

    They're certainly not impossible, but they're possible if I'm willing to go down to the C/C++ level of things and do some work there. I'm a C programmer by default so I have no issue with doing that, but the reason why I started using the framework initially was to just use Lua and not have to worry about that, so it kind of defeats the purpose. And so if I'm going to have to handle things at a lower level no matter what then I'd rather own that part of the codebase by building it myself.

    However, I'd like to make a more general point about engines here and for that I have to switch to trashing on Unity instead of LÖVE. There's a game that I really enjoyed playing for a while called Throne of Lies:

    https://i.imgur.com/AZhLj4g.jpg

    It's a mafia clone and it had (probably still has) a very healthy and good community. I found out about it from a streamer I watch and so there were a lot of like-minded people in the game which was very fun. Overall I had a super positive experience with it. So one day I found a postmortem of the game on /r/gamedev by one of the developers of the game. This guy happened to be one of the programmers and he wrote one comment that caught my attention:

    https://i.imgur.com/UuASK7w.png

    So here is a guy who made a game I really had a good time with saying all these horrible things about Unity, how it's all very unstable, and how they chase new features and never finish anything properly, and on and on. I was kinda surprised that someone disliked Unity so much to write this so I decided to soft stalk him a little to see what else he said about Unity:

    https://i.imgur.com/JkcZ8H2.png

    And then he also said this: 😱

    https://i.imgur.com/zorNJMh.png

    And also this: 😱 😱

    https://i.imgur.com/peB5QjL.png

    And you know, I've never used Unity so I don't know if all he's saying is true, but he has finished a game with it and I don't see why he would lie. His argument on all those posts is pretty much the same too: Unity focuses on adding new features instead of polishing existing ones and Unity has trouble with keeping a number of their existing features stable across versions.

    Out of all those posts the most compelling argument that he makes, in my view, which is also an argument that applies to other engines and not just Unity, is that the developers of the engine don't make games themselves with it. One big thing that I've noticed with LÖVE at least, is that a lot of the problems it has would be solved if the developers were actively making indie games with it. Because if they were doing that those problems would be obvious to them and so they'd be super high priority and would be fixed very quickly. xblade724 has found the same is true about Unity. And many other people I know have found this to be true of other engines they use as well.

    There are very very few frameworks/engines out there where its developers actively make games with it. The ones I can think off the top of my head are: Unreal, since Epic has tons of super successful games they make with their engine, the latest one being Fortnite; Monogame, since the main developer seems to port games to various platforms using it; and GameMaker, since YoYo Games seems to make their own mobile games with their engine.

    Out of all the other engines I know this doesn't hold, which means that all those other engines out there have very obvious problems and hurdles to actually finishing games with it that are unlikely to get fixed at all. Because there's no incentive, right? If some kinds of problems only affect 5% of your users because they only happen at the end of the development cycle of a game, why would you fix them at all unless you're making games with your own engine and having to go through those problems yourself?

    And all this means is that if I'm interested in making games in a robust and proven way and not encountering tons of unexpected problems when I get closer to finishing my game, I don't want to use an engine that will make my life harder, and so I don't want to use any engine other than one of those 3 above. For my particular case Unreal doesn't work because I'm mainly interested in 2D games and Unreal is too much for those, Monogame doesn't work because I hate C#, and GameMaker doesn't work because I don't like the idea visual coding or interface-based coding. Which leaves me with the option to make my own. 🙂

    So with all that reasoning out of the way, let's get down to the specifics:

    C/Lua interfacing and memory

    C/Lua binding can happen in 2 fundamental ways (at least from my limited experience with it so far): with full userdata and with light userdata. With full userdata the approach is that whenever Lua code asks for something to be allocated in C, like say, a physics object, you create a reference to that object in Lua and use that instead. In this way you can create a full object with metatables and all sorts of goodies that represents the C object faithfully. One of the problems with this is that it creates a lot of garbage on the Lua side of things, and as I mentioned in an earlier section, I want to avoid memory allocations as much as possible, or at least I want to have full control over when it happens.

    So the approach that seems to make the most sense here is to use light userdata. Light userdata is just a a normal C pointer. This means that we can't have much information about the object we're pointing to, but it's the option that provides the most control over things on the Lua side of things. In this setup creating and destroying objects has to be done manually and things don't magically get collected, which is exactly what I need. There's a very nice talk on this entire subject by the guy who made the Stingray Engine here:

    https://www.youtube.com/watch?v=wTjyM7d7_YA&t=18m32s

    You can also see how some of what he's talking about happens in his engine in the documentation.

    The point of writing my own engine when it comes to this is that I get full control over how C/Lua binding happens and what the tradeoffs that have to happen will be. If I'm using someone else's Lua engine they've made those choices for me and they might have been choices that I'm not entirely happy with, such as is the case with LÖVE. So this is the main way in which I can gain more control over memory and have more performant and robust games.

    External integrations

    Things like Steamworks, Twitch, Discord and other sites all have their own APIs that you need to integrate against if you want to do cool things and not owning the C/C++ codebase makes this harder. It's not impossible to do the work necessary to get these integrations working with LÖVE, for instance, but it's more work than I'm willing to do and if I'll have to do it anyway I might as well just do it for my own engine.

    If you're using engines like Unity or Unreal which are extremely popular and which already have integrations for most of these services done by other people then this isn't an issue, but if you're using any engine that has a smaller userbase than those two you're probably either having to integrate these things on your own, or you're using someone's half implemented code that barely works, which isn't a good solution.

    So again, owning the C/C++ part of the codebase makes these sorts of integrations a lot easier to deal with, since you can just implement what you'll need and it will work for sure.

    Other platforms

    This is one of the few advantages that I see in engines like Unity or Unreal over writing my own: they support every platform available. I don't know if that support is solid at all, but the fact that they do it is pretty impressive and it's something that it's hard for someone to do alone. While I'm not a super-nerdlord who lives and breathes assembly, I don't think I would have tons of issues with porting my future engine to consoles or other platforms, but it's not something that I can recommend to just anyone because it's likely a lot of busywork.

    https://salenauts.com/files/news/main/727x324-deals/B/bloon-td-5.png

    One of the platforms that I really want to support from the get-go is the web. I've played a game once called Bloons TD5 in the browser and after playing for a while the game asked me to go buy it on Steam for $10. And I did. So I think supporting a version of your game on the browser with less features and then asking people to get it on Steam is a very good strategy that I want to be able to do as well. And from my preliminary investigations into what is needed to make an engine in C, SDL seems to work fine with Emscripten and I can draw something on the screen of a browser, so this seems good.

    Replays, trailers

    Making the trailer for this game was a very very bad experience. I didn't like it at all. I'm very good at thinking up movies/trailers/stories in my head (for some reason I do it all the time when listening to music) and so I had a very good idea of the trailer I wanted to make for this game. But that was totally not the result I got because I didn't know how to use the tools I needed to use enough (like the video editor) and I didn't have as much control over footage capturing as I wanted to have.

    https://www.youtube.com/watch?v=vRC1F1BSW7E

    One of the things I'm hoping to do with my engine is to have a replay system and a trailer system built into it. The replay system will enable me to collect gameplay clips more easily because I won't need to use an external program to record gameplay. I think I can also make it so that gameplay is recorded at all times during development, and then I can programmatically go over all replays and look for certain events or sequence of events to use in the trailer. If I manage to do this then the process of getting the footage I want will become a lot easier.

    Additionally, once I have this replay system I can also have a trailer system built into the engine that will enable me to piece different parts of different replays together. I don't see any technical reason on why this shouldn't work so it really is just a matter of building it.

    And the reason why I need to write an engine is that to build a replay system like I 100% need to work at the byte level, since much of making replays work in a manageable way is making them take less space. I already built a replay system in Lua in this article #8, but a mere 10 seconds of recording resulted in a 10MB file. There are more optimizations available that I could have done but at the end of the day Lua has its limits and its much easier to optimize stuff like this in C.

    Design coherence

    Finally, the last reason why I want to build my own engine is design coherence. One of the things that I love/hate about LÖVE, Lua, and I'd also say that of the Linux philosophy as well is how decentralized it is. With Lua and LÖVE there are no real standard way of doing things, people just do them in the way that they see fit, and if you want to build a library that other people want to use you can't assume much. All the libraries I built for LÖVE (you can see this in my repository) follow this idea because otherwise no one would use them.

    The benefits of this decentralization is that I can easily take someone's library, use it in my game, change it to suit my needs and generally it will work out. The drawbacks of this decentralization is that the amount of time that each library can save me is lower compared to if things were more centralized around some set of standards. I already mentioned on example of this with my camera library in a previous section. This goes against just getting things done in a timely manner.

    So one of the things that I'm really looking forward to with my engine is just being able to centralize everything exactly around how I want it to be and being able to make lots of assumptions about things, which will be refreshing change of pace (and hopefully a big boost in productivity)!

    Anyway, I rambled a lot in this article but I hope it was useful. 🙂

    submitted by /u/adnzzzzZ
    [link] [comments]

    Meta Game Jam (March 17-31) - create a game that deconstructs/parodies/satires games/game culture, or breaks the fourth wall!

    Posted: 28 Feb 2018 03:42 AM PST

    Hi fellow gamedevs!

    I'm hosting the Meta Game Jam (https://itch.io/jam/metagamejam) from March 17-31, where participants spend two weeks creating 'metagames', which are games about games and/or games that break the fourth wall.

    Some examples of metagames include The Stanley Parable, Frog Fractions, DLC Quest, Desert Bus, Pony Island and Game Dev Story.

    There'll be ~$100 in game prizes, and a long list of YouTubers/streamers lined up to play your entries and give feedback. All skill levels and disciplines (art, music, code, design) are welcome.

    If this sounds like your kind of thing, you can join the event here!

    You can also stay updated via our Twitter!

    Hope to see you there :)

    submitted by /u/XAVIER_INDIE_GAMEDEV
    [link] [comments]

    Thanks to you, i could drastically improve my scene!

    Posted: 28 Feb 2018 02:03 AM PST

    Level Design of Celeste: Redefining Platformer

    Posted: 28 Feb 2018 08:08 AM PST

    How Stardock's Elemental: War of Magic Failed - Brad Wardell details the difficulties in development that led to a disappointing product - Transparent look at game design

    Posted: 28 Feb 2018 09:27 AM PST

    How do Steam refunds work as an independent developer?

    Posted: 28 Feb 2018 08:17 AM PST

    With the current policy essentially allowing a refund at any time within reason, in theory you could have a sale refunded weeks down the line, what happens? If you spent that sale money do you then have to pay it out of your own pocket?

    I'd be wary of spending my hard earned money if it might have to be sent back at a moments notice. I'm sure it can't work like this, any game devs have experience with the system?

    submitted by /u/wonderthat
    [link] [comments]

    WIP Wednesday #86 - Boop

    Posted: 28 Feb 2018 06:55 AM PST

    What is WIP Wednesday?

    Share your work-in-progress (WIP) prototype, feature, art, model or work-in-progress game here and get early feedback from, and give early feedback to, other game developers.

    RULES

    • Do promote good feedback and interesting posts, and upvote those who posted it! Also, don't forget to thank the people who took some of their time to write some feedback or encouraging words for you, even if you don't agree with what they said.

    • Do state what kind of feedback you want. We realise this may be hard, but please be as specific as possible so we can help each other best.

    • Do leave feedback to at least 2 other posts. It should be common courtesy, but just for the record: If you post your work and want feedback, give feedback to other people as well.

    • Do NOT post your completed work. This is for work-in-progress only, we want to support each other in early phases (It doesn't have to be pretty!).

    • Do NOT try to promote your game to game devs here, we are not your audience. You may include links to your game's website, social media or devblog for those who are interested, but don't push it; this is not for marketing purposes.

    Remember to use #WIPWednesday on social media for additional feedback and exposure!

    Note: Using url shorteners is discouraged as it may get you caught by Reddit's spam filter.

    All Previous WIP Wednesdays

    submitted by /u/MEX_XIII
    [link] [comments]

    Looking for 3D game idea that can be implemented in Unity in 1-3 months (prototype)

    Posted: 28 Feb 2018 05:38 AM PST

    Hi, I have a Game Dev course in university during which I need to create a game in Unity.

    I have programming/software development experience. Also some basic computer graphics experience, for example this Three.js scene https://github.com/AlexP11223/Three.js_GuardedCastle

    The only problem is that I don't have any interesting idea for the game or even genre in mind :) (I think First Person Something would be interesting, but I am afraid that it could be too complex)

    I tried googling for the first game ideas, but found mostly too simple ones like Pong, Tetris. Some people suggest cloning a game that you like, but I mostly played AAA games before, so inspiring from them is probably not the best idea for the first game.

    Maybe someone can share an interesting idea for a 3D single-player game that can be implemented in 1-3 months part-time work (at least a prototype / partially)?

    submitted by /u/AlexP11223
    [link] [comments]

    Unexplained methods in book "Programming Game AI by Example"

    Posted: 28 Feb 2018 07:43 AM PST

    Is it just me or are there many methods that are given in code examples not shown. For example the method "PointToWorldSpace" in chapter 3 for the wander behaviour or the "LineIntersection2D" for the wall avoidance behaviour. I do have a general idea of what they are supposed to do, but I'd still like to see what he does within those actual methods.

    submitted by /u/Raynlaze
    [link] [comments]

    Question about existence of character model in single-player game with fully FPS perspective.

    Posted: 28 Feb 2018 07:02 AM PST

    I actually posed this question on Ask Reddit, but didn't get any information: https://www.reddit.com/r/AskReddit/comments/80w800/seriousgame_devs_standard_single_player_game/

     

    It's about whether or not there is a character model in a single player game that is played fully in first person. Like, obviously, in multi-player games, you have a character model that other players can see. But in a single player, game this doesn't seem to be the case as far as I can tell. However, many random users and trolls are proclaiming otherwise. Thus, I was seeking professional assistance about this.

    Such as Kingdom Come Deliverance on Cry Engine 4. You can move your camera, and see your body, feet, etc. But you can never zoom out to see your entire character in a third person view.

    Tons and tons of people are saying there is a character model there. You just can't see it because you're stuck zoomed into first person. Thus, if you had the option to zoom out into third person, you would see your character. Because there is an actual character model there.

    Or is there just no character model? So you can imagine a camera for your head with a dummy body attached to it. And this is all that exist. Thus, no actual existence of a character model in the game.

    Which is it?

    submitted by /u/sCoOurDcEe
    [link] [comments]

    JavaScript with Pixi.js or Lua with Love2D?

    Posted: 28 Feb 2018 10:22 AM PST

    I'm a single developer looking to build a simple 2D platform fighter similar to Rivals of Aether. I know javascript quite well, and have already used Pixi.JS to build an arcade rhythm game.

    In the past, before I knew as much as I do now, I decided to start off with Javascript, and eventually, for a bigger project, transfer to Lua and use Love2D. However now, I'm seeing Javascript age quite nicely and get tons of support, and am wondering if I'm better off sticking with it? Can Lua & Love2D provide me with a relevant bonus that I'm not aware of?

    Does anyone have recommendations on which I should use or which they find to be better?

    submitted by /u/forleafe
    [link] [comments]

    "GIAW - Game In A Week" game jam starting soon!

    Posted: 28 Feb 2018 07:27 AM PST

    I would love to stream game creation as a fully fledged indie company some day.

    Posted: 28 Feb 2018 07:04 AM PST

    Hey, devs! I had the idea of a type of job to pursue out of college (currently a freshman studying Game Art and Animation). I want to create a live stream in which I go on along with other people in the team to create the game and most of the assets on stream for people to give ideas to. The result would be a game made by the collective thoughts of an Indie game company and the twitch viewership.

    Right now since I do not have a company, I hope to stream my 3D modeling in order to create fun or challenging creations for stream based on their suggestions. I can not seem to get anybody on so I was hoping that if you guys supported my idea, you could spread the word and help me make this idea a reality!

    My twitch is mighty_se7en if you are interested at all. Thank you guys for reading what I have to say, feel free to say whatever you want in the comments, I'm here to take criticism and improve, not to die out from giving up.

    submitted by /u/Cambodude7
    [link] [comments]

    Feeling a little overwhelmed

    Posted: 28 Feb 2018 09:15 AM PST

    I'm working on a 2D RPG after making a handful of small games. I'm building one chunk at a time. I've been at it since last November, and currently have implemented:

    A* pathfinding/movement, attacking, animated equipment (helmet,legs,torso,boots,main and offhand), inventory/equip system with UI, dialogue, basic stats, basic AI and a handful of other little features.

    My goal is to create a small example of what the game is going to be...a small slice of a town with NPCs and a shop, a forest outside of the town with baddies it, and maybe a cave with stronger baddies.

    It's been going fairly well but I feel so naive sometimes. I try to adhere to the principles of good OOP, but I can't help but feel like I'm going to get to the end and realize I've been doing it all wrong somehow.

    As I write this out I find it hard to describe what I'm feeling, but I guess what I'd like to ask is if there is anything I should be watching out for as I work my way towards my goal? Any red-flags that might tell me:

    "hey this system you have works ok now but it's going to screw you over down the line"

    submitted by /u/maryjellybelly
    [link] [comments]

    So what is a scene graph?

    Posted: 28 Feb 2018 09:01 AM PST

    As I understand it, a scene graph is pretty small and simple concept which boils down to the following tree structure:

    class SceneNodeTransform { x, y, z: float; rotX, rotY, rotZ: float; scaleX, scaleY, scaleZ: float; parent: SceneNodeTransform; }

    It may be implemented with a matrix, have some utility methods, dirty flags and other means of smart updating, but conceptually it just remains a representation of a game object's transform relative to its parent object.

    But when I look at "scene graph" libraries, such as OpenSceneGraph or some lesser known ones, I see concepts related to

    • Lighting
    • Textures
    • Geometry

    I don't understand this. Is scene graph a lighting system? Is it a collision detection system? A space partitioning system? I thought it was just, well, a graph (or a tree, to be more specific).

    Are scene graphs reusable between rendering environments, or are they tied to APIs like OpenGL?

    Could someone please clarify what is usually meant by "scene graph" and how far off my understanding is?

    Thanks!

    submitted by /u/smthamazing
    [link] [comments]

    Is there a way to recover lost source code from an old console game?

    Posted: 27 Feb 2018 09:38 PM PST

    Forgive me if this is a stupid question I am not a game developer. I just heard it was impossible to release a remastered version of one of my favorite old school video games because Sega lost the source code for it. Im curious as to why it's impossible to recover it and would appreciate if someone could offer an explanation. I'd love for this game to be remastered for PS4 or PC.

    submitted by /u/circuit4812775
    [link] [comments]

    Html5 Multiplayer Game Tutorial with Phaser and Node server.

    Posted: 27 Feb 2018 04:37 PM PST

    I just completed my 8 part multiplayer game tutorial series with Node.js server and Phaser client. It goes from authoritative server with physics in the server to hosting the game online. For the tutorial purpose, we're recreating Agar.io. We're making everything from entering the username, leaderboard, highscore, etc.

    First Part: link: http://gojasonyang.com/post/phaserMultiplayerGamePart1.html

    If you just want to check out the code, link: https://github.com/dci05049/Phaser-Multiplayer-Game-Tutorial.

    submitted by /u/ShinyGooseAss
    [link] [comments]

    Our life-long dream - a piano on a touch device that conveys feelings and emotions of playing the real piano

    Posted: 28 Feb 2018 10:59 AM PST

    Hello everyone!

    I'm a programmer of a small team and I'd like to tell you about my project that I've been doing for more than a year.

    Soon after the arrival of the first touchscreen mobile devices I wished to play a game, that will convey feelings and emotions of playing the piano. Meanwhile, a simple composition could be played for the first time and some more complex ones could be easily mastered within a short period of time without spending years on special education and without having any particular knowledge and skills in this sphere. I have been waiting for a game like this for ten years now, but no matter how «magically» made the analogs were, they still fell short of my expectations. They were prone to one of the extremes – either they were pretty much simplified till «one-two finger clickers» or they were too stodgy, merely unpleasant and unplayable.

    Finally, we are ready to show our project to the world - "Another Piano"

    Our trailer

    Also, we are working on the version for phones.

    iPhone gameplay

    Yesterday the campaign on Kickstater started.

    Meet our small team. We are looking forward to your support!

    Our team in oil

    P.S. I'm on the left with a cat on my knees :3

    submitted by /u/LessTergy
    [link] [comments]

    2D adventure game engine for beginners

    Posted: 28 Feb 2018 10:38 AM PST

    I've had this idea for a story driven, humorous 2D adventure game, a bit like Earthbound or Undertale. I don't have any previous experience in game development, so I was wondering if there are any easy to use tools you guys know of so I can get started. Preferably free or with a free version, since I don't know if this game will become something I seriously work on and plan to release.

    submitted by /u/Elemeno24
    [link] [comments]

    3anglez - minimalist arcade game

    Posted: 28 Feb 2018 10:34 AM PST

    3anglez is an HTML5 game that uses Phaser as the main game engine that handles the logic and rendering while Howler is used for the sound.

    It was ported to Android using Cordova as a container which can access the native API of an Android smartphone and Crosswalk that acts as the WebView rendering the WebGL context. Implementing Cordova plugins such as Notifications, Leaderboard, Analytics, was hard because they would always enter into conflict with each other and collapsed the whole game. After days of fixing, they now act nice with each other.

    The whole idea of this game was to provide hours of fun using only basic shapes. So I picked the polygon with the smallest number of sides (the triangle) and I build the entire world using it. The triangle is also responsible for the l33t style game name (3anglez).

    The gameplay is pretty simple. You have to avoid the spikes, the rocks and the enemies (they have some basic artificial intelligence and will try to kill you). Your job is to lure the enemies into the rocks in order to gain points that are used for upgrades. The controls are simple, tap anywhere on the screen and the player will follow you.

    The depth effect of the main game scene is created using 6 parallax layers. There is a slight tilt of 5 degrees present in the whole game that gives you a unique feel compared to other Android games (this feature was pretty hard to implement since I didn't change the camera angle but instead I tilted the sprites which required some pretty complex trigonometry). The color changing background helps you track your progress.

    You can try to challenge and defeat the leaderboard top players by getting a higher score! Here is a link where you can play this game: https://play.google.com/store/apps/details?id=com.inn3r.anglez3&hl=en

    If you have any questions post them in the comments and I'll try to answer them. Thanks for reading the whole post!

    PS: I can't say how many levels are there but you can try to finish them all :D!

    submitted by /u/inn3r
    [link] [comments]

    Played around with Unity's new C# Job System last night on Twitch. Didn't go quite as planned...

    Posted: 28 Feb 2018 10:21 AM PST

    Killer Sci-Fi Environment Production Tips and Tricks

    Posted: 27 Feb 2018 07:00 PM PST

    Qualifications

    Posted: 28 Feb 2018 10:02 AM PST

    Hey I'm really sorry if this kind of post is not allowed here but I just had a question I wanted to ask . So basically I'm 17 years old Living in India and game designing has been my biggest passion for such a long time and it's the only thing I want to do , but I was kind of confused how to approach , basically I will be finishing my 12th finals in about a month and then from June I'll be joining a college which is mostly going to be Computer Science Engineering but I always thought that once I finish this bachelor's degree in need to do 4 more years of Proper game designing but then I came across other sources I don't remember too well which told me that a degree in CS and a good portfolio ( CV) with good enough game designing skills like knowing how to use the software and all that and having the knowledge and experience on how to make games and also having sample projects or small games which I've done is enough to get me into the game designing industry and get me a job . So my question is , if I spend all my free time during my CS degree in learning game designing at home and developing skills ( thought of learning unity and several other softwares) and working on small games and project , will it be enough to get a game designing job in US ? Also I'm interested only in graphics not coding , although I'll be having coding skills due to the CS degree . Also I know English really well and I consider myself creative and I game alotttt so I understand game mechanics and plus I'm a good speaker and can present stuff well with confidence . Thank you so much if you read all of this and Thank you even more if you reply ! Sorry if I left any details out , feel free to ask anything !

    submitted by /u/RPisOP
    [link] [comments]

    How I designed the camera controller for my 2D action game to make it feel like an episode of Battlestar Galactica

    Posted: 28 Feb 2018 09:52 AM PST
    Read more
    at

    No comments:

    Post a Comment