Blitzmax Open Project
BlitzMax Forums/BlitzMax Programming/Blitzmax Open Project
| ||
| I'm sure you've all seen suggestions for team projects before here. Often they end up as a huge discussion on what type of game to make, how to structure it, etc, and often they never really materialise. So I propose we try to basically set up a subversion server (sourceforge perhaps) and start coding before discussion. Gradually, as people steer it this way and that, the game will take shape on its own accord. I think it would be a good idea to establish a few general guidelines/rules: - No paid for modules, using them would exclude people people who don't have them. - Obviously nothing illegal - Try and keep everything multi-platform compatible - Don't rely on the features of a particular IDE. Specifically, don't use BLIde managed solutions; unmanaged ones are ok but it's probably best not to commit the actual solution file. Send me an email or post in here if you're up for it, and I'll add you to a sourceforge project if I get two people other than me (after I figure out how to use sourceforge). |
| ||
| A couple points... subversion This here's the first flaw in your plan. Subversion really isn't suited to this sort of thing. It's better for environments where you have a set team and such, not where anyone might jump in and go "hey, here's a patch/feature/fix/whatever." I will do my usual thing and recommend Git and Github/gitorious/etc., but the other distributed options are also good enough by now (I think.. maybe not bazaar, but at least Mercurial can hold its own). sourceforge perhaps And the second flaw. Sourceforge really will require that whole 'team' thing, and will just make contributing a gigantic pain. - Obviously nothing illegal This is unrelated, but I'm having a hard time imagining how you'd do something illegally in this case. |
| ||
| Although I think that many people have trouble enough trying to understand/use Subversion, I'll push for Github over SourceForge. What exactly do you want the project to be? |
| ||
This is unrelated, but I'm having a hard time imagining how you'd do something illegally in this case. Use a pirated piece of software, use copyrighted graphics, etc... There are a lot of ways you could do something technically illegal... |
| ||
| This entire forum post could be illegal. |
| ||
| This is definately cool. So.. what is to be done? |
| ||
| Without a clear direction for a project such as this you will end up with inefficiencies in the code (spaghetti in structure)... practically zero optimization and probably, eventually strange bugs. |
| ||
| recommend Git and Github/gitorious/etc Well I've never used Githum, but it seems to be more popular so I guess it should be fine. So, unless anyone else wants to set up a project there I'll go ahead and do it. What exactly do you want the project to be? A game. Other than that, there's no particular direction at the moment. Without a clear direction for a project such as this you will end up with inefficiencies in the code (spaghetti in structure)... practically zero optimization and probably, eventually strange bugs. You're probably right, but the idea behind this isn't to create something brilliant, it's really more an experiment to see what happens when you let a group programmers people do whatever they please to a project. The hope is that people will guide the project themselves by programming what the want, and people going along with it. Someone might steer it in the direction of a side scrolling shooter, then someone else might add loads of dinosaur-based vehicles, and so-on until we end up with a side-scrolling-time-travelling-dinasaur-strategy-shooter game. Or we might end up with a pong remake. Inefficiency and optimisation isn't really so much of an issue, although I'd like to think that as a group, we're competent enough to avoid spaghetti structure. |
| ||
| it's really more an experiment to see what happens when you let a group programmers people do whatever they please to a project. I don't think that will work so well with a programming project... |
| ||
| I don't think that will work so well with a programming project... Well there's only one way to truly find out, and that's giving it a go. I'd say this should be 60% make something interesting, 40% experiment. Or perhaps you could look at it as a cooperative programming game, I don't know. Anyway, I've created a github repository, and the clone url is git clone git://github.com/Spacerat/Blitzmax-Open-Project.git I'll start coding on it tomorrow since I have no time now, but feel free to get started if you want. |
| ||
| I love experiments. Stated that, i'd suggest to do more than a community experiment, and try out something technically awesome.. I know thats easy said.. but.. "give it a try", uh? I would really like to go enhancing NTGs fluid dynamics sim, or.. is it actually gonna be 2D or 3D? Just start coding, and throw your piece of code into the big code pit? |
| ||
| Well I'm not going to tell you what to do, but I'll suggest that we start something from scratch, as opposed to simply continuing something which already exists. That being said, if you could use this fluid dynamics sim as part of something bigger then I see no reason not to. As for 2D vs 3D, 2D is easier (for me, anyway), and more convenient, since we're using Blitzmax, but 3D is certainly not out of the question as long as you use a free 3D engine. And yea, just start coding. I'm going to start adding code tomorrow, but if you want to start then by all means do so. |
| ||
' Unknown Game with no direction While Not Keydown(KEY_SPACE) Print "Hello" Wend Print "Bang Bang, your dead." Ok... go from there... add whatever you wish.. Just stay on theme. |
| ||
| Thats harsh.. but true. All direction we have is 'nearly something is good, almost anything better, everything great'.. |
| ||
| Erm... you didn't even setup the project on GitHub correctly. |
| ||
| I doubt a general idea will work. my suggestions(just opinions): there needs to be some type of leadership. Letting everybody just throw a piece of code it's not going to work. The leader needs to assign tasks to himself and to others. Before that can be done, there needs to be an idea for what type of game its going to be made. as it stands, I could throw code for a 3d shooter, somebody else might throw code for a side scroller game, someone else a SHMUP or a Match 3 and on... Treat this as if it's a business(A fun business maybe but none the less a business). Get a group first(each person interested needs to commit him/herself put at least 5(just a number it can be anything) hours of work each week and a deadline to complet the task. it needs to be know that the programmer it's going to be responsible for the task and report progress on a regular basis. on the top of this thread get a list going to list the names of programmers who wants to join. Even before the group is set, start brain storming ideas for the type of game that is going to be made. 1st. I suggest to get a list of the types of games know off and get votes on each. I say on 3 game ideas with the most votes do the easiest one just to get the first project going. 2nd. Everybody needs to brainstorm it; everybody need to create a rough draft storyline. The ideas can either be combined together, select one and dump the others, or add to a main one from the others. It might be rough for someone that thinks his/her idea is the best and not be chosen but if it's going to be like a business than that is the way the cookie crumbles and everyone needs to be able to put up with it. 3rd. Get the modes, input(keyboard joystick and mouse controller done), and high score storage input output done. Possibly a nice but simple framework before the game is even started. I have noticed that all of the projects that get started here neglect that and at the end nobody wants to do it. this is where leader ship skills in delegating comes in hand. 4th. the leader should be able to direct the team programmers on how to get the individual's code in to the game to make it work. there should be guidelines for code to be accepted: Certain variables in certain format(such as in a type) to be passed back and forth between individual's code. 5th. just get it done. As long as no major bugs are found it should be considered ALPHA stage. At this point; speed slow, no problem; graphics suck, no problem; control not optimal, no problem. even though it is as I said it doesn't mean that each coders should not try to do their best. it's just that I believe that everybody wants to see some type of accomplishment and the best way to do it is by having their work in a finished product. At this point, work to improve and make it better. 6th. present it for criticism. what does everybody think of it? What type of bugs are found? What is missing to get it commercial quality? What can be done to satisfy a large crowd? take advice and suggestions and learn. 7th. lucky number :-). Do the team have enough talent to get a commercial project out? if Yes. wha are you waiting for? Get started! if not, are talented people willing to enlist now that there is a finished project? If yes, Do it! If not, at least everybody here learned, what in my opinion is, a nice business model or maybe not. It might just be my inexperience peeking out. Hey, I take suggestions. ************************************************************************* those are only Ideas I have based on what I have seen around here, not necessarily true or realistic. just my 2 cents. ************************************************************************* |
| ||
| Jesse, I think you're missing the point. If I wanted to do a real, good quality team project, I'd have done exactly what you said, but this is an open project. The idea is that people have a bit more sense than to throw in code for a side scroller after someone has already started code for a 3D shooter. I've got a feeling there's not really very much support for this idea. Perhaps Jesse's suggestion would be better, but I'd still like to give this a try. If no one wants to do this though, perhaps I'll start it again as a team thing instead of an open thing. Erm... you didn't even setup the project on GitHub correctly. Oh. Well, I've never used it before so that's no surprise. Do you think you could set one up instead? |
| ||
| Here is what your proposing, but in a workable form... http://www.blitzframework.co.uk/ |
| ||
| I agree that this would need more direction. Look at any open source project, none of them started as 'let's just throw anything together'. They start with a solid direction and goal, and most of the time a small (usually 1 person) team gets something up and going before others start adding to it. It's easy to have multiple people building onto different parts of a house. It's pretty much impossible to try to build a house from scratch with no blueprints and everyone sticking up walls and stuff wherever they please with no coordination. That being said, I've always like the idea of a somewhat modular game. Maybe a platformer that has all enemies, objects, and levels scripted, allowing people to make levels with a great deal of variety, but keeping the gameplay somewhat the same. That is, the map/collision/sprite systems probably need to somewhat concrete. |
| ||
| Here is what your proposing, but in a workable form... http://www.blitzframework.co.uk/ This is as far from what I am proposing as you could possibly get. For a start, that is a framework with loads of separate components all shoved into one bag, which isn't what this is. Secondly, as far as I'm aware, you can't just edit anything you want, you have to submit a contribution, have it reviewed, etc etc. (correct me if I'm wrong). I might have misunderstood you and you could be suggesting we do a community game (as opposed to framework), which is similar to Jesse's suggestion. This also isn't what I originally proposed but it looks like that's what everyone would prefer to do. I'll give it a bit more time and if no one's up for my idea I'll start another thread for a more structured team project (not a framework though) |
| ||
| don't worry space... If there's anything I've learned from my many years with blitz forums... Is that if you come up with an idea that's out of the norm, you'll have 4 or 5 people that think it's nifty. Another 1 or 2 will be totally gung-ho about it. And the majority of everyone else will attempt to beat you over the head with their ideas of why it won't work. :) Set up your project. Set a theme and general direction for it. And try it. Nothing stopping you from trying at least. |
| ||
| And especially keep this thread alive. I will definately do work for this, but atm .. time.. lets bridge this with making the directive decisions and talk about something cool. Let me start: A 2d shot'em up with awesome physics and dynamic lighting. |
| ||
| I think this is a great idea. I'm having trouble getting my test commit up: ERROR: Permission to Spacerat/Blitzmax-Open-Project denied to Difference. Do you need to add me as a user? Then please do, my gitup username is Difference. [EDIT]: When I Try to clone is says: "No HEAD" Below is the code I tried to commit |
| ||
| Do you need to add me as a user? Then please do, my gitup username is Difference. He does. Either that, or you should make a fork/branch of the project, but that would be very difficult since there's no project to fork. When I Try to clone is says: "No HEAD" This is because he neglected to actually set up the repository with an initial commit. |
| ||
| And the majority of everyone else will attempt to beat you over the head with their ideas of why it won't work. Oh. I thought that was just my over active imagination :-p |
| ||
| Repository is at http://github.com/nilium/osmax I've put up a properly set-up repository on github. There are some rules I've put in the CONTRIBUTIONS (a poorly-chosen name since it's not actually a list of people's contributions) file that should hopefully put at least a few safeguards in place to prevent issues with commits. I'll quote it here for those less inclined to read things not in posts: 10/21/09 If you would like to make contributions to this project, please observe the following rules: RULES 1. All source code must use \n line endings. Windows line-endings (\r\n) and other variants (\r only) will be rejected, because this really screws up diffs and makes commits much more difficult to work with since determining what has and has not changed in a commit is incredibly difficult. 1a. Use of the default MaxIDE (specifically versions shipped with BlitzMax) is forbidden due to rule 1. If you need alternatives, please consider using ConTEXT, BLIde, TextMate, Smultron, VIM, Emacs, gedit, etc. 2. Do not commit files for working with projects (e.g., ConTEXT projects, BLIde solutions, TextMate projects, and so on). Due to the nature of bmk compiling everything from a single file, these are unnecessary and only serve to make commits unnecessarily complicated. 3. All source code must be available under the z-lib/libpng license. 3a. If using other source code, libraries, etc., that code must be compatible with the z-lib/libpng license or used in such a way that they are compatible within the context of their use. 4. Hard tabs only. Soft tabs (e.g., 4 spaces to indent) cause more trouble than they're worth. 5. No trailing whitespace on lines. This isn't likely to be an issue, but it has come up in some projects, so please take care to avoid it. This list may be amended, appended, prepended, modified, and what have you as work progresses.On 1a, I'm not entirely sure if BLIde or Smultron can specify the type of line-ending, so they may be excluded in the future. Feel free to rename the CONTRIBUTIONS file if you want. I've added you as a contributor, Peter, so go nuts (within the confines of the above). I also added plash just for my own amusement. I would encourage everyone to make forks and work on those before asking for contributor status. If you have something you want to see merged into the main branch(es), Github has a feature to make such a request. If you're an active contributor to the main repository, please do not modify the main branch unless you absolutely have to. I've set up a 'working' branch, you should put anything being actively worked on there until it builds and runs just fine. Obviously make use of the issue tracker and wiki if you want to report bugs or write documentation. Finally, if you do not know how to use Git yet, please read the guides on Github. |
| ||
| If you set autocrlf to 'input' all \r\n line endings will be converted to \n on both cloning/pulling and committing. It's probably best that everyone has that in their main configuration (core.autocrlf). I'm not sure if a repo's config overrides the global config or not but it's probably best to have it in the repo's config as well. |
| ||
| Open Source BMax Project (Zero Goals, 100% Confusion) I just spit coffee in my keyboard! Thanks! ;) |
| ||
| Here's a little rundown on getting the repository setup: http://wiki.github.com/nilium/osmax/getting-the-repository-up-and-running |
| ||
| Great, thanks nillum, exept for the nazi 1. All source code must use \n line endings. Windows line-endings (\r\n) and other variants (\r only) will rubbish.be rejected, because this really screws up diffs and makes commits much more difficult to work with since determining what has and has not changed in a commit is incredibly difficult. 1a. Use of the default MaxIDE (specifically versions shipped with BlitzMax) is forbidden due to rule 1. If you need alternatives, please consider using ConTEXT, BLIde, TextMate, Smultron, VIM, Emacs, gedit, etc. @Plash : autocrlf is it in my git client, or is it Nilium that should change it in the project settings? |
| ||
| because this really screws up diffs Do whitespace excluding diffs not work with git? Shame.... |
| ||
| autocrlf is it in my git client, or is it Nilium that should change it in the project settings? All you need to do is set core.autocrlf to true (or input, in which case \n replaces every instance of \r\n).I don't think the config for a repository carries along in a commit, so if you just want to change it there you would have to do that. |
| ||
| Wow... no using the official IDE, and this is an open project? I'm going to go out on a limb and say that I think most people still use the default ide. I may be wrong... maybe alot have switched the the CE, or blide, or whatever... but I still use the official. (CE doesn't seem to work on 64bit windows 7....) Is that if you come up with an idea that's out of the norm, you'll have 4 or 5 people that think it's nifty. Another 1 or 2 will be totally gung-ho about it. And the majority of everyone else will attempt to beat you over the head with their ideas of why it won't work. :) Absolutely no offense to spacerat, but this is far from a new idea. There have been a ton of 'community projects', and many of them -started- similar to this. I personally submitted the first piece of code (just some tile-map drawing code with layers and scrolling) to a similar project back in the bcoder days. I don't remember what happened to it exactly, but if I remember correctly no more code was written. I believe the project died from the planning being really 'open'. With random people chiming in with their thoughts on the direction the game should take, we ended up with something along the lines of a side-scrolling platformer starring some guy with bionic arms (I actually started drawing sprites for this, even though I hated the idea...), and then alot of ideas contrary too. Everyone who's idea wasn't accepted basically left the project. I'll be honest, I want to work on a game that I personally feel is a good idea. When the idea isn't there to begin with... there is too much opportunity for it to turn bad... and waste my time. You can say that I could steer the game in the direction I wanted by involving myself more, and contributing more than others... but then I'm just building _my_ game... with added resistance from people trying to build it into theirs. I guess that's the best I can put it in words. Not trying to be a downer... just stating why the idea doesn't interest me. |
| ||
| Thanks plash , got it set up , and comitted a first file! :-) |
| ||
| Wow... no using the official IDE, and this is an open project? I'm going to go out on a limb and say that I think most people still use the default ide. I put it under 1a since it's more of a guideline and not a rule. If you can't ensure rule 1, then it's effective in stopping people from committing CRLF line endings, otherwise I really don't care.I'll quote a chat log since clarification about how this all works is obviously needed: <Nilium> Also, the line-endings thing isn't nazi-ish <Nilium> That really is an issue, and it came up a few different times when I was fiddling with plash's mono module <Difference> no, but you can take out 1 and 1a if we do what plash says <Nilium> I don't intend to enforce 1a, it's more like an advisory. <plash> We need to lay down rules for type structure, and importing/including <Nilium> And 1 does need to be in there, because otherwise you'll just ignore autocrlf <Difference> it's way to restrictive to dictate what editor people can use <Nilium> I'm not dictating what editor people can use provided they meet rule 1. <Nilium> If they can't ensure rule 1, 1a is effective <Nilium> Think of it that way. <Difference> ok, then 1 + plash " fix" <Nilium> The rules are in the repository, I'm not stopping you from changing/amending them to reflect the use of autocrlf <Difference> k <Nilium> I put them in there 'cause those're the ones I think are most important, says pretty clearly they're subject to change, and I don't intend to do much more than maintain the repo <Difference> cool <plash> If we don't have structuring rules there will be some ugly code <Nilium> Also, I figured that if I didn't pick a license for you all, you'd be bickering about it 'til kingdom come <plash> It would be hard to work through multiple different structures <Nilium> If you want to outline coding style or whatnot, go nuts <plash> I shall <Nilium> I would prefer that my input be completely unnecessary <Nilium> If you decide to fork it and set up your own project with different rules, contributors, style guidelines, etc., that's your call <Nilium> Basically, if you want to change something, do so, I'm not going to stop you unless you decide to wipe the repo and ruin it for other people <Nilium> And I don't think that'll be an issue Basically, what I want to make clear is this: the rules can change, you can change them, ask other people on the project to do it, but you don't have to ask me. I'm not involved in coding or anything, I'm just keeping the repo up (well, github is keeping the repo up, I'm just making sure nothing bad happens and adding contributors as needed). Rule 1 is important for me to keep things from getting messy, 1a can be modified and I won't care- I'm not telling you what IDE to use, I'm just saying you shouldn't use something that will break things if you're not using autocrlf (it will break things regardless of OS as well, last I checked). Hopefully that all makes sense, as I'm typing this in a bit of a hurry. |
| ||
| I've commited some code for game states, and layed out a basic file structure. At least I think I have... I'm using a GUI git for windows which I'm starting to realise isn't very adequate. Also Nilium, is that IRC? If so, what server/channel is it? EDIT: Upon investigation, I've realised that I probably didn't commit properly. $ git pull is telling me that branch.master.merge isn't set. What should I set this to and what else do I need to set? |
| ||
| is that IRC? If so, what server/channel is it? irc.blitzed.org #blitzbasic Upon investigation, I've realised that I probably didn't commit properly. $ git pull is telling me that branch.master.merge isn't set. What should I set this to and what else do I need to set? Are you using Nilium's repository? If so, you'll probably need to be added as a contributor. Once that is done refer here (I've never used the GUI so I cannot provide a tutorial on that).EDIT: Until you're a contributor, you'll have to work on a fork. |
| ||
| It's probably irc://irc.blitzed.org#blitzbasic More Git help can be found at - GitCats - learn.GitHub - Pro Git (I recommend this one, there's also a printed version of it) |
| ||
| I'll make one little statement about this.. if the project rots (is inactive) for two weeks, I'm going to delete the repository. If you want this to succeed, I suggest you make an effort, gentlemen. |
| ||
| Anyone have an optimism to code converter? |
| ||
 Just to prove that this hasn't fizzled into nothing, here's the progress so far. We (mainly plash and I) have created a textured destructible terrain generator and a player to traverse it. It would be really nice if we could have more people contributing though. Two people or even three people aren't really enough for a project like this. |
| ||
| Looks good :) |
| ||
| Why not use code from the blitz community framework competitions? How are you doing the destructibility? And how big is the game world? |
| ||
| Why not use code from the blitz community framework competitions? If anyone contributing wants to then they're free to do so. It's not something I'd do myself though, and I don't want to make the blitz community framework a theme of the project. How are you doing the destructibility? And how big is the game world? Plash did the destructibility, by pasting transparent textures into the image pixmap for collisions, and using modified FBO code from the code archives to make the same changes to the rendered image. As for the game world, we don't know yet as we still don't have an outline for what the game will actually be, although clearly it's going to be a side-view 2D game with destructible terrain. Performance wise, I think that if the game world ends up being large, it could be split into multiple sections so that we don't have to check for a collision with a needlessly large image. Here's the repo if you want to check it out, and if you want to become a contributor just ask Nilium and he'll sort it out. |
| ||
| Why not use code from the blitz community framework competitions? Personally I would not like that idea. How are you doing the destructibility? For collisions we have it writing/removing pixels from the image's pixmap. For the actual visual data we make the exact same changes to the OpenGL texture using an FBO (instead of reuploading the pixmap to VRAM every time a change is made). |
| ||
| Don't make a Worms clone, there are enough of those already. How about a building sim.. where you can mine/dig for something? |
| ||
| So you are limited by opengl fbo texture size? |
| ||
| So you are limited by opengl fbo texture size? If there is one, of course. Is there one?The terrain sections will probably be separated anyways if it gets bigger. The terrain you see in Spacerat's screenshot is exactly the size of the game window. |
| ||
| Yah your fbo object uses a texture which means it's limited to the maximum supported texture size, which might be 2048 or 4096 or 8192 or more but depends on the graphics card. |
| ||
| What you asked originally was misleading. Of course it would be ridiculous to make a massive 12000x4096 texture for the entire terrain. |
| ||
| I've done it. It's not so rediculous, it's just that you can't keep the entire texture in graphics memory all at once. |
| ||
| Don't make a Worms clone, there are enough of those already. How about a building sim.. where you can mine/dig for something? How about this, for a twist: Make the project a Worms or Scorched Earth clone where the players don't directly control the tanks/players. Instead, players using a scripting language or a GUI interface to assign behaviors to their tanks, which then go fight on their own. Possibly give the player a certain number of points to spend on accuracy, power, speed, etc, in addition to allowing the tanks' decisions to be scripted. Eh, I guess that might be a bit unrealistic, but it sounds like fun. SpaceAce |
| ||
| What about Lemmings meets Worms. You don't control the warriors directly, but by manipulating the landscape, or changing their role (jumper, marcher, blocker..) you guide your men towards the enemy. |
| ||
| Sounds pretty interesting. |
| ||
| What about Lemmings meets Worms. You don't control the warriors directly, but by manipulating the landscape, or changing their role (jumper, marcher, blocker..) you guide your men towards the enemy. That actually sounds pretty awesome, similar to what I had in mind, but probably more realistic in scope. Instead of a base just pumping out tanks that you assign jobs to, maybe you could mix parts in a hopper or something to get what you want. For instance, drop a cannon and a drill into the hopper, and you get a tank that drills through walls and attacks enemies when it encounters them. SpaceAce |
| ||
| Nilium wrote: I'll make one little statement about this.. if the project rots (is inactive) for two weeks, I'm going to delete the repository. If you want this to succeed, I suggest you make an effort, gentlemen. Time to put your money where your mouth is... ;-) |
| ||
| Ahhhhh hahahaha... oh.. .sorry whew! |
| ||
| If you want to make something tangable you would need to lay out what the objective is... hammer it out until the top of the thread is laid out with a decent plan. Obviously you would not be able to decide on the game until you had enough "buy in" to have a core team... you will need a coder, a graphic artist, and a sound guy... later.. level builders I would suggest that you all stick to top level stuff like: Concept... Programming Language BlitzMax ver ... GUI System: .. Input Control System: Graphics System: OpenGL (Cross platform :) Particle System: TimeLineFX 3D System: {if needed} ... Start adding more to, and breaking each down...When you start getting to places to add code... step back and see if anything else in the plan is not resolved yet. When you all look at the plan and see no need to modify anything, and all thats left is coding/creating... off you go... Just IMHO |
| ||
| What about Lemmings meets Worms. You don't control the warriors directly, but by manipulating the landscape, or changing their role (jumper, marcher, blocker..) you guide your men towards the enemy. That actually sounds pretty awesome, similar to what I had in mind, but probably more realistic in scope. Instead of a base just pumping out tanks that you assign jobs to, maybe you could mix parts in a hopper or something to get what you want. For instance, drop a cannon and a drill into the hopper, and you get a tank that drills through walls and attacks enemies when it encounters them. Ok, If someone doesn't make this game I'm going to scoop it up LOL |
| ||
| Everyone has six hours to fork/clone the repo and then I'm killing it. Edit: And making commits won't save it anymore. |
| ||
| Shame, its looks like a good project (Ive been interested in a Worms/Lemmings destructible terrians for a while).... Does this have the latest verison?: http://github.com/nilium/osmax When I run it I get this screen:  Which looks a bit different to the one spacerat posted, also I cant see the destructible terrian code... btw the code/comments looks very neat - good job! |
| ||
| That looks like a single image with a sin curve drawn on it and a block guy moving over the "terrain" Was it even tile based? |
   |