What is Reddit's opinion of
LÖVE?
From 3.5 billion Reddit comments
100 reviews of this app found across Reddit:
follow along with Harvard University's Extension School's Introduction to Game Development course
they have posted all the lectures and assignments on line
https://cs50.github.io/games/lectures
they start with Lua and the Love2D framework
and later move onto Unity and C#
If I could give my younger self one piece of advice, it would be to focus on building things, not on learning concepts or languages. Learn what you need as you go along. Always keep in mind why you're learning something, and you will never struggle with motivation.
Lua is a great language. You can also make your own games with Lua using LÖVE.
Very tangential, but I would recommend carefully considering what you present to students. CS is used as a general term, but not everybody is truly interested in the abstract science (i.e. computability, etc). Software Engineering, Informatic, Bio-Informatics, Information Science, and more are also common related majors/programs with different kinds of focus. CS programs in college are often full of theory courses and math (I know because that's what I'm studying). Some people won't have any interest in the abstract, but mostly with what they can do with it. They may not need to study CS specifically to be able to do things with technology in their future.
TL;DR It's important to realize that CS != doing stuff with computers.
You might also wish to add some kind of game making to your curriculum, since it sounds like you'll be covering programming. Love2D (https://love2d.org/) might be a good option. It's a Lua game engine that's pretty easy to get started with. This might be useful -> http://pilove.mitako.eu/
Here have my opinionated opinion:
TL;DR: Lua doesn't have enough of ecosystem to support standalone apps for anything, and being targeted for embedding makes it de facto a 'secondary language'.
It's not popular as a scripting language because there are three others that already have extensive software collections and communities, and each of them has some unique-ish point (e.g. Python and SciPy, Ruby and Ruby on Rails, Perl and the most comprehensive archive of modules ever).
It's not popular for 'standalone' or systems stuff because it was never really meant for that. Here you have C, C++, C#, Java etc. that are well established, can interface directly with the OS, have libraries and whatnot etc. etc.
It's not meant for browsers, as there is really only JavaScript there. Maybe lua-to-js compiler? But then there is a lot of X-to-js 'compilers' out there already.
Lua was meant for embedding - and it's actually being used in this context! You can find it in games, in various tools (e.g. nmap), even in kernels. But embedded lang means it's an asset to something written in something else - it's not the primary language.
If you feel like you can't create stuff fast enough, you might want to consider using different tools. Some development environments allow for games to be developed quickly so that you spend less time coding and more time actually making your game.
Try something like Gamemaker, Construct 2, Multimedia Fusion 2, or Love2D for getting your ideas out quickly.
If anyone is curious about the LOVE API, do it! If you don't know Lua, you can learn them both at the same time. It's really simple and intuitive. For me, one of the drawing points of Lua is its non-rigid grammar as compared to other high level languages such as Java- it really lets me focus on the logic as opposed to finagling with the language.
Anyways, Lua + Love is good. You should use it. Oh and if you want some animations, try AnAL.
I'm a big fan of Lua's LÖVE for first time programmers. The minimalism of the language makes it easy to get the hang of when you're first starting out, and having a graphics engine to go along with that only makes it better.
Building a small game in LÖVE is a great way to learn the basics of developing software.
For many of the same reasons, I also think that people should start with C if they want to learn a 'serious' programming language. Yes, it's gonna be a bitch to deal with until you get the hang of it. Once you're over that initial hurdle of learning how to pointers, C is a relatively small language compared to many others. Most languages used for programming are either C itself, C-based, or has C-like syntax, so the skills transfer very easily as well.
Got a first release candidate out for ggez 0.4.0, a lightweight game framework modeled on LÖVE for making 2D games with minimum friction . It's a big release with lots of bug fixes and new features, especially to graphics and window handling... but now all that needs to be done for the full release is cleanup and documentation. Woohoo!
Maybe now I can take a break a little and spend a bit more time working on various IPFS-related things... still have to finish my hosting service project, and I want to play with the possibilities of using IPFS for a distributed public-key service...
With Love what you have to do to make an EXE is append your .love file, which is your zipped game folder, to the Love executable.
The Game Distribution page on the wiki gives the details about how to do this.
There are unofficial Android and iOS versions of LÖVE 0.9 already – I did the iOS port and someone else did the Android port, but their codebases are both forks of LÖVE's and they share as much common code as possible, so all of LÖVE's features are in the ports and the new mobile APIs (love.touch) are the same in both the Android and iOS ports. We're planning to basically integrate them into LÖVE officially in 0.10, with some improvements.
Several commercial games have been released using both ports (oh my giraffe is one that's been in /r/gamedev's screenshot saturday before.)
I think the least-polished part of the ports is the setup necessary for building and running LÖVE / LÖVE games compared to the desktop versions.
>Games submitted(34)
--
>Linux (33)
If anyone is curious, the "non-Linux" game is Stickmans Journey... which was made in Love and can potentially run on any desktop or mobile platform. Including Linux.
You're really not thinking of it correctly. You cannot use Unity without the editor, and I don't see why you would ever want to. The editor is massively powerful and saves you a ton of time.
If you think you can design your game purely in code, there is no point to continue looking at Unity or Unreal. Look at thin wrappers such as SFML or LOVE.
https://www.sfml-dev.org/ https://love2d.org/
Just remember, if you only use a hammer, everything is a nail. It really sounds like you're working against your toolchain. However if you're hellbent on using "just code" then idk man you do you.
It was a vague question because you didn't specify the type of game you want to make. The engine (if any) recommended for an FPS would be different from that for an interactive fiction or 2D puzzle game.
Also it comes down hugely to personal preference. Do you want a big IDE-like engine like Unity or Unreal 4? Or do you prefer something more DIY like Love2D (which is great btw, you should consider it for a 2d game)?
Budget also matters if you're looking at 'pro' engines. Most take a fee or a cut in various ways. Cryengine has Linux support so that's an option (unless you wanted the tools to run on Linux - you didn't specify).
Also would you prefer FOSS tools or are you ok with proprietary? The FOSS 'answer' to Unity is Godot, which seems pretty decent.
And obviously you can make a game in any language that has GL and/or SDL bindings. Or even those without if you're willing to do some very hard work. You could make a game in anything with Ncurses support. Or just in text. You could make a game in the form of a Libre Office spreadsheet.
But yeah, based on the clarification you offered after the vague OP, Unity (which does run on Linux now as /u/RyuzakiKK mentioned) or Godot sound like what you're after.
Just to give you some context, this is like saying "I only know English, but I want to learn about romance languages, so I'm going to start by translating poetry from Spanish into Italian". It's not impossible, and if you have the patience to keep at it you are going to learn a lot, very quickly, but you're going to need to put in quite a bit of effort before you see any results at all. If you want to take that on, good luck, but I think a lot of people would prefer starting with something simpler.
If you're here, I recommend playing with 2D game engines like Game Maker, PICO-8 or LÖVE and try to recreate the simplest games you can think of: rolling a die and displaying the result, guess-the-number, Towers of Hanoi, Solitaire, Tetris, Space Invaders...
I remember reading a one-paragraph review of the Game Boy Advance version of RPG Maker in the JP import column of a gaming magazine and I thought "Wow, you can make your own games? Sounds AMAZING!". A few weeks later, I picked up RPG Maker 2003 for PC and I spent a few years using it!
I think the next things I picked up were TI-Basic (to make games on my TI-83) and then Flash MX 2004 + Actionscript 2 while I was in highschool.
I would not recommend using any of those things though. New versions of RPG Maker might be fun though but I think Love 2D is the perfect engine to get started.
Upvote for Linux version.
EDIT: After doing some (extremely) brief research, it looks like the people I really have to thank are the creators of LÖVE, which is the framework upon which this game was built. More info on their website: https://love2d.org/
There's X@COM by Kyzrati and https://love2d.org/forums/viewtopic.php?t=82886 On the Roadside by rmcode. Both are somewhat like Armored Commander in that they skirt the edge between roguelikes and turn-based strategies.
I'm enjoying using LÖVE but it's more of a framework to write games with LUA. I'm knocking together a remake/clone of Jet Set Willy.
Godot is popular. The UI/IDE is written using it's own engine so you can use Godot to modify Godot.
The Old ID Software engines like Doom and Quake have had lots of work done on them since they went open and if I wanted to make an FPS I'd probably start with them.
Have you taken a look at the distribution wiki page yet?
In short, you can distribute games, without porting or shenanigans like that. It's usually just a bit of folder and file manipulation which you can do with a few commands that are provided or even automate it if you so desire.
Though for iOS development you need access to a mac. Not 100% sure if you can package for Mac on another system. I'm too inexperienced with Mac and .app files. I think it should be possible on another platform.
And for linux there isn't really a way to create an appimage yet. So you'll have to tell people to download Löve and your game (as .love)
Just a side note: Love does, as of 0.8.0, have shader support in the form of "pixel effects" which, in my opinion, offsets the lack of mobile support significantly.
literally on the main page of the wiki, on the last paragraph of the Welcome section, it says
> If you want to read this wiki without an internet connection, you can download a weekly generated package for offline viewing here
Click that link to download an offline copy of the wiki.
When it's ready. This year, probably. :)
A mostly up-to-date changelog for it is on the wiki, and you can see the latest commits on Bitbucket. If you're on Windows you can also download nightly builds: https://ci.appveyor.com/project/AlexSzpakowski/love/branch/minor/artifacts
Lua's about as good as it gets in terms of performance as far as dynamic languages go, and the whole thing's architected as a bunch of performance intensive stuff (physics, audio, batched graphics, etc.) implemented in C, and exposed to Lua via the api, so performance really isn't that bad. The default main loop is single-threaded, but you can trivially rewrite it with love.thread if that becomes an issue.
I'd say the biggest downside is, as the name suggests, the limitation to 2D. There have been efforts to mitigate this, but ultimately you will be working pretty heavily against the grain if you want to do anything 3D.
You're definitely not the first to complain about this: https://love2d.org/forums/viewtopic.php?f=3&t=13300
My opinion: Americans are overly sensitive about sexual things, but these libraries tend to go out of their way to joke around with them. It would be nice if this were not an issue, but being forced to compromise by renaming the existing libraries is a disagreeable option.
I can imagine why this would make it difficult to teach Love to kids, but maybe rather than be embarrassed about it, it should be embraced? It would help keep things funny and silly while kids learn about coding and game design.
I basically learned by copying/pasting scripts together. I created unholy abominations of shit that somehow came together to make a (shitty) game. I slowly learned what everything I coded actually did. They key is to not give up. Stick to the tutorials and try to make cool shit. I would recommend picking this up: https://love2d.org/ . You can make simple 2d games with it and get a hang of basic gamedev. After, you can move into C# or C++. Unity is perfectly viable too, but maybe more complicated than you might be comfortable with.
For those of you that already know how to program, I just want to share something really dumb I did as a beginner. I remember making a function called BarrelRoll. I need a function that had to do roughly the same thing. Instead of passing a parameter, I copied and pasted the function, changed a single thing, and renamed it to BarrelRell. Fuck I was so bad.
Here's a list of the games made with Love2D: [Link text]https://love2d.org/wiki/Category:Games
You can look through them and judge for yourself if the framework is good enough. Though mostly, its the way you structure your code that matters.
there is some progress in porting LÖVE to android (https://love2d.org/forums/viewtopic.php?f=11&t=4270&sid=f8ff6a6b15b06192020814d60a6ca9c8), and I wouldn't be shocked if it happened before Hawkthorne is finished (given that Android is based on Linux), so I think it makes far more sense to wait and see if LÖVE is done than to switch platforms now.
I'm a proponent of sketch out the thing you want to make and then learn just enough to be dangerous, but if you want some resources that are better written than anything I could make on the spot:
https://love2d.org/wiki/Category:Tutorials
Love2d is a game framework for lua and so that is an ok place to start.
But there is no perfect tutorial so asking questions early and often is good (and having a specific goal in mind helps ask better questions). Especially since tutorials can't guess at what skill level you are currently at.
In my opinion it's better to write platformer physics yourself, because most of the time you don't need them to be realistic - just fun.
As for resources on this, there's an article on the wiki on how to make a very basic 2D platformer. For collision detection you might want to use a library like bump.lua or HC (for collisions with more complex shapes).
Fans of the NBC show Community brought a game from that show to life using the Love2D language. So anything is possible. For all we know, we could be in a turtle's dream in outer space.
We want to officially support that eventually, there's been work done by /u/WuTangTan who made a port of 0.10 for emscripten. Here's the latest word from him: https://love2d.org/forums/viewtopic.php?f=12&t=81736&start=90#p219024
Making a game.
It sounds stereotypical, but it's how I started, and I believe it's the best way.
On the forums there are projects people have submitted, you can download them and look at the code.
But an important thing to remember is that there probably won't be a tutorial for exactly what you want to do, but you don't need it, as you can transfer what you've learnt to what you want to do.
It helps a lot if you switch the theme from the default to GM8 in Preferences (always the first thing I do on a fresh install). The worst change they made in Studio was setting that awful black theme as the default.
Beyond that, it's a legacy thing. If the first version were made today, it would look very different, but the first version was made fifteen years ago (in Delphi), and it laid down the core workflow that's probably just too ingrained to change now. And it's a little better than it has been in the past (afaik you didn't used to have as much movement freedom with code windows, but I could be misremembering).
Stuff like the maximisation is a pain. After working with GM for a enough years, you develop an unconscious maximise reflex and kinda stop noticing it. That's the best excuse I can offer, and yeah, pretty lame.
To be totally honest, I don't know that I would really recommend GMS to someone just getting into game development now. A lot of people I've tried to introduce it to, especially those who already know a few mainstream programming languages, don't really take to its nonstandard behaviours and methodologies. GMS is a killer product for people who already learnt GM in the old versions and now want to leverage those extant skills to make games for smartphones and web browsers. Or for kids with really wealthy parents. It's developed into a very powerful, but still immensely quirky tool.
But for someone starting out... you might prefer Unity or an HTML5 engine like SuperPowers or Love2D or maybe even Construct. I love GM, but if I'm honest, a lot of that is probably Stockholm Syndrome.
> is there anything comparable for someone who is in the opposite situation?
Don't listen to the naysayers. You can write games without being a "proper" programmer. While not 3D:
- Tom Francis wrote <strong>Gunpoint</strong> using GameMaker.
- Windybeard developed <strong>Sweezy Gunner</strong> using Multimedia Fusion.
> completely build up another skillset?
You're perhaps of the opinion that a programmer can write any program just like that. Doesn't work that way. I have been programming for 15+ years and I find writing even simple games from scratch (without using any engines/frameworks) tedious/hard because of the number of APIs and the amount of work involved even if I know exactly what needs to be done. On the other hand, I can write things like parsers and code generators effortlessly.
The experience that people have writing web/financial applications doesn't translate as-is to game programming. The only thing you carry with you is basic programming knowledge. And that is something any one can pick up in a few months, if not weeks. You can start using something like the Lua scripting language and the Love2D engine to start drawing things on the screen. Once you're comfortable with the idea, you could explore 3D engines and games, and even other languages.
Always remember:
- Easy: Composer/Artist -> Journeyman programmer
- Hard: Programmer -> Composer/Artist
I should say though that if you are a one-man studio, 2D games are easier and safer. Might not want to attempt full-fledged 3D games unless there are 3-4 people involved.
It isn't. GameMaker does alot of stuff for you that you will forget when you start writing everything yourself and that is plain bad for a start. If you want to learn how to "code" stuff (not only games) and you want a easy way of starting without going head-first into C# and other stuff check out LÖVE.
If you know what you want to do, got a small team ready and need a somewhat "okay" frame for your project game maker is just fine. If you want to learn how to do everything the easy way try to avoid tools that do a good amount of work for you like game maker.
A web developer is not a tool, but simply a developer (programmer) that writes applications for the web. Javascript is one of the tools a web developer uses.
Javascript has the very neat property that its interpreter is included with every web browser. This means that you don't need a game engine (which in turn is simply a collection of tools and pre-made code that removes big parts of the work required to make a game), but only something like Chrome, Firefox or Internet Explorer, as well as some sort of editor to write the code in.
Visual Studio is an Integrated Development Environment. It's basically a text editor (like notepad) with a bunch of tools bolted on (again, to remove big parts of the work in programming). You don't need anything that fancy for Javascript (or any programming language, really), but it can help.
As far as I know, Anselm and Michael are writing their own game engine, instead of using a premade one. They are, however, using "libraries" (collections of code, basically) that other people have made. This is very useful, as it turns out that many problems are common to several fields in programming, and someone has almost always published a solution to your problem.
Regarding making a game engine, you can make that in any programming language. It is, however, a huge undertaking. Especially if you want it to run fast.
That doesn't mean you shouldn't try to make games though! There is a neat little game engine called LÖVE that you can use to make 2D games. It uses a language called Lua, which is kind of similar to Javascript, but it comes with everything you need to make a basic game built in.
I'm not a full-time programmer, but I know my way around software development. I can probably answer some more questions you may have.
You would need to first parse the XML into Lua, and then manipulate some data so it is love-centric. I did a similar thing with Tiled (except Tiled exports to Lua, so I was able to skip that step) with my Tiled library, Simple Tiled Implementation.
I've been working on these declarations to allow LÖVE 2D to be another game engine that can be used with TypeScript thanks to the TypeScriptToLua transpiler
Declarations: love-typescript-definitions
Transpiler: TypeScriptToLua
Game Engine Home Page: LÖVE 2D
it's an API, you but code in Lua. Once you look over that, the API is pretty identical from LOVE, the desktop version. I've also got a trello board for what's done so far.
Veins of the Earth - LOVE
- Implement prepickup function that fires before you pickup an item
- Implement money, spawn it
- Increase player's coin counters when picking up money
- Replace some console prints with log prints in the interest of performance
- Fix random piles of stuff on starting tile - the NPC inventory code used 1,1 as the stand-in coords when creating items that would go in the inventory, but never removed them from 1,1 later, oopsie :)
- Use treasure tables to spawn coins on monster death
- Randomize the amount of coins spawned on floor
Refactor Map:display so that it calls Map:displayActors(), Map:displayObjects() and Map:displayTerrain() instead of being a giant function in itself
Spend a day and a half trying to implement isometric map by myself, then remember the STI (Tiled map loader library that can also do isometric). I failed at integrating STI with the existing project, so I created a new folder, put STI in it and started ^almost afresh.
Current state of isometric version - pic
LOVE file of isometric version
The isometric version is missing the FOV as well as most of the GUI bells and whistles. But you can move and see the AI move and hit them.
Today I'm going out to a local con to see some friends, some of which I haven't seen in a year or more. Tomorrow I'll try to get a grip on Gamejolt and TIGSource forums - I seriously want some feedback on the game and the ideas.
I'm not sure where you heard they are unsuited to this task, because I am 100% positive you can do a 2D turn-based game in all three. That said, personally I'd recommend Python.
Incidentally, is not using a game engine part of the assignment? Because you kind of imply that, but don't actually state that; if you can use an engine, check out Love for programming this in Lua.
Wouldn't it be easier to store the id on love.touchpressed and then only allowing input from that id until love.touchreleased?
Definitely becoming increasingly popular, especially after the Legend of Dungeon people wrote about it (although they were not the first to think about it) and the release of Sprite Lamp. I remember seeing a post on the Love2D forums a couple years ago that was really impressive: over here. Lighting is such a strange beast in 2D games, especially with pixel art. With these techniques, it almost loses the true pixel art feeling and becomes something else, like a new, highly stylized art style where everything is a mosaic-like texture.
I guess I might as well post what I've been working on. I've been trying out LÖVE this week and made my first LÖVE game.
Last Defense - A mashup between space invaders and breakout, you reflect your enemy's weapons back at them. Instead of protective shields as in Space Invaders, the green boxes are what you defend from weapon shots.
It doesn't really have any graphics yet, but it has 8-bit sounds and is totally playable and the skill curve is more interesting than I thought it would be. There are multiple levels--each level increases the speed and rate of fire of the invaders.
I think for now I'll just clean it up visually, fix the little details like not exploding when you lose, and pronounce it finished. It's been fun to work on a very very small project and see it near completion, compared to long, long projects that never see the light of day.
You need to use love2d specific file loading methods because a zip file isn't the same as normal folders.
dofile is from lua, and loads files from a regularly defined set of folders, including the current directory. Dofile doesn't know how to load things from inside the love archive file.
If you use require somefile, it will work, because love changes the behaviour of require to know about the love archive file.
If require won't work for you, then use methods from https://love2d.org/wiki/love.filesystem .Your best bet is probably love.filesystem.loadfile in that case.
You can download it as collection of htmls.
I don't know of an automatic way to turn those into pdfs. It is a wiki after all.
Here's the link to the offline docs: https://love2d.org/wiki.zip
Edit: Ah, you found it :)
Cheers!
LUA ist recht gut für Anfänger geeignet:
https://www.activevb.de/tutorials/tut_lua/tut_lua.html
Sie ist recht einfach aufgebaut (es gibt z.B nur einen Datentyp für Zahlen) und man hat recht schnell Ergebnisse.
Man kan sogar Spiele damit programmieren:
Man ist mit der Programmiersprache nicht für den Rest des Lebens festgelegt. Man sollte sogar mehrere unterschiedliche Programmiersprachen lernen.
house.lua needs to return house to make it visible to anything loading it. In addition, love.filesystem.load returns stuff, so you need to set its return values; it's not enough to just invoke it e.g.
local house, _ = love.filesystem.load( "house.lua" )
Generally speaking, I use "require" to load other files (similar to using "import" in other languages); I don't know what the benefits of using love.filesystem.load are tbh. Using "require" looks like this:
local house = require("house.lua")
try to follow Harvard University's Extension School's Introduction to Game Development course
https://cs50.github.io/games/lectures
they have posted all their lectures and assignments online for free
they start off with Lua and Love 2D (first 8 weeks) and then move onto Unity
the instructor is ok, and not boring
but I think the biggest plus is that by following along you get a set of goals to work towards and keep you on track and motivated with progressively more difficult set of assignments
Could you dump it next time on a place like pastebin for formatting and syntax highlighting? It's kinda hard to follow code like this.
Also a more specific explanation of what doesn't work is always helpful.
For now I'm gonna assume that the problem is as outlined in the header with math.random().
Math.random() is seeded. Meaning it has a default seed if not initialized otherwise. Resulting in always the same list of numbers being returned.
As outlined in this documentation for the math library.
The first numbers themselves aren't random either. A usual setup is doing the following:
> math.randomseed( os.time() )
> math.random(); math.random(); math.random()
Yes. This is somewhat silly and love implements it's own randomness function for that reason. Either as direct function or via a generator object for more consistent seed generation (so for example. You can use a specific generator for the world generation instead of using a global random number which will output different values when it's called multiple times even when seeded. So if you don't use randomness exclusively for particles, you can not rely on seeds resulting in consistent behavior. Which is solved by random number generator objects).
Here's the link to loves math utils: Link
Yeah from what I've seen (as far as how the backend runs) from what I've seen is that it's either through a VM, interpreted, or used as a script language.
There's a really nice, popular gaming API for Lua, too, and quite a few libraries that people have built that can aid in development with it. The framework is called LOVE and you can check it out here: https://love2d.org/. It's a really nice community and LOVE show's a lot of potential, too ^_^.
Either way, I've been using LOVE to create a game myself and it's been really, really fun to play around with. There's a lot of nice libraries for both LOVE and Lua like Classic that implements OOP into Lua, general libraries for game creation such as camera management, collisions, map creations, and the likes. It also has support for inline GLSL code for when you want to do some shader work! Although, I'm not sure if or how that works with the 3DS implementation.
Sorry I'm not able to provide you with a ton of information, but if you have any more questions I wouldn't mind answering them to whatever extent I can at all!
Also for reference, here's the 3DS implementaiton of LOVE/Lua in the same package: https://github.com/VideahGams/LovePotion.
Here's the implementation of a Lua interpreter for the 3DS that codepoet was talking about in a separate comment chain below... it's not as well written, but it does get the job done when you need to make some quick system utilities: https://github.com/Rinnegatamante/lpp-3ds
Also mind I'm only saying it's not super well written because when I used it some things weren't working, but I was /extremely/ new to both Lua and game development and I haven't really looked through the source itself to judge whether it's good or not.
I'm mostly taking codepoets word for it, but mind they also seem a little biased against Lua even when there's communities like LOVE thriving off of it.
Yes, you can make (just about) any 2D game you'd like with Love2D. All it takes is the coding of the game (and for things you don't want to code there are generally libraries made by other people).
TL;DR: You can indeed make a game like Hotline Miami in Love2D.
Edit: There are links to the forums and the wiki, which has documentation.
> I can only export for Mac if I'm on a mac myself. And on Linux, you literally have to provide the .love file (which is your source code!) and expect others to install LÖVE.
The game distribution situation isn't as streamlined as it could/should be, but neither of those statements are true. You can create a fused Mac .app from any OS (provided you keep the symlinks inside the .app folder intact), and for Linux you can either provide and installable package (e.g. .deb or something), or a completely standalone / portable build.
For the latter there isn't an official downloadable solution on the love front page yet, but work on that is in progress / being tested ( https://love2d.org/forums/viewtopic.php?f=3&t=83087 ). You can also create a standalone Linux build yourself if you have the know-how.
Regardless of your target platform, current platform, and choice of engine or framework, you should always test all versions of anything you make on all its target platforms though, when possible.
Check out Love. You do the coding with Lua, which is very similar to C++ and Ruby. And Love handles all the nasty, tricky stuff like window generation and drawing graphics. You're essentially writing three functions: the load function, update, and draw. In load you set up all your initial conditions. In update, you catch button presses, write the logic for enemies and the world, etc. And then draw, you tell it what things you want on screen. There is also a nice community and tutorials.
- The games factory
- LÖVE
- Unity3D
- If you're preparing it up with demos and examples, then just python+pygame would fit your pick as well. I see you're looking for something that doesn't require much expertise to pick up. But for someone experienced with gamedev himself could even just setup some scene editor and code view to provide an environment for beginners.
Guys.
https://docs.google.com/spreadsheets/d/135HgMYcRDt6vnJN0d-xFMEZUeWjVbc61ETf8uVwHERE/edit#gid=0
This is an ongoing effort by the LÖVE community, started by the user "Ivan":
I think Natural Select 2 would be a better option, it's a cleaner codebase with actual documentation and a real API. Space Base is mostly spagetti code strung together.
If you have Incognita is runs in the same engine, and is much more readable, it even has developer comments!
Or just dive head first into the LOVE2D engine.
Gods speed. It looks like there are some people already working to get Löve working on RPi, but you will probably have to compile it for the ARM architecture, and it sounds like you may run into video issues, since the drivers may not be doing hardware acceleration yet.
Very interested to see how this goes though! Good luck!
I actually use SDL in C++ with the VC++ and G++ compilers. I would agree that it has a reasonable bit of boilerplate code needed, but I find the library very nice to work with, especially the 2.0 RC version. I suppose you could use gcc (the Gnu C compiler), I'm not really sure of any other quality C compilers (is Clang/LLVM good for C?). Visual C is pretty lacking, MS's C support I think is more just a side effect of their C++ support, so it doesn't get much love.
If you're interested in a C++ library that's similar to SDL, you could check out SFML, also get the 2.0 RC version of this library. I haven't used SFML much, but i believe it may have less boilerplate code needed.
In addition, as suggested previously in this thread Unity is an excellent engine, and there do exist free packages to make working with 2d in it far easier, and there is a free version of the engine, the pro is $1500 but the free version is completely free as in beer.
If we expand our search outside of C/C++ there also exist other excellent frameworks such as Pygame which uses Python and LOVE which uses Lua. There's more too, but these are quite popular and good.
I just had a quick look at the README[1] file and can't see any mention of moving to a directory.
It looks like you just grab the source (extract or clone), then run
./platform/unix/automagic ./configure make
Can you try this and if it doesn't work, post your console output onto pastebin or something. Ta.
Löve is really great. Packages small, runs everywhere Lua can (so, everywhere).
Note that in true Lua spirit, in exchange for being light, you have to implement pretty much everything apart from the game loop and the basic I/O stuff.
Here's a really thorough tutorial to learn Löve by building the author's game, Bytepath.
Obwohl Spiele spannend sind, kann ein großer Game Engine wie Godot einen Anfänger schnell überfordern. Ich habe mit LÖVE angefangen, welches mit Lua funktioniert, eine Sprache die ich sehr empfehlen kann da sie simpel und deswegen einfach zu lernen ist. Trotzdem started man am besten auf der Konsole mit einfachen Programmen die die Text Ein - und ausgabe verwenden.
Check the docs.
https://love2d.org/wiki/love.graphics.newCanvas
I’m on my phone right now but the idea would be.
Get window height, get window width.
Set your ideal resolution, let’s say 480x640.
Create the canvas: myNewCanvas = love.graphics.newCanvas(480, 640)
You need to divide the screenwidth with the ideal resolution to get the multiplier for scaling:
widthScale = screen width/480
If you want that to be “pixel perfect” you need to use math.floor on the scale and apply the same number on the heightScale.
It’s possible depending on how you are implementing it (if you are using math.floor) you game screen won’t cover the entire screen so you need to add an offset to your canvas on the sides to get a letterbox. For doing that you need to get the difference between your scaled canvas width and the screen. Something like cancasOffsetX= (screen Width - (480*widthScale))/2
You can apply the same logic to the height if necessary.
Then you need to draw your game on the canvas. Once you finish you need to draw the canvas with scaling on the X and Y and the offset on the position. You can check the documentation and have a play with it.
I recommend using defold it's a free open-source (kinda) cross platform game engine.
If you want a retro fantasy console emulators then TIC-80 and PICO-8 are the best options imo (PICO-8 is proprietary software that you have to pay for, but TIC-80 is open-source), but they are mostly code based with a few interactive tools (like a world editor).
​
There are also the most popular ones, like Love2d and solar2d (prevoisly named Corona) but those are frameworks and not a game engine (they both don't have world editors or anything like that)
Because no one has mentioned it yet, give Godot a try. I was using it in gles2 mode on my ancient laptop. It has a Mac version, but I don't know how far support goes back.
Someone else mentioned LÖVE which is just a player for Lua scripts. I've used it before and it's really good.
>The only thing I’ve been able to use is Twine, which doesn’t even make applications.
If them not being applications is a sticking point, google twine compilers. The first one with a Mac port I found was Tweeego but I'm sure there are others. Twine is great at what it does, but what it does has a very limited scope.
You could also go the hard way and just learn to program. Get C# ~~(or C++ my favourite)~~ and just learn how to program. You can make games, and you can make sure they run at whatever hardware target you want.
I think the problem might be related to dofile(). I've made a few games myself (no expert here), but I've never used that, always just done require('...').
This link also mentions not using dofile, so it might be a known issue.
Love2D released a new version on April 1 2018 (version 11.0)
https://love2d.org/forums/viewtopic.php?t=85051
some of the changes were
- deprecated love.filesystem.exists / isFile / isDirectory / isSymlink / getLastModified / getSize in favour of getInfo
- Changed colour values to be in the range 0-1, rather than 0-255
so for the edx course starting on July 1 2018 should we use this new version or should we the version before that -- (version love-0.10.2)
Start with Lua and Löve. You can play around with it and make a small gamer or two. Later I would advice you to at least try C++ for a couple of weeks so you can learn about pointers and classes and inheritance. You learn what the problems are with that kind of stuff and you can then switch to another language which solves those problems in a way. Or you can use C++ in an advanced way to solve those problems (smart pointers, ...).
ZomboTropolis (Zombie MMO for mobile) Github
Been adding the final touches to my class refactor for every object in the game. This update has been a frustrating slow few weeks, but I am satisfied with the how much cleaner my API is. I have most of the refactoring knocked out, but there are a few loose ends remaining. By next SS it will be completely finished and I can work on new features!
Implementing Composition, Mixins, and Inheritance
A had a big discussion regarding combining the three on the Love2D forums and the issues I was having in my game. Fortunately, I have solved most of them in a sane manner. The discussion other developers might find useful if they find themselves confused like I was!
Changes
- Transfer location data to new format
- Reorganized location files and data
- Remove location text descriptions (I plan to animate the location with sprites later)
- Remove many dependencies in files since code was split into smaller manageable chunks
- Fixed a lot of bugs from changes
Todo List Deadline for Next SS [12/1/2017]
- Refactor actions
- Refactor abilities
- Use composition for player subsystems
Total Progress to reach 1.0.0 release and launch.
Code [~70%] - Leftover Remaining: 10% Items, 10% Abilities, 5% Equipment, 5% Locations
| Task | Progress | Completed |
|---|---|---|
| Skills | 80% | 63/80 |
| Abilities | 50% | 07/12 |
| Items | 60% | 24/35 |
| Equipment | 20% | 00/03 |
| Locations | 45% | 10/23 |
Graphics [~2%] | Networking [~0%] | Music [~0%] | App Store [~0%]
First of all. Consider whether you need a fixed timestep.
It makes sense for physics. And it also makes sense to run physics much more often than the game loop. For accuracy reasons.
Many games run their physics 120 times a second even if they only manage 30 or 60 fps.
The article you linked also specifically talks about game physics.
Unless you need increased accuracy.
Now to answer your question. The best way to do this would be in your love.run.
Love.run is a function called by love containing the main game loop. Usually there's no need to tinker with it. But in this example, it would make sense.
https://love2d.org/wiki/love.run
Ideally. Just use the same one and modify it slightly to fix the timestamp.
Specifically. You'll need a counter variable. You increase it love.timer.getDelta().
While this counter variable is larger than your target fixed timestep, call update with your fixed update and decrease the counter by fixed timestep.
And that's about it!
Hey there!
I would suggest using one of the camera implementations.
Hump is generally a fantastic library and has one so that'd be my pick.
But anyway. Yes there is a way!
love.graphics.translate(dx, dy)
There's functions for rotating and scaling as well. The camera implementations use that too.
It happens implicitly, if you're interested the code that controls the main loop is love.run, and it calls love.graphics.present() to do the equivalent of pygame.display.update(), but you don't need to worry about doing it yourself.
Regarding the ugly... that's only a mediocre issue really. Bad yeah. But I wouldn't call it ugly.
It is rather common that you have to build for mac on a apple system. It's a closed system and third parties don't have the compiler. Meaning you either hack something together or you need that extra step.
For example: Unreal Engine 4 requires exactly the same step.
Most of the other things can be distributed with very simple batch scripts. I agree to someone completely unfamiliar with that type of stuff it's inconvenient. Hence bad. But not terribly bad.
Also. You have to provide the sourcecode. All distributed version contain it and have it rather easily accessible. Rename your .exe to a .zip and you can look right into your files.
There are ways to obfuscate and encrypt the lua files. But in the end that won't make much of a difference.
You could try to compile your lua files (which is by the way not necessary. Love2D is interpreting them during runtime. No compilation required!). Link to guide
But it does not actually prevent reverse engineering.
Just like no other game engine does. Granted. The default state is worse and it is easier to get on source code of love2d than it is for c++ compiled stuff for example. But the code has to run. The computer has to understand it. And as long as that's the case you can retrace the steps and get to some version of the code eventually (for c compiled stuff this is assembler which is quite a barrier to be sure. But not actually preventing anything).
You can always manipulate a game, extract content and modify it. If you put in enough effort.
All you as developer can do is obfuscate it and make it harder so fewer people will be capable to do it.
For the majority of gamers renaming the .exe to .zip will already go far enough.
As that page is saying. Do the right thing. License the code properly. Compile it. And you will be just fine.
Well. There actually is a canvas object which does exactly that.
You draw onto it once and just reuse the reference to it. (You can add additional things at any time but you can not remove specific sprites once drawn to canvas).
https://love2d.org/wiki/Canvas
There's also SpriteBatches for when you want to draw the same sprite a whole lot at different (potentially moving) positions.
https://love2d.org/wiki/SpriteBatch
Though in general I would suggest checking out the graphics library in general if you're concerned with performance. Or even when not. There's a lot of nifty stuff in there I just learned over time that would've been incredibly useful to know initially.
I don't watch videos for tutorials very much as everyone has a different way of doing things.
The love2d wiki is by far the best resource i have used to learn love2d. It's very mature, has documentation for everything and even examples for most.
If what you are asking is for beginner tutorials, they also have good ones on the wiki right here: https://love2d.org/wiki/Getting_Started
Good luck!
You should definitely give LÖVE a shot for sure! I have a game shipped on Steam using it (but other platforms are 100% viable as well), and before that I used it for a number of personal projects. :)
It's definitely missing some native functionality here and there (especially on mobile), but the API is always being expanded and there's a lot of awesome community libraries to supplement things! Phoenix listed the most relevant libraries for your project, but you can find a full list of libraries here.
I'm assuming by 'notepad file' you mean a text file. The love.filesystem module is what you want, if you are having problems with it, either post your code and that's having the problem (along with the errors), or re-read the documentation: https://love2d.org/wiki/love.filesystem
Hey Sean,
I started in a similar situation.
I started coding when I was 23, with no prior experience.
I picked up a book on C# and worked myself halfway through it, then I started to play around with XNA/Monogame a bit.
Two months later I met someone who introduced the programming language Lua to me, along with the LÖVE framework.
I was soo glad that happened.
Lua is very easy to learn, and a much more modern language than C# for example.
Don't get me wrong, I enjoyed C# when I wrote it, but with Lua you will have to write significantly less code than with C# or Java (let alone C++, which you shouldn't touch until you're relatively confident in your programming abilites).
And LÖVE is so far the best framework for 2D games I encountered, being well documented, having a nice community and performing very well - even on weaker hardware.
So I really recommend you give it a try, there are plenty of newcomers in the forum and most of your questions are probably already awnsered there.
I work with LÖVE, which runs Lua. It is a very versatile and comfortable framework, but only handles 2d. It is relatively commonly used in ludumdares afaik because the simple API and the fact that it runs on a scripting language makes prototyping easy.
Your code works well but I don't think that reading text is the best way to learn (especially trying to integrate networking into an existing physics system). You should start off with a simple messaging script. Networking is really really complicated sometimes, so treating it as a brand new subject will give you a good base knowledge to build on.
You'll want to start off with the luasocket tutorial, which goes over connections, polling, etc. Basically, you open a connection (like a highway) between the server and the client. From there, you can send 'messages' to the other computers msg queue. The messages are literally just strings, so you need to find a way to portray what your goal is: moving an entity might be "mv 8 400 300" to move entity #8 to the position 400-300.
Just bear in mind that sending a message isn't free. You might only send messages when an object has moved, or its properties updated. Also remember that the messages aren't instant so you may have to do some lag compensation (which is a different discussion all together).
Start with the tutorial, make a love script that let's you send some text to and from another computer, and go from there :)
I'm not familiar with MOAI or ActionScript enough to adequately answer those questions, unfortunately.
I have a small amount of experience with LOVE2D for Lua, which is decent in comparison to most game-development libraries. If MOAI is comparable then you shouldn't get much trouble.
A .zip file is a compressed file. Try right clicking on it, and choosing "Extract" ( or similar ).
Alternately, you can install the Löve framework ( you probably have windows 32bit ) and then download hawkthorne.love and then just double click on that.
Well... Here's a list of games from their wiki: LÖVE Games
I would also check their Forums. The quality varies, but there are some really cool games being made with LÖVE.
I can't really tell you which games on the first list have been released commercially, but I will say one thing: I will easily recommend LÖVE to "professionals". We use it as a prototyping tool at our studio, and for that purpose it is excellent.
Check the release notes for 11.3 and see if any of the changes or fixes look like they might be relevant to you. If that doesn't help, you could also try a deep dive into individual git commits between 11.2 and 11.3; it might be a regression related to some other change. If you're really serious about figuring out where the change happened you could build it from different commits between there, starting with ones that seem likely culprits, and figure out precisely where the breakage happened.
You could also see if it's still broken on git master that way. It could be a regression that's already been fixed.
1 - Set the gun rotation to math.atan2(targetY-gunY, targetX-gunX)
2 - Place all the elements of the map using an offset (which is the opposite of the character position) or use a higher level abstraction like a View / Camera : https://love2d.org/forums/viewtopic.php?t=83979
Löve2D might fit the bill if learning lua isn’t an issue. It has some good high level API to draw stuff and do simple interactions.
My entry into gamedev was GameMaker 4.x which had a graphical programming language of sorts. I’d recommend looking into it especially if some older version is available for free (I haven’t used it in a long time).
https://love2d.org/wiki/love.audio.newSource You are only passing the path, that function expects 2 arguments. Thats what the error means with ”bad argument #2” it expected to get a string but never did.
I don't know of anything that formal unfortunately, but I do have a bit of experience with ggez. There are some example games in the repo here, and the README.md at the base of the repo also has template that should be a good starting point.
Additionally, it's based off of the LÖVE framework, which has quite nice documentation. It targets Lua, but the concepts carry over to Rust/ggez quite well.
You gotta use love.graphics.newImage to load the image file into a drawable image, and then call love.graphics.draw inside your draw callback.
See https://love2d.org/wiki/love.graphics.newImage and https://love2d.org/wiki/love.graphics.draw for more information.
I'm not sure using FPS is the best approach to handling movement physics.
Check out the default event loop here:
https://love2d.org/wiki/love.run
It looks like they are using love.timer.step() to get the time passed since the last frame, then passing that into update.
If you multiply forward velocity by this delta time value, you'll see smaller steps the higher the FPS gets, which means you get consistent movement independent of the framerate.
i think a good comparison is that bevy aims to be a full-featured, highly customizable engine, à la Godot or similar (not there yet but getting there), whereas ggez is meant to be more like LÖVE. in my experience ggez is great for making something 2d and relatively small, and for getting started quickly out of the box, like for a game jam.
Lua isn't really designed for building games, let alone 3D ones. Perhaps the closest thing you'll get to a game engine for Lua is LÖVE, but it's really meant more for 2D games, not 3D (though it can do it).
Lua at its heart is an embeddable language. Its design goal was to be small and limited to allow software developers to embed it into their programs and provide it with extensions in order to interface with the underlying software, allowing users to automate/control/process data for tasks in a simple, programmatic way. Its use as a fully-fledged gamedev language for 3D FPS is questionable at best. You're better off learning C#/C++ for Unity/UE4/Godot, as those engines are designed to be performant in 3D.
Learn Lua. I learn Lua pretty quick, by just fooling around with a 2D gaming engine call Love. Didn't take to long to learn how to code in Lua. I made a Breakout clone and code it in Lua. Check it out, you might like it.
When you create a cursor from an image file, you can set the cursor's "hot spot" using the 2nd and 3rd arguments. The default 0, 0 is the image's top left corner, so just set that to the position of the hot spot on the image.
Löve uses a virtual file system.
Long story short, both your source directory and save directory behave as if they were the same. With the difference that you can only write to the save directory and read by default favoring the save directory over the source directory (should both have a file with the same name).
So for example if you have a test.lua in your source directory and a test.lua in your save directory. When reading a file via love.filesystem you would get the test.lua from your save directory.
You can check whether a file is in the save or the source directory with love.filesystem.getRealDirectory
This depends entirely on the rendering engine. Font, size, etc. all come into play. So, for example, LÖVE has Font:getWidth and Garry's Mod has surface.GetTextSize. Whatever API you use which supports this function would be different. However, they would probably already have wrapping support built-in if they already support this (just like LÖVE and Garry's Mod)
Wrapping the update(), on the other hand, solved it. I now have a while loop that breaks on player.turn, so every actor is processed in a single update(), only moving on to draw() during the player's turn.
If I'm reading Love's engine loop correctly, it cycles between input processing, update(), and draw() in a loop, so that at least is consistent.
Yes!
With a Canvas object.
A canvas is basically an image you create while your game is running.
So instead of drawing things directly on the screen, you can draw it on a canvas first and then scale this canvas to fill out the entire screen.