Reply With QuoteThat's a possibility. It can be taken too far, though. Like in Nethack when I got stuck and couldn't move because I had automatically picked up a heavy box or whatever just by stepping on it. Not very intuitive. :)Originally Posted by JoshV
Oh, like the Volatile keyword in C#, and I recall there is some special stuff for declaring code as having to occur in the order in which it was coded. I've only mucked with that a little bit. I've definitely noticed an increased need for multithreaded knowledge these days though.
That's a possibility. It can be taken too far, though. Like in Nethack when I got stuck and couldn't move because I had automatically picked up a heavy box or whatever just by stepping on it. Not very intuitive. :)
I don't code in C#, but yeah, the quick look at docs indicates that a volatile field is guaranteed to be read/written atomically and that it has the correct acquire/release semantics.
Usually the standard is command+direction, without facing being handled all the time (same for LoS, it usually has no specific direction and works for all angles, which would be my ideal choice as well).
Commands in roguelikes are usually like that. For example you [o]pen the door (or [k]ick), then give the direction of what you want to open. Otherwise a default command can be issued still by using the direction.
If North there's a door, you try to open the door by moving North (it will try to open it by default, if not locked).
Usually only movement commands and related are automated. Along with other commands that have no negative side-effects, like picking up gold when gold isn't even counted as weight.
But why reinventing the wheel. If you want an universal "use" command you should still implement it with: use+direction.
If there are multiple uses, or if the action could be dangerous, you could just place some flags so that the command issues a confirmation, or offering more choices.
The result is that if an object has just one use then it gets its default action, if the object can be used in different ways it shows something like a menu where you cherry pick what you want specifically.
P.S.
This was better kept in the other thread! Since it quite interesting discussing the inner workings of these things.
Last edited by HRose; 08-15-2012 at 05:28 PM.
I'm giving some thought to actually putting some time into some game ideas I've been thinking about for a while. With that in mind, does anybody have recommendations for a good relatively lightweight 2D framework / engine for android? Mostly I just want things like a scene graph and an object manager.
Failing that, any recommendations for one in Windows (C++ / Java)? Or do I have to suck it up and finally learn Flash or Unity or something?
Have a look at cocos2dx: http://www.cocos2d-x.org/
Also Corona: http://www.coronalabs.com/products/corona-sdk/
libGDX will get you going and then some: http://libgdx.badlogicgames.com/
I think I'd go with LibGDX, if I had to have OpenGL. Unless you're doing something graphically intensive, though (i.e., lots of animation, multiple sprites, etc), I'd strongly consider just running with native Android (Canvas, SurfaceView, etc).
Apart from being just a lot simpler to work with than any OpenGL framework I've yet seen, it also allows you to mix and match with standard Android UI elements and means that you will (almost) never have any errors due to graphical hardware incompatibilities. I use that in Pirates and Traders, and while in theory I'd love to convert it to use OpenGL/GlSurfaceView, in practice it's just never been worth the time required to convert and debug the code.
At the moment I'm spending my free time working on a very small squad/army combat game engine. The idea is to make something generic enough that it can scale from small skirmishes up to army warfare, and which handles combat (with some abstraction, of course), from swords and buckler up to musket and bayonet. Not sure if it will work or be interesting to play, but it's pretty fun to do.
This is one of my many extremely-low-heat back-burner projects for Android sitting around in my Eclipse workspace waiting for me to be interested in it again. Right now I hardly have more than some simple object types defined.
Hexes or floating point positions? Personally I prefer hexes, because it can be hard to know if you are in fact behind cover or behind a ridge line or not when trying to eyeball some unit token or sprite against a curving high-res contour.
Oh, I assume it's a strategy game, not action.
Strategy, of course. More precisely, I'm looking at some turn-based, simultaneous movement (or phased) gameplay.
It is grid based, but at a fairly high scale (currently 7x6). The idea is to make something that is quick playing, but where positioning, orientation and terrain still has an impact. The aim of the granular grid is to try and create a "less is more" effect; i.e., there may not be a lot of terain, but the terrain on the board matters a lot.
So the level design will be important for the fun element of the game. Have you played Squad Leader? The first couple of tutorial scenarios from the original game strike me as a nice candidates for a port to your system, and a few old timers at least may even remember them.
Thanks for the recommendations! Now I have to scan through the docs for those and see which ones seems the easiest to play with. I probably won't be able to this week as I'm pretty swamped at work.
All of my game dev experience is straight 2D casual games stuff, very minimal resources and no 3d requirements, so that's what I have in mind. I'll have to look at the Android core docs, but I never liked re-implementing low level stuff, and a lot of the phone specific stuff (cameras, location, interface) scares me, so I prefer to pretend it doesn't exist.
I have very little expectation of ever putting out a commercial product, it's more of a way to get myself programming again after, well, almost 3 years away now. I'm kind of dreading the re-learning part, but that's only going to get worse the longer I wait.
My Kinect music project (that started this thread back in the mists of time) is making slow but steady progress. Recently added dual-monitor support, just in time for this demo at Microsoft -- I won runner-up in the "So Fun!" category, and I was told I might well have won if I weren't using a Wiimote as well as the Kinect.
Next up: two-player support, hopefully in time to jam with some Seattle beatboxers next month. Then I put in VST support, specifically for the Turnado plugin by SugarBytes (used by my musical inspiration Beardyman in his new custom iPad-based live looper). Then some more visuals... and then it'll be late next spring and time for some real performances in the summer :-D
This year already I showed the damn thing at Microsoft twice, at the Seattle Mini Maker Faire, at my sister's wedding in Boston, and most recently at a makerspace in Seattle for the Decibel electronic music festival. Been well received damn near everywhere, so this project has no real end in sight -- applause is extremely motivational!
I'm hoping not too much - I'd like to be able to generate random maps for the system that provide the player with interesting situations.
I know of SL, but initially, at least, I'm focusing on swords, bows, and muskets. I'm not convinced the system will even be able to go that far forward - combat changes quite significantly from earlier periods once you start getting high velocity, rapid-fire weapons that allow a single character to dominate the battlefield.
@CLWheeljack:
Given your last comment, I'll double my recommendation that you use the standard Android API, because graphical programming really doesn't get much simpler than using the Canvas and SurfaceView together with the standard UI views. See http://developer.android.com/guide/t...-graphics.html and take a look at the LunarLander demo that comes with the SDK.
Seriously? Boo!
Apart from that, awesome. Loved the presentation. Latency is Evil!
Thanks :-)
The decision was fair -- it was a contest partly organized by the Kinect team, so I kind of was cheating by bringing in Nintendo hardware. The other contestants went full Microsoft. But quite a few people told me they thought I was robbed, which is almost better than winning.
Naval War: Arctic Circle, the Paradox-published Fleet Command-alike from early this year, needs a random scenario generator. I've embarked on a project to make one.
My language of choice is of course Groovy, everyone's second-favorite non-Java JVM language (behind Scala; Groovy is more scripting language-esque, though). The NWAC developers were nice enough to make their custom scenarios simple XML, and after brushing up on my orthographic projection math and sussing out their origin point choices, I was off to the races last night.
I'm taking a break from iOS and Android games to work on a Twine adventure game. So far, I love it! You can make simple interactive stories, or add variables and simple logic. It outputs an HTML page which I guess could be packaged with Phonegap for a mobile device, but that's not my plan.
Heh, it's funny you mention it, as I've had a similar project on the back-burner for a while, but XNA 4.0. Granted XNA is mostly a ghost town now, so I should convert it to something else, which of course, doesn't help it's backburner status.
I actually went with floating point positions, as I wanted to try to capture that 'tabletop' feel, but hell, it's a way more complicated endeavor than doing tiles. I did have a rolling terrain, and calculated the cover by percentage of model being covered from the attackers point of view. Navigation was a stumbling block, as I'd think I'd have to use a navigation mesh. Though now Unity has a navigation mesh plug-in, if only they didn't gate the rendertargets behind their pay license. Though I should just buy a license anyway, cost be damned.
Or, my new thought, is to not go floating point, and in fact, just dig into the XCOM files, and just mod it to be what I want, as I rather like how it handles cover. I've mucked with some unreal script before back when I was tempted to port my game to Unreal, but their navmesh was completely horrible and crash-tastic on even a simple test case.
Does anyone have a good reference on spherical geometry? I've been able to leverage the whole locally-Euclidean thing for my Naval War: Arctic Circle project thus far, but it seems at least possible that I'm going to run into situations in which great circle distances and segment intersections become critical rather than just a nice feature.
I made a Mac app (using cocos2d) to provide an environment for my 21-month old daughter to press keys on the keyboard without causing havoc. I don't really expect to sell any copies of it, but hey -- my daughter loves it and has learned the names of all of the animals: https://itunes.apple.com/us/app/todd...66326332?mt=12
So after doing zero promotion of this -- actually, I sort of forgot about it -- I logged in to see that I've sold about 100 copies in the first week. Woo. Actually, it would be great if it sold enough to cover my annual developer costs. Not bad for a few days of work (and an App that my daughter loves).
I thought I'd give this newfangled HTML5/Canvas stuff a try, so I wrote a simple canvas "game" as a learning exercise: http://koti.kapsi.fi/~shang/games/monster-maze.html (tested with latest Chrome and Firefox)
The whole thing took about 9 hours to put together, including the time spend reading various documentation. All in all, it was a surprisingly pleasant experience, so I can see myself making a more substantial game using the web technologies at some point.
I wish I had more time for for-fun programming!
Shows plenty of promise given the small investment of time. What resources did you use?
I was thinking about for-little-kids toys for tablets. I mean for say, ages 3-6 or so. Elements that occur to me offhand include:
- simple paintbucket for filling in outline pictures -- tried and true and done to death, sure, but I think kids enjoy this, so there's no harm in doing it again. Obviously the fills would include patterns and gradients and shiny things, maybe animated fills too, and the app would come with a whole bunch of outline pictures to fill in.
- simple "fingerpaint" drawing app with robust and easy undo and redo.
- ability for the above drawing apps to send an "i made this" email with the image as attachment to a preset address by touching a button. Equivalent of posting to a refrigerator door. Stretch goal, put up a public website with the pictures for all to admire by passing a link around.
- "kaleidoscope" -- pretty, changing graphics affected by touch.
- very simple point-and-click adventure that is mainly just changing scenes by going left or right or finding the hidden path, and clicking on characters to talk to.
The last item requires a pro (or at least amateur) artist to implement, but the others seem simple enough from a pure programming point of view. What other elements or toy or game modes might go into a toddler app like this?
Thanks! I'm not quite sure what you mean by resources in this context, but assuming you mean learning resources, mainly
plus whatever random articles I googled and looked up on Stack Overflow on a need-to-know basis.
The graphics are Creative Commons works from OpenGameArt.org and David Gervais.
As for libraries, I just use Require.js for module loading and JS-Signals for event handling. I wanted to learn the low-level APIs first, so I didn't look at any larger framework yet.
Right, that's what I meant, thanks.
How worth (and how hard is it) to learn Lua, in general? It's one of those languages that I never had the opporunity to work with, but I recall it coming up every so often. From the examples I've seen, it basically looks like pretty standard OO-programming syntax.
The multi-typed tables seem like they'd take some getting used to.
Posting Permissions