|
I've been learning C++, and I've gotten pretty decent with it! I have an idea for a simple first person shooter game, and am eyeing the original Doom engine to work with... but I have a question... If I was working with the Doom Engine, there are tons of editors that will allow you to create and edit .wads and reskin things. I don't just want to make a Doom mod though, I want to make my own game, you know? Something I made. With that in mind, can I use the .wad editors? At what point does it stop being "A Doom mod that Griff made," and start being "This cool game that Griff made!"? I'm planning on reskinning and retexturing everything, adding a whole new sound library, also new features I'd like to program in (hopefully I can use C++ for this). I just want to have something that I can say "I made this," you know? Also, this would be my first "real" game project, so I'm sure I've made some hilariously flagrant mistakes. Oh well, I wanna get my hands dirty! What do you all think?
|
#
?
Feb 14, 2013 20:48
|
|
|
|
| # ? May 12, 2024 10:56 |
|
|
Radical Griff posted:I've been learning C++, and I've gotten pretty decent with it! Yes. The answer to this question will become more obvious as you get more experience. Modding involves altering code (AI, new weapons, new mechanics, add vehicles, whatever your imagination comes up with), I'd saying that modding isn't the right word for just editing wads, "re-skinning" or "texture mod" would be describe mods that just offer replacement models and textures and skins. My first mods were for Half-life 
|
|
#
?
Feb 14, 2013 20:57
|
|
|
Well I was planning on adding enemies, a new communication feature, a new weapon, etc. I'm not entirely sure the best way to do this using the Doom Engine though. If .wad editors aren't the answer, what is? My C++ experience consists of making various programs on my own, I've never tried to work with code like the Doom engine before.
|
|
#
?
Feb 14, 2013 21:03
|
|
|
Radical Griff posted:Well I was planning on adding enemies, a new communication feature, a new weapon, etc. So since you are pretty new there are a whole bunch of revelations that you are going to have about just basic interopability of programming before the game stuff revelations even start happening, things like SDK's, extern calls with DLL's, etc. See, the game programmers were cool enough to allow certain external entry points for independent hobbyist programmers to extend and override existing code. Google "doom sdk" and "doom coding tutorial" or "doom weapon tutorial" or something like that. There has gotta be ton's of stuff. Doom modding is probably in a college textbook by now. e: Also I think I need to clear something up for you: on top of the programming you will also be using whatever wad and level editors you like, unless you want to use the existing maps with all of their already existing entities but are running your code (AI in this case) to help them think. ee: Oh and also to clear something else up: it stops being a mod when you license the engine. Then you get to say it's your game. But really, most games are mods if you think about it. All those games that use the Unreal, FarCry, Quake, Source, etc engine are actually just like mods but the developers paid alot of money to have really well integrated support and branding. KoRMaK fucked around with this message at 21:22 on Feb 14, 2013 |
|
#
?
Feb 14, 2013 21:18
|
|
|
Awesome, thank you so much. You're a godsend!
|
|
#
?
Feb 14, 2013 21:20
|
|
|
edit: Wrong thread, sorry
|
|
#
?
Feb 14, 2013 21:20
|
|
|
KoRMaK posted:ee: Oh and also to clear something else up: it stops being a mod when you license the engine. Then you get to say it's your game. But really, most games are mods if you think about it. All those games that use the Unreal, FarCry, Quake, Source, etc engine are actually just like mods but the developers paid alot of money to have really well integrated support and branding. Since I'm assuming the original Doom engine is freeware by now, does that mean my project can be more than just a mod, since you can't license an engine that's...free... Thanks so much for your input!
|
|
#
?
Feb 14, 2013 21:25
|
|
|
You will have to check the license (GPL, MIT, etc) but I don't think you will be able to charge people for it, and you might have to give credit in the readme to the engine (this will be covered in the license). MIT is the most chill because it lets you do whatever, so long as you mention them once. GPL makes you release your source code with every binary which is good for academia but not (all) commercial applications. If you take a look at the Dorner game posted earlier, it's based on a "Free Doom" which I assume is almost open-source and might even be where you want to start. A user that wants to play your game won't need a previous install of Doom, so you will be able to package it as one download via your own means of distribution (while adhering to the requirements of the license e.g. to distribute source with binaries or not) e: Sorry free Doom might not be the place to start, this looks better http://www.chocolate-doom.org/wiki/index.php/Chocolate_Doom http://www.chocolate-doom.org/wiki/index.php/About Looks like the Doom source was released in 1998 so go hog wild. ee: even more "source ports" http://doomwiki.org/wiki/Source_port for the Doom engine KoRMaK fucked around with this message at 21:35 on Feb 14, 2013 |
|
#
?
Feb 14, 2013 21:29
|
|
|
Shalinor posted:Right now, it has me thinking I might actually want to dust off shadow volumes, but can anyone think of a better approach? Bonus points if it supports self-shadowing? I'd love to use something newer and fancier, but most recent shadow algorithms focus on realism rather than style. Personally, I think the best option would be do PCF (or similar) and use the result as a lookup into a 1D texture that's half-white half-black. Doing that should allow anisotropic filtering to prevent aliasing on the threshold. The shadows will be a bit rounder compared to stencil shadows if you do that too, which may or may not be what you want. If you need it to be as cheap as possible, then you can just do the the thresholding directly in the shader or just subtract 0.5, multiply the result by a big number, and saturate. OneEightHundred fucked around with this message at 22:18 on Feb 14, 2013 |
|
#
?
Feb 14, 2013 22:12
|
|
|
I have a handle class similar to what is described here that I've called Index (I should probably change it to Handle or something, but whatever). It is a templated class that holds an integer as an index into an array in a manager, basically. It also has a static pointer to the manager that matches the template parameter so I can overload the -> operator and get easy access to the object itself. It's worked pretty well so far, but I've run into a problem. I've got a work around, but I'm hoping there is a better solution. I've been working on a component system that has various components derived from a base Component class. I have an Entity class that holds a list of Index<Component>. The base Component class doesn't have a real manager, so the manager pointer in Index<Component> is null and trying to actually use an Index<Component> in that form would be an error. The integer index is correct, so if it knew what manager to use, you could still get the component you wanted. To get an Index<Component> back into a Index<MotionComponent>, for example, I've written a cast function that just returns a new Index of the type you request, which is super sketchy since the only way I could think of to type check it would be to use the -> operator to get the raw pointer and try to cast it to the requested type, which doesn't work because the manager pointer is null. So for now, it just gives you the Index you requested, regardless of what type it actually is. It shouldn't be a problem if I never get the cast wrong, but I don't like leaving it like that. I also end up having to cast back and forth whenever I want to add or remove a component, which isn't ideal either. Anybody have any good suggestions? I can post as much code as needed if it makes it easier.
|
|
#
?
Feb 15, 2013 18:09
|
|
|
Got a game math question for you mathematicians out there. I'm working on generating tilemaps on the fly and I'm dividing my tilemaps into regions to conserve memory and only load a certain number of tiles around the player. Say my region sizes are 50x50 for simplicity. So region (0,0) would be have tiles from x position 0 to 50 and y position 0 to 50. Each tile is 16x16. So technically a region of 0,0 would be 800x800 pixels. What I'd like to do is make it so that when the game starts it only generates the regions surrounding the player, kinda like this: xxx xpx xxx When the player moves into a new region the regions that no longer need to be in the game will be removed and new ones will be added based on which region the player has moved to. How can I figure out which region my player is in based on the player position?
|
|
#
?
Feb 19, 2013 07:32
|
|
|
I would probably do it something like this: First I'd calculate the players tilemap position tilemapPosition = Math.Round(player.position/16) then I'd do this for the region position regionPosition = Math.Floor(tilemapPosition/50) I'm not a math wiz but something like that might work 
|
|
#
?
Feb 19, 2013 07:39
|
|
|
SuicideSnowman posted:Got a game math question for you mathematicians out there. I'm working on generating tilemaps on the fly and I'm dividing my tilemaps into regions to conserve memory and only load a certain number of tiles around the player. Say my region sizes are 50x50 for simplicity. So region (0,0) would be have tiles from x position 0 to 50 and y position 0 to 50. Each tile is 16x16. So technically a region of 0,0 would be 800x800 pixels. What I'd like to do is make it so that when the game starts it only generates the regions surrounding the player, kinda like this: Is your player "position" a tile, or a pixel? If the former, you just take the floor of the player's position divided by 50. If the latter you need to divide by (50 * 16) instead.
|
|
#
?
Feb 19, 2013 07:39
|
|
|
Svampson posted:I would probably do it something like this: I knew it should be simple but I couldn't wrap my mind around it for some reason. That worked perfectly. Thanks to both of you. SuicideSnowman fucked around with this message at 07:54 on Feb 19, 2013 |
|
#
?
Feb 19, 2013 07:47
|
|
|
Unity questions: Do I need to shell out the $400 apiece to deploy to Android/iOS, or are those just extra feature sets for those platforms? That's a really prohibitive price point for me as a student.
|
|
#
?
Feb 19, 2013 20:34
|
|
|
Above Our Own posted:Unity questions: Do I need to shell out the $400 apiece to deploy to Android/iOS, or are those just extra feature sets for those platforms? That's a really prohibitive price point for me as a student. From the FAQ: Subscriptions to student licenses are available through Studica. We also have educational licenses available to accredited educational institutions. Schools can contact us using our contact form for more information. Note that reduced-price versions available through Studica have a single activation and not the two activations that you get when you purchase a full-price Unity from the unity3d.com web store. Here's the Studica link: http://www.studica.com/unity
|
|
#
?
Feb 19, 2013 20:50
|
|
|
Pathfinding isn't easy. Well A* is simple enough, but the real issue comes down to the graph that you work on. I'm making an RTS and I didn't want to have it be "grid based" (think Warcraft 2) for lack of a better term. What I'm going for is having units being able to move freely, and not have to walk along a grid or stop on individual grid points. My first attempt was something like this:  So here the blue areas are impassable, the red dots are the nodes and the green lines are the edges. The basic idea is that if you construct your impassable areas as polygons then the only edges you need for A* are those that connect nodes and which don't intersect walls (actually you can prune more edges but it's sort of complicated to explain. I can get into that if someone's curious). When you want to pathfind between two points you just add them to the network and run A*, then remove them. You can see a path there in blue. The problems with this are that it scales very poorly (the number of edges connected to a node goes as ~n2) and that it doesn't handle moving units very well (which is compounded by the poor scaling). Units have to be part of the network if you're going to pathfind around them. If units move then the network has to be reconstructed before you can pathfind and that means checking all the potential edges connecting the nodes that move with the unit to the remaining nodes in the network. Every potential edge has to be checked against every wall so it quickly becomes unreasonable. So then I started thinking maybe I'd do something grid based, but then smooth out the results, like this:  So the idea here is that you do A* on a traditional grid, and then walk backwards from the end to the beginning and find the longest leg to the start node that doesn't intersect any impassable tiles (here I've smoothed out all the parts of the path, but that really only the first part matters: once the unit reaches the end of that part it'll just pathfind again and have a new direct line). The problem with this is that tiles are either "passable" or "impassable," so what do you do with a unit that isn't at the exact center of a tile? The only solution seems to be having all tiles it touches be "impassible" which makes for situations where a unit should clearly be able to pass between two other units but can't because they slightly overlap a tile in between them. There doesn't seem to be any way to fix it without having an unnaturally large space between the units, or forcing them to snap to a grid which is what I wanted to avoid in the first place. Anyway I finally settled on this:  This isn't the best picture because two paths are touching (that unit in the bottom right is going off to the left), but the basic idea is to start with a grid based mesh and then alter it near obstacles/units. As units move they update the local grid. After the pathfinding is done I find the longest straight line as before. The good thing about this are that it's more scalable because as the units move they only modify the local grid, so you only have to check a few nodes and walls whenever the unit moves as opposed to every node/wall. This seems to work very smoothly right now. Anyway I just thought I'd share in case anyone else was having similar issues. Does anyone have any other suggestions/good reading material on this? Most of what I found on google was similar to my first two implementations.
|
|
#
?
Feb 20, 2013 22:55
|
|
|
HappyHippo posted:Does anyone have any other suggestions Doing that, you should never have an overlap between units. Each has a zero point that should be within a particular grid, which you mark as blocked. It does mean that two units could pass pretty close, if each was in the "corner" of their respective grid, but in practice you almost never notice those edge cases. EDIT: VV *shrug* it was standard practice in the old days, and most of the old tricks still work in indie space. I wouldn't use it on a AAA RTS where you could zoom in on the pores of your soldiers, but for most use cases, it'd probably be fine. Start simple, only add complication when the simple solution proves to be insufficient. Shalinor fucked around with this message at 23:19 on Feb 20, 2013 |
|
#
?
Feb 20, 2013 23:05
|
|
|
Yeah I considered that but how sure are you that you'd never notice it in practice? It means the units could get arbitrarily close if the grid line falls between them. I could see it happening a lot. Edit: There's also another weird situation to consider. Even if you only consider the unit to be in "one" cell, the algorithm that finds the longest straight path section doesn't really make that distinction. It just checks two parallel lines near the unit to see if they intersect any impassible tiles. If the unit is overlapping with some other tiles, and other units move into those tiles, then now the intersection detection will fail in all cases and the unit will be trapped. You could add more code to handle this maybe but it starts getting messy. HappyHippo fucked around with this message at 23:18 on Feb 20, 2013 |
|
#
?
Feb 20, 2013 23:11
|
|
|
HappyHippo posted:Yeah I considered that but how sure are you that you'd never notice it in practice? It means the units could get arbitrarily close if the grid line falls between them. I could see it happening a lot. (Essentially this is the same as saying "each unit has a radius that is smaller than a square, and blocks any square it overlaps with") You could also achieve better results still by marking a square "partially blocked" and only consider it actually blocked if the two units will actually overlap, possibly by reducing any partially blocked square into smaller squares for the purpose of resolving such things. roomforthetuna fucked around with this message at 23:21 on Feb 20, 2013 |
|
#
?
Feb 20, 2013 23:18
|
|
|
roomforthetuna posted:You could also do half way between those two options without it being too silly - since you already have a unit covering all four squares it overlaps with, instead make a unit cover only squares it overlaps more than X% with (ie. if the unit's center in the middle (100-2X)% of a square then it only blocks that one square). With an X of 50 that would keep units from touching at all, and in the absolute worst case would keep them one full square apart, identical to what you already tried. With an X of 25, units could overlap by half a unit at worst, and be blocked by a unit a half square away at the other worst. Then you could tune it to get the most acceptable result. Yeah, there's lots of potential solutions, it's going to increase in complexity one way or another I think (how do you handle your partially blocked cells in the actual pathfinder?). The solution I have now isn't particularly complicated right now and works very well so far (most of the complexity comes from creating the nodes near lakes generated by the random map generator. I used marching squares). I hadn't read about anything like the one I went with so I figured I'd post it.
|
|
#
?
Feb 20, 2013 23:31
|
|
|
HappyHippo posted:Yeah, there's lots of potential solutions, it's going to increase in complexity one way or another I think (how do you handle your partially blocked cells in the actual pathfinder?). The solution I have now isn't particularly complicated right now and works very well so far (most of the complexity comes from creating the nodes near lakes generated by the random map generator. I used marching squares). I hadn't read about anything like the one I went with so I figured I'd post it. How does your "make a straight line" part that's outside of the A* grid resolving work? Is that based on unobstructed "pixels" of the grid? Given that units clear a node-space around themselves, how do you allow them to move - do they remove their own node-alterations before they start pathfinding, or have a private node at their own center that connects to all their border nodes, or what? (I guess a wall would have a node-radius like the one a unit does, and just water is a special case that allows you to get your center right up next to the edge, right?) Edit: what does the diagram look like when two units are next to each other such that their zones of blockage intersect, and what does it look like when they're next to each other such that their zones don't quite intersect?
|
|
#
?
Feb 20, 2013 23:58
|
|
|
roomforthetuna posted:Yeah, your solution actually looks pretty good, like it has almost the accuracy of the first option without the downside of the crazy amount of stuff to update when things move. Plus allowing you to walk right up to the water's edge rather than only into the nearest empty square. Basically each cell has nodes, edges (which join nodes) and walls. The constraint is that no edge can ever intersect a wall. When it comes time to do the "make a straight line" I find all the cells a line intersects, and for each cell I check if the line intersects any of its walls. quote:Given that units clear a node-space around themselves, how do you allow them to move - do they remove their own node-alterations before they start pathfinding, or have a private node at their own center that connects to all their border nodes, or what? Yeah they remove their "box" and then pathfind. That's also how movement is done - remove the box and then add it at the new position. quote:(I guess a wall would have a node-radius like the one a unit does, and just water is a special case that allows you to get your center right up next to the edge, right?) Not quite sure I understand this question. Using the terminology above, the lake borders are made of walls, with nodes (and edges) just beyond those walls. The unit boxes are similar. quote:Edit: what does the diagram look like when two units are next to each other such that their zones of blockage intersect, and what does it look like when they're next to each other such that their zones don't quite intersect? The situations look like this, respectively (I've removed the box representing the unit, the red area is the exclusion zone):   The interesting thing is that when they overlap sometimes some edges are left over inside them (this also happens when the box is bigger than a cell). But it doesn't matter because the constraint that no edge intersects a wall keeps those nodes from connecting to the network at large. Edit: These are from before I started building the game on top of it. Here's what it looks like now: 
HappyHippo fucked around with this message at 00:39 on Feb 21, 2013 |
|
#
?
Feb 21, 2013 00:34
|
|
|
HappyHippo that is some great stuff that I am trying to wrap my head around. One thing I don't understand is how do you generate the grid around the edges of your impassible zones? Do you walk a unit around with it's collision detection, or do you use a walking cubes kind of algorithm but in 2D? By that I mean you create the grid with vertex's with uniform edge lengths, then see if any overlap with an impassible zone. If they overlap completely you remove it, if it's only partial you move them in some direction until they are out? e: There were two articles that I read a while ago when I first tried learning path finding. I thought I wanted A* but realized that Djistrka's was more appropriate. These articles went into nav meshes which I didn't need, didn't understand, but really wanted to. The biggest problem for me is figuring out how to generate the mesh automatically. I went searching around and am amazed that I found the second article. http://www.ai-blog.net/archives/000152.html http://theory.stanford.edu/~amitp/GameProgramming/ KoRMaK fucked around with this message at 01:08 on Feb 21, 2013 |
|
#
?
Feb 21, 2013 01:01
|
|
|
KoRMaK posted:HappyHippo that is some great stuff that I am trying to wrap my head around. One thing I don't understand is how do you generate the grid around the edges of your impassible zones? Do you walk a unit around with it's collision detection, or do you use a walking cubes kind of algorithm but in 2D? By that I mean you create the grid with vertex's with uniform edge lengths, then see if any overlap with an impassible zone. If they overlap completely you remove it, if it's only partial you move them in some direction until they are out? Thanks, I used marching squares, the 2d version of marching (or walking) cubes, to create the mesh around the lakes. You start with a uniform mesh, and then eliminate nodes in impassable regions, and then add new ones along the cell borders with marching squares.
|
|
#
?
Feb 21, 2013 01:05
|
|
|
HappyHippo posted:Not quite sure I understand this question. Using the terminology above, the lake borders are made of walls, with nodes (and edges) just beyond those walls. The unit boxes are similar. Edit: also neat, that in your system you can make units different shapes or have their rectangles rotate when they turn or the like, since the pathbuilding algorithm could work around whatever shapes you throw at it. Edit2: how well does it handle "there is no path" situations? I realize this is a thing of A* in general that won't really differ for yours, but since you're having a fairly large nodemap it seems like it might be nasty. (Though looking again, I guess you don't really have all that many nodes, just a lot of joins. And not even really all that many joins, just more visualized joins than I'm used to in an A*.) roomforthetuna fucked around with this message at 01:37 on Feb 21, 2013 |
|
#
?
Feb 21, 2013 01:30
|
|
|
I'm trying to wrap my head around how to disconnect a unit's node system from the world node system. It looks like some unit's still have a grid under them and other's don't. But I can't be sure because it could just be the way the units are oriented. Why are there so many node's bunched in the area marked with the black circle around the lake? It looks like there are more edges than there should be. How many edges are used to define a square? It looks like 6, I highlighted them. But if you look at the other one I marked down near the bottom left, it looks like there is double; 2 edges for a pair of connected nodes.  I also don't get what values they are using in last step of linear interpolation.  http://en.wikipedia.org/wiki/Marching_squares KoRMaK fucked around with this message at 02:29 on Feb 21, 2013 |
|
#
?
Feb 21, 2013 02:01
|
|
|
HappyHippo posted:Anyway I just thought I'd share in case anyone else was having similar issues. Does anyone have any other suggestions/good reading material on this? Most of what I found on google was similar to my first two implementations. Left 4 Dead uses something called "Reactive Path Following" -- http://www.valvesoftware.com/publications/2009/ai_systems_of_l4d_mike_booth.pdf pg 14 Modifying the navigation mesh to avoid collisions seems harder than just doing collision tests directly.
|
|
#
?
Feb 21, 2013 04:58
|
|
|
Scaevolus posted:Modifying the navigation mesh to avoid collisions seems harder than just doing collision tests directly. If you just do collision tests, then if a bunch of units are blocking a narrow pathway you'll just keep bumping into them as opposed to finding a path around.
|
|
#
?
Feb 21, 2013 05:18
|
|
|
yaoi prophet posted:If you just do collision tests, then if a bunch of units are blocking a narrow pathway you'll just keep bumping into them as opposed to finding a path around.
|
|
#
?
Feb 21, 2013 07:37
|
|
|
Maybe if you don't know how to micro. 
|
|
#
?
Feb 21, 2013 08:17
|
|
|
That could be solved by either "grouping" entities into tasks of similar nature or somehow calculating the rough time it'll take for the entity blocking the corridor to move vs the time it takes to go around.
|
|
#
?
Feb 21, 2013 08:24
|
|
|
Another solution would to be to add a weight to your lathing options so that waiting at the bridge is cheaper than walking around to another bridge. This is what I did in a roguelike prototype to prevent enemies from walking around the map once another enemy stepped into a single width hallway towards a player.
|
|
#
?
Feb 21, 2013 14:23
|
|
|
roomforthetuna posted:I was just getting at the fact that units have their path-walls a good distance out from the unit, while water has its right at the water's edge - if there was a brick wall object you'd presumably put its pathing walls further out, like for the unit, so that you don't end up with your units overlapping the bricks like they can with the water. Oh yes, that's true. I figured going up next to the water is fine in my game since they're tanks anyway and tanks can drive through shallow water, so seeing the tank part way in the water is realistic. If I didn't want that I could always push the nodes back from the water (easier said than done, but possible). Right now the "no path" situation seems fine. Right now it just reports failure but I plan to have it return the closest node in the future. No noticeable slow down or skips happen when there's no path. KoRMaK posted:I'm trying to wrap my head around how to disconnect a unit's node system from the world node system. It looks like some unit's still have a grid under them and other's don't. But I can't be sure because it could just be the way the units are oriented. In each cell every node is connected to every other node, unless there's a wall in the way. In a cell with 4 nodes that means 3 + 2 + 1 = 6 edges. If there are 5 nodes, then there's 10 edges. Cells have a methods to add/remove nodes and walls, afterwards they recheck all their edges to see which ones are allowed. quote:I also don't get what values they are using in last step of linear interpolation. Those are the original values, in the top left. HappyHippo fucked around with this message at 19:15 on Feb 21, 2013 |
|
#
?
Feb 21, 2013 18:31
|
|
|
This was a few pages (and therefore a few weeks) back but thanks to everyone who suggested LibGDX, it's great. It got me to actually make a game and while it is just a simple Tic-Tac-Toe clone, releasing something into the wilderness of the Play Store felt pretty drat satisfying.
|
|
#
?
Feb 21, 2013 18:51
|
|
|
edit: Nevermind, I fixed it.
Common Coder fucked around with this message at 00:48 on Feb 22, 2013 |
|
#
?
Feb 22, 2013 00:17
|
|
|
Unity pattern am-I-dumb check. So game object instantiation is taking a few seconds; so in order to not just have the game freeze up, I moved my scene init into a co-routine with a few "WaitForFixedUpdate" stops, and throw up the loading screen in OnGUI. Is this completely dumb, or a reasonable design pattern? You decide! e: I should use WaitForEndOfFrame instead, I guess. FixedUpdate is the physics step? Unormal fucked around with this message at 04:49 on Feb 24, 2013 |
|
#
?
Feb 24, 2013 04:43
|
|
|
Unormal posted:Unity pattern am-I-dumb check.
|
|
#
?
Feb 24, 2013 05:21
|
|
|
So I am wrapping up my first game for iOS, which I used cocos2d for. I'm totally new to programming as of last summer but I feel pretty confident with objective-c/cocos2d now which feels great! My current game is a little sparse gameplay wise but that's alright. I am plotting out my next project which I hope to make more full featured and fun! My question is if I want to make a more serious step into game development am I shooting myself in the foot with objective-c? I have no ability to port to android or pc which is my first concern. Second, I'm worried that "depth" isn't really necessary for the mobile market as much as a catchy casual game that can be played for a minute than put away. I like the "idea" of mobile games but I worry my ideas are better suited for the desktop than a phone. Thoughts? I can spend the next few months learning a new language and set of tools, or I can dive into the next thing. Not sure
|
|
#
?
Feb 24, 2013 08:01
|
|
|
|
| # ? May 12, 2024 10:56 |
|
|
 A really tiny thing I made in Haskell using netwire, GLFW, and lens (about 250 loc). You can move around and shoot projectiles, and that's it. I'm hoping to make it into an actual game, and maybe start up a development blog about it since game development is something there's really not a lot of in Haskell.
|
|
#
?
Feb 24, 2013 09:30
|
|