|
Coldrice posted:whoh hey thanks! Yeah I keep updating my kickstarter, but I'm not really sure if people are that interested. I figure its such a small amount it'll either get funded, OR I'll have at least gotten some attention for my site/game. I watched the video and was thinking "I could see myself playing this a LOT on my commute to work, if only it was on 3DS/iOS" not realising until the last 2 seconds (because I don't read) that you're making it for iOS. 100% sold it for me.
|
#
?
Apr 25, 2013 08:46
|
|
|
|
| # ? May 12, 2024 13:52 |
|
|
Coldrice posted:Is it alright to post progress videos here? I made a video of some of the developments for my little cheesy game http://youtu.be/tFM-MJvPGzE Shalinor fucked around with this message at 16:21 on Apr 25, 2013 |
|
#
?
Apr 25, 2013 16:19
|
|
|
Are there any freely available block-based/minecraft-like engines or frameworks you can recommend? I'm thinking of writing an alife simulation in such a world and I'm looking for a good starting point.
|
|
#
?
Apr 25, 2013 19:12
|
|
|
scissorman posted:Are there any freely available block-based/minecraft-like engines or frameworks you can recommend? I suppose you want to use voxels? Check out voxeljs. I have not used it, but it is opensource and since it is javascript, it should not be very hard getting started either  Have you checked the minecraft-mod thread? That one contains quite a few resources about creating mods for the game (such as own blocks), but it might be a good place to start just to get the general idea. Edit: Check out their examples, for instance this baby allows you to enter a seed in the url. Also, a great thing about their examples are that the source is next to the example link. For instance, the above example is only 93 lines of code. DancingPenguin fucked around with this message at 19:39 on Apr 25, 2013 |
|
#
?
Apr 25, 2013 19:29
|
|
|
Shalinor posted:put your link in the kickstarter thread. Game looks awesome, and I'd never even have guessed you were running a funding drive from the first part of the video. I'd recommend moving the link in the video desc to the top / above the fold. In for $75  Alphabeardmicrobe incoming... or Qudcrobe. e: Visual Studio 4lyfe.
|
|
#
?
Apr 25, 2013 19:43
|
|
|
I use Vim myself  
|
|
#
?
Apr 25, 2013 19:44
|
|
|
DancingPenguin posted:I suppose you want to use voxels? Do you know how fast a javascript application like this runs vs traditional programming languages? DancingPenguin posted:Have you checked the minecraft-mod thread? That one contains quite a few resources about creating mods for the game (such as own blocks), but it might be a good place to start just to get the general idea. I thought about using Minecraft as a base but I see two problems with that: a) The simulation would primarily use a top-down, RTS-style camera, which is probably not what the engine is optimised for. b) I'm mostly interested in the simulation and thus want to keep the rendering simple. All the additional stuff in Minecraft would just take away from that.
|
|
#
?
Apr 25, 2013 19:54
|
|
|
Abalieno posted:I use Vim myself I use vim and it still hurts to look at that.
|
|
#
?
Apr 25, 2013 19:56
|
|
|
Abalieno posted:I use Vim myself Is that your setup or someone else's? If it's yours I may have to ask about it in some other appropriate thread or via PM
|
|
#
?
Apr 25, 2013 19:56
|
|
|
Coldrice posted:Is it alright to post progress videos here? I made a video of some of the developments for my little cheesy game http://youtu.be/tFM-MJvPGzE This looks pretty awesome. Might give you  on kickstarter, even though I personally do not own an iOS device.
|
|
#
?
Apr 25, 2013 19:57
|
|
|
Abalieno posted:I use Vim myself Preach it, brother. My favorite 'IDE' is a tabbed terminal emulator with a vim running in each one. If I need two on screen at the same time, I'll just drag a tab out temporarily.
|
|
#
?
Apr 25, 2013 20:11
|
|
|
SlightlyMadman posted:I use vim and it still hurts to look at that. The image shows the various features like Undo Trees, the file browser and the function browser. Otherwise it's pretty clean. It has some bright colors, but I find it really usable.
|
|
#
?
Apr 25, 2013 20:50
|
|
|
Abalieno posted:The image shows the various features like Undo Trees, the file browser and the function browser. Otherwise it's pretty clean. Haha, yeah it's a powerful editor, but I like to keep it simple. I didn't mean any offense of course, don't want to start a browser war! This is my workspace, which sounds a lot like xzzy's as well: 
|
|
#
?
Apr 25, 2013 21:03
|
|
|
Oh hey I totally forgot that this thread was probably a good place to show my latest update, since it's a bit more on the technical/infrastructure side (instead of adding pretty flashy things). Hopefully I can get some feedback and/or suggestions. In my last blog post I have an explanation of my system for adding new behaviors (i.e. game objects that aren't just simple tiles). Here is a video of my start-to-finish workflow once I have an art asset in place. Yes, this includes programming, but I purposely used an extremely simple example so that the video wouldn't be full of typing code. https://www.youtube.com/watch?v=QBBI0v8zbr8&hd=1
|
|
#
?
Apr 25, 2013 21:28
|
|
|
Orzo posted:Yes, this includes programming, but I purposely used an extremely simple example so that the video wouldn't be full of typing code. Do you goons think that (many) engines will aim for less programming in the future and simply aim for as much drag-n-drop as possible? Feels like new game engines are available everyday through Steam and such, and while Steams target market might not be the best example, it really feels like these engines are on the rise. I tried Unity before switching to Ogre3D (Which on the other hand is not a "game" engine.), and their tutorials really surprised me. Parts of them were almost like "Yea, so just drop this code into the file, this is way too advanced for you to ever understand". (Not trying to start a flame war against Unity users, I do know that there is a huge competence required for using that engine.) In short: Is programming slowly phasing out of game development?
|
|
#
?
Apr 25, 2013 22:14
|
|
|
Nope, being able to use code to develop is faster, easier, and more flexible. It's also easier for the writer of the development environment to implement since they just need to wrap to the native language. The only barrier is a person's refusal to learn something new. Just thinking about my early days using GM4.0 drag and drop is making my knuckles hurt.
|
|
#
?
Apr 25, 2013 22:21
|
|
|
Manslaughter posted:Just thinking about my early days using GM4.0 drag and drop is making my knuckles hurt. Oh lord, I think Gamemaker might have been what I used in my early days aswell. The memories.
|
|
#
?
Apr 25, 2013 22:48
|
|
|
Not to mention that even with a tool like Unity, you can only do so much with drag-and-drop. At some point you're going to have to open a text editor if you want to do something complicated. You can still do plenty with drag-and-drop, but it's finite. Also, the reason the tutorials say "just drag this here, don't worry you'd never understand it" is because there's a strong learning curve, especially before you get into any real coding. I've been programming for 27 years, and I still didn't understand what the hell was going on in Unity until I sat down and went trough some stupid tutorials. That's just how learning works, you have to start with the stupid basics and work your way up. That said, I do wish there were more in-between tools, like XNA or PyGame, that gave you full control in code without having to learn an IDE, but still have a ton of helper libraries so you don't have to push every single pixel by hand.
|
|
#
?
Apr 25, 2013 22:53
|
|
|
DancingPenguin posted:This made me think of something. It is completely unrelated to Orzos video/post, just something I have been thinking about. No. Every once in a while people try to come up with fancy "visual" languages under the guise of them being simple, and while the idea tends to appeal to those who are new to programming or those want to get into programming or those who want to avoid programming, they are mostly just air that experienced programmers ignore. To be clear, it's not that programmers are those grumpy "back in my day, we had to type things" kinds of people who want to do things the hard way, it's that we simply want to do things. In practice, for even trivial problems, you need to easily be able to create branches and loops, often with arbitrary conditions. You will also find it beneficial to create and specify explicit abstractions. You will want to create your own algorithms and have programmatic ways to deal with redundancy. The list of things that are difficult to do with simply drag-and-drop functionality is enormous. Unless you're expecting to drag-and-drop equivalents of control statements like if or for, and have a visual way of creating more general imperative or functional code, you're going to be extremely limited, and if you are expecting to be able to do those things visually, you're going to find that manipulating those objects is no less complicated than simply writing the word "if." In fact, you'll likely find it much worse. The only real, practical exception I can think of concerning visual languages is as an interface to declarative languages and simple markup languages since they lack control flow. Something like dealing with the format of a tile-based map is a good example of this. In fact, it's probably just getting stored as xml or something similar underneath the hood. Perhaps if there were some really high-level, declarative language in the domain of game development that covered every possible type of thing you could ever do in a game, which, mind you, is the same set as anything you could ever do in any program, it could become a reality. Not only is that completely unreasonable, but the... vocabulary of that language would be intractable -- visual or otherwise. There's a reason why declarative languages are often very domain-specific. In other words, unless we get some really intelligent AI that can do all of the programming work for you when you give it a high-level description, making a game will never be as simple as Geordi makes it seem when "programming" the holodeck.
|
|
#
?
Apr 25, 2013 23:08
|
|
|
I have fairly strong opinions on the subject, but I am probably biased as hell since I'm a programmer. And my opinion is that drag-and-drag interfaces aren't going to get you beyond relatively simple and generic games. The reason for this is because those drag-and-drop interfaces are simply abstracting away common commands to allow you to design workflows around a limited set of actions. You might counter-argue with 'but those actions are getting more and more sophisticated'. Well, yeah, they are. But the more sophisticated and flexible they get, the more they start resembling actual programming. After all, when you're programming, you're really doing the same thing, just at a different level. But when you try to shove that into a graphical designer...it just doesn't work as well as a real IDE would. In the end, I believe the type of abstract thinking required to translate a set of commands and behaviors into, for example, the way an enemy moves and attacks, is pretty much the same type of thinking required to do actual programming. Orzo fucked around with this message at 23:15 on Apr 25, 2013 |
|
#
?
Apr 25, 2013 23:12
|
|
|
That Turkey Story posted:To be clear, it's not that programmers are those grumpy "back in my day, we had to type things" kinds of people Those kinds of people exist in every area of employment ever. But I do completely agree with you, text does make it easier. I do have very little experience from visual programming, but from what I got I quickly realised that I could create the same program with text in half the time. And from that point I just stuck with text. Orzo posted:I have fairly strong opinions on the subject, but I am probably biased as hell since I'm a programmer. And my opinion is that drag-and-drag interfaces aren't going to get you beyond relatively simple and generic games. The reason for this is because those drag-and-drop interfaces are simply abstracting away common commands to allow you to design workflows around a limited set of actions. This pretty much sums up my thoughts about it as well. For instance with games I see a lot of 2D-games with really lovely everything that just seems to have been rushed through for instance GM. (One also sees a lot of good ones, but it feels like the actual game and mechanics of it rarely is in it, usually these tend to focus on story or such.) I will not counter-argue, since I am also pretty biased, but I do feel like your response to said counter-argument was really logical. I do personally not believe that they will get way too similar with actual programming since that would not be profitable due to killing off their target market. On the other hand, it might turn out to be a great starting point for actual programming in a few years! SlightlyMadman posted:Not to mention that even with a tool like Unity, you can only do so much with drag-and-drop. At some point you're going to have to open a text editor if you want to do something complicated. You can still do plenty with drag-and-drop, but it's finite. This was what I was trying to "tell" in my original post, I am not trying to bash on Unity users in any way, since I do know that a great game (in regard to programming and mechanics of the game) will always require manual programming as well in Unity. And as for those tutorials, it was most likely my own fault. Basically it was some "FPS for beginners in Unity", and I felt a bit confused over how this could be done already at a beginner level. But that might just be a neat thing to show off for new users. Like "Hey, look at this awesome FPS. You could create one too!". So I am probably completely wrong for saying that they were a bit weird, since those very parts might be covered in a later tutorial. I chose to go with Ogre3D instead, and I have taken the same path as you, going through those stupid basic tutorials/instructions. And indeed, the nice thing about it is when you after a while realise how much you are going to need that little part that the awfully boring tutorial taught you. I am off for the night, sleep well everyone!
|
|
#
?
Apr 25, 2013 23:39
|
|
|
I tried Stencyl, a mostly-drag-and-drop Flash game thing, and even if it wasn't a buggy piece of crap it was basically identical to programming, dragging and dropping your 'if' and your 'while' loops, only it took ten times longer than normal programming because you can type 'if ()' a lot quicker than you can find it in a menu and drag it to an appropriate place. The one thing it does make easier is that it also implements a component system. So basically like Unity does, only buggy and trying to disguise the actual programming part. That one aspect of drag and drop is really quite useful, along with the "level editor" functionality you get from Unity. I can't say how many times I've got bored of making a game when it comes to the "gently caress now I need to make a level editor" step, so having that just there as part of the environment is super valuable to me. What blows my mind is that they haven't done the same thing for making a menu system. I'm sure there must be something for it in the asset store, but it's crazy that their main GUI interface is programmatic, when that's another of the few things that genuinely benefits from a drag and drop editor.
|
|
#
?
Apr 25, 2013 23:50
|
|
|
SlightlyMadman posted:Haha, yeah it's a powerful editor, but I like to keep it simple. I didn't mean any offense of course, don't want to start a browser war! If we're posting our workspaces I'm posting mine because it's sweet and god that one vim shot was loving awful up there 
|
|
#
?
Apr 26, 2013 00:39
|
|
|
BGM1-004.mp3 is your favorite song too? I can't get it out of my head!
|
|
#
?
Apr 26, 2013 01:25
|
|
|
Orzo posted:You might counter-argue with 'but those actions are getting more and more sophisticated'. Well, yeah, they are. But the more sophisticated and flexible they get, the more they start resembling actual programming. After all, when you're programming, you're really doing the same thing, just at a different level. But when you try to shove that into a graphical designer...it just doesn't work as well as a real IDE would. Something like the Blizzard game trigger systems is a nice example, the actions set off by them are usually fairly simple, but you can add a lot of flexibility to them via the GUI editor and it's allowed level designers to do interesting things, but the main reason it works is because it's small, and the bindings to the game world are implicit, so you don't have to do stupid bullshit like tag everything with an ID and then have your code find them by ID or whatever.
|
|
#
?
Apr 26, 2013 02:38
|
|
|
Fairly simple and not especially game-related question except in that I'm doing it for a game - if I have a string approximately 2MB in size, and I want to parse it essentially by reading everything to the next space, then one character, then everything to the next space, then one character, repeat until the end, is an indexOf / substr combination going to be the best way, or is there something that'll do a faster job of it?
|
|
#
?
Apr 26, 2013 06:09
|
|
|
What language?
|
|
#
?
Apr 26, 2013 06:14
|
|
|
Orzo posted:What language?
|
|
#
?
Apr 26, 2013 06:16
|
|
|
indexOf/substr will work for that scenario, but you should really use split, and if that's not good enough for some reason, use regular expressions.
|
|
#
?
Apr 26, 2013 06:46
|
|
|
roomforthetuna posted:Fairly simple and not especially game-related question except in that I'm doing it for a game - if I have a string approximately 2MB in size, and I want to parse it essentially by reading everything to the next space, then one character, then everything to the next space, then one character, repeat until the end, is an indexOf / substr combination going to be the best way, or is there something that'll do a faster job of it? Why do you need substr? indexOf gets you the next space, then you use charAt to read the character after the space, and then do whatever you want with the data in between that and the next index. Perhaps you want to use a binary file format that you parse with ArrayBuffer? I don't know.
|
|
#
?
Apr 26, 2013 07:14
|
|
|
What's the preferred way to render top-down terrain? I'm thinking of partitioning it in chunks, store those in a x,y map and render only the chunks lying inside the view. Anything more involved like quadtrees is probably not worth it.
|
|
#
?
Apr 26, 2013 09:20
|
|
|
scissorman posted:What's the preferred way to render top-down terrain? This should work out just fine, really. It's a pretty cheap algorithm and the player isn't going to notice if you do it right.
|
|
#
?
Apr 26, 2013 11:05
|
|
|
scissorman posted:What's the preferred way to render top-down terrain? As long as you have some basic terrain outside of the view, that should work excellent. Or did you mean rendering every chunk in the complete render distance? What my question really asks is if the player will perhaps only see textured ground beneath his feet (or a 20-yard radius or whatever you might use), or do you mean rendering everything that is viewable? I play way too many lovely games.
|
|
#
?
Apr 26, 2013 13:41
|
|
|
scissorman posted:What's the preferred way to render top-down terrain?
|
|
#
?
Apr 26, 2013 14:35
|
|
|
DancingPenguin posted:This made me think of something. It is completely unrelated to Orzos video/post, just something I have been thinking about. However there has definitely been a rise in popularity in "drag'n'drop game-making tools" lately (I wouldn't put Unity in that category though, but stuff like GameMaker, Stencyl, MMF2, RPG, etc). While most of us here are programmers and see them as just more complicated ways of doing branches and loops and functions, to a lot of people programming is just ugly, they don't get it or don't want to, and to them these tools are a lot more appealing and intuitive. Even if they just result in more work down the road, they will happily brute-force and copy-paste their way through them to make their dream games, and a lot of them even get quite successful. So I guess it's just different strokes for different folks. 
|
|
#
?
Apr 26, 2013 14:35
|
|
|
Orzo posted:Yeah that's called a spatial hash or a hash grid, they're much easier to implement than quadtrees and in some cases actually have advantages. EDIT: VV spatial hashing requires that any item in a bucket not go so far beyond the bucket's edges as to be problematic, unless you're drawing a bunch more buckets than what strictly fits in screen EDIT: regardless, yeah, this is only worth talking about if you're going to chuck more in than terrain. Shalinor fucked around with this message at 14:53 on Apr 26, 2013 |
|
#
?
Apr 26, 2013 14:41
|
|
|
Spatial hashing doesn't require that each item fits into exactly one grid square, so that example would work fine. As for 'why', I dunno, they both have their advantages. Quadtrees aren't super hard to implement, but they are definitely more complex than grids, and they can also be more difficult (and expensive) to maintain if you have a lot of moving things (dunno if scissorman is using this just for terrain, or for all things).
|
|
#
?
Apr 26, 2013 14:44
|
|
|
Are Crabitron avatars the new cool thing now?? I always miss out on new cool things.
|
|
#
?
Apr 26, 2013 14:57
|
|
|
Yodzilla posted:Are Crabitron avatars the new cool thing now?? I always miss out on new cool things. 
|
|
#
?
Apr 26, 2013 15:22
|
|
|
|
| # ? May 12, 2024 13:52 |
|
|
Orzo posted:Spatial hashing doesn't require that each item fits into exactly one grid square, so that example would work fine.
|
|
#
?
Apr 26, 2013 17:00
|
|