English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 23 May 2015, 23:47   #141
copse
Registered User
 
Join Date: Jul 2009
Location: Lala Land
Posts: 280
Quote:
Originally Posted by TMR View Post
For the more experienced people out there, isn't there an Inform engine for the Amiga which could be used to do this...?
There are lots of engines:
If I were going to work on a game, I'd work on one with Inform. It's incredibly popular and has numerous games already out there (as does TADS for that matter) so tutorials and examples in the form of existing games are going to be plentiful.

But really, there's no excuse, if one really wanted to make a text adventure. All you need to do is dig in and keep applying yourself, like making any other type of game.
copse is offline  
AdSense AdSense  
Old 24 May 2015, 00:46   #142
Lazycow
Registered User
Lazycow's Avatar
 
Join Date: Oct 2014
Location: Germany
Posts: 149
Quote:
Originally Posted by spud View Post
Lazycow, see the sticky at the top of this sub-forum
Argh, thanks. Yes, I saw that before...
Lazycow is offline  
Old 24 May 2015, 02:40   #143
Ikilledher
Registered User

Ikilledher's Avatar
 
Join Date: Jan 2015
Location: The Hague
Posts: 22
Okay, I admit. I have been lurking for two weeks. I like this thread. I started out confused by the term ‘homebrew’: I always thought homebrew described creating software for systems that were not meant to be explored by consumers, e.g. SNES or Atari 2600. Commodore 64 and Amiga, I think, would not classify because all information on creating for these systems is readily available, and it has been for a very long time. These computers are almost literally shouting “make stuff with me!”

But homebrew, that’s just a word. The thread’s about creating stuff! Throw in some references to (text) adventures and I can’t resist adding to it.

I think there are quite a few people around with certain skills that would enable a modest team to create a brand new Amiga game. Interested people can manage (‘create’) time themselves so let’s say you manage to get them to commit some time in a project. Now here’s your team: a graphician that is all heated up, ready to pixel. An Amiga coder who just walked through his/her old code and sheds a tear (of joy). And musicians… please stop the constant flow of modules. There are not enough musicdisks to hold them all really!

Now what?

The most important part, I think, in the creation of a game is envisioning the game before it exists: a story, an idea, ambience, a character. Draw it, write it, share it. You don’t need any programming experience whatsoever! Your parents can join in, your sister, nephew, brother in law, your kids. Amiga is a family computer after all. YOU can create an idea for a game in an afternoon. Try to be precise: ‘The best vertical shooter ever on Amiga – one that trashes C64’s Hades Nebula’ is not really specific enough.

If you get to a point where you start feeling somewhat excited, you are doing it right. Now bring in the coders, right! No. Make a mock up. Do it yourself. A drawing would be nice. It does not have to be very good. Just use it to explain your idea.

My point is, just suggesting that other people should build a game won’t deliver a new Amiga game in 2017, or 2018… And in the remote case it will, it might be a different game than you expected. On Amiga, people create games for the fun of it.

So… my (somewhat simplistic) conclusion is: make the d#?n game yourself! I mean that in the most positive way. Start creating and make sure to have fun doing so. Share your endeavors so people can get interested and might join in! If you are able to do this together with a few (newfound) friends that would be great but… you can start it yourself! Even sharing your mature ideas for a game IS part of creating a game.

Maybe you even feel the urge to try and build it yourself. The Amiga certainly is no difficult-to-master Commodore 64 (!) or downright hard-to-master homebrew system like the Atari 2600. I agree that learning assembly and some of the inwards of the Amiga can take time and effort but there are quite a few alternatives out there, mentioned in this thread also.

I can recommend a nice little book titled “Rise of the Videogame Zinesters: How Freaks, Normals, Amateurs, Artists, Dreamers, Drop-outs, Queers, Housewives, and People Like You Are Taking Back an Art Form” (978-1609803728) which message I would summarise as: anyone can make games; do it.

I am happy I found an Amiga forum where people are talking about making stuff. That is so Amiga to me.


Last edited by Ikilledher; 24 May 2015 at 02:57.
Ikilledher is offline  
Old 24 May 2015, 14:21   #144
NorthWay
Registered User
 
Join Date: May 2013
Location: Grimstad / Norway
Posts: 391
About this discussion, I'll flip it on the head:

I think it is possibly easier to start something on the Amiga, but much harder to complete or be satisfied with. The C= 64 has absolute limits in both look and size that all interested parties know and the trick is to get as close to them or make it seem you passed them, but on the Amiga the sky is the limit - when is it good enough?

Better tools has made it possible to do C= 64 development speedy enough to be comparable with commercial releases in a short enough time, while the next Sword of Sodan will probably not be done any faster nor better(or even as good as) than the original.

Last edited by NorthWay; 24 May 2015 at 14:23. Reason: typos
NorthWay is offline  
Old 24 May 2015, 18:51   #145
TMR
Registered User

 
Join Date: Aug 2014
Location: Leeds, U.K.
Posts: 38
Quote:
Originally Posted by NorthWay View Post
Agree to disagree?
Well, you can do it with a bubble sort but you're always trading off those overheads against something else; even if you don't fully sort the list each time and/or add some kind of pre-sort there's still more overhead than using a faster, more efficient routine in an environment where wasting cycles is problematic.

i've released a game with a bubble-based multiplexer on the Atari 8-bit, but it gets away with it by A) only dealing with six objects, B) running a pre-sort which compares one half of the list with the other and C) all the other stuff like scrolling is based on Atari 8-bit specific techniques which wouldn't work on the C64.
TMR is offline  
Old 24 May 2015, 19:03   #146
TMR
Registered User

 
Join Date: Aug 2014
Location: Leeds, U.K.
Posts: 38
Quote:
Originally Posted by Ikilledher View Post
Okay, I admit. I have been lurking for two weeks. I like this thread. I started out confused by the term ‘homebrew’: I always thought homebrew described creating software for systems that were not meant to be explored by consumers, e.g. SNES or Atari 2600. Commodore 64 and Amiga, I think, would not classify because all information on creating for these systems is readily available, and it has been for a very long time. These computers are almost literally shouting “make stuff with me!”
It's one of those terms that has changed several times over the years. At one point people would only use it in reference to games they'd burnt to EPROM and painstakingly hand etched a PCB for over the stove, but the earliest use of the word i'm aware of is the Homebrew Computer Club, the software they wrote was considered homebrew as well so the C64, Amiga and other platforms fit under that version of the umbrella.

As someone who has been writing about "homebrew" for over a decade and coding it for three, i've never liked the term personally but the only other option is to call ourselves "indie" developers and i'm not sure that fits me either. =-) Also, i feel very old now.
TMR is offline  
Old 25 May 2015, 03:56   #147
Tsak
Registered User

Tsak's Avatar
 
Join Date: Jun 2012
Location: Athens
Posts: 244
Quote:
Originally Posted by phx View Post
Often it is sufficient to kill these projects when only a single team member becomes inactive. So the risk increases with the number of people involved.
None can argue against the fact that the best person to trust is yourself and yourself alone. So, yes, when you rely on others there is always some risk involved. Past that, what you stated above perhaps holds some truth but it's not always the case:
For a start, the more people you have helping in one department (ex. gfx) the less likely it is for one person's departure to cause too much trouble for the project to be killed. Other members can usually compensate for the loss especially if there's loads of shared work involved.

And -of course- every job has a different weight and importance for the project's continuum. Have you ever seen a project being canceled because the person responsible for sfx has left the team? So, it's not about members -in general- but WHO becomes inactive:

1) The “game designer”, original author of the idea or the person leading the effort. Losing this guy is the most efficient way to kill a project. Especially if the guy is reluctant to pass it on to someone else or holds a key position (ex. he is the lead coder).
2) The lead coder: It's a position that is very difficult to cover if lost. I think most of you know very well how it's like to work on top of someone else's mess (supposed the previous coder was kind enough to left his work behind). You either need a hero for the job or start thinking seriously about re-building the whole thing from scratch. In all cases it's a true disaster... Of course if this person is really the lead coder (that means your team has other people helping in this department) you have slightly better chances to compensate for the loss.
3) The lead gfx artist: Losing him is the less likely reason to kill a project but it remains possible, especially when you're deep into production and the guy simply takes away his work and vanishes (or if he is extremely talented and his work is of an exceptionally high level). Still, another, equally experienced artist can continue, reform, finish or even upgrade the gfx that are left behind. The greatest problem here is to get the artistic style right so that the game won't feel different. That is indeed a great barrier to overcome. But the simpler the gfx are (and the greater the artist's experience), the less likely is for this to become a problem. In any case, a game can always continue being developed using placeholders- until you find the right candidate for the job. Not your prime choice - I know- but at least this is sufficient to keep a project alive.

Quote:
Originally Posted by phx View Post
As a programmer I must be absolutely sure that I can rely on my team, because I don't want to spend a year of work for nothing. This keeps me away from uncertain "adventures".
Well, this stand true for any other member in the team... who wants to spend a year of hard work for nothing?

Quote:
Originally Posted by phx View Post
In most cases you have some game graphics looking for a programmer, but that will hardly ever work. Finding a programmer who likes exactly the concept and game type which is shown is quite unlikely.
Perhaps amiga coders are extremely picky and hard to trust?
Ok, joking aside I know everybody holds his preferences. But maybe the hard fact here is that there are few coders in our scene that would be willing to hand the keys of game design to someone else, either for reasons of trust, disbelieve or simple inclination. Wouldn't you agree?
Discarding a project or person who lacks either the expertise, talent or basic knowledge of game design is obviously a no brainer and it's not what I'm talking about...


Quote:
Originally Posted by phx View Post
It works best when designing the concept first. The programmer thinks about the technical implementation and defines the constraints for the graphics. Then the artists start drawing.
I wouldn't disagree. But if it's the artist that is behind the concept, he needs to present some sort of showcase to attract attention first. Then a programmer could come in, think about the technical implementation and counter suggest any needed constraints. Gfx and concept can then be adapted to those. It's a take and give process that works equally well in reverse or may hit -as well- on the same obstacles (f.e. coder that asks for gfx that are beyond the artist's abilities or a coder's concept that stumbles upon technical issues, but this time from the artist's perspective).

Quote:
Originally Posted by phx View Post
And even if that would be the case, the graphics are often unusable, because they are drawn without taking the limitation of the hardware in account.
Quote:
Originally Posted by Apollo View Post
Where are the individuals who can create 2d art natively on the Amiga? It was said several times now that there are more graphicians/musicians out there than coders on the Amiga. Is this really true? I doubt that. Like I wrote in my previous post: things get complicated _nowadays_ when someone hast to draw graphics in a reduced environment. Back in the day people did not have 16,8 million colors. They did not have Ableton live and a plethora of synthesizers in their bedroom. One had a bunch of ST-xx disks and tried to make the best of it.
Common guys! This is an amiga retro forum, not microsoft's backyard!
Most experts that are actively involved in game making here know pretty well how to move a pixel or what it takes to make gfx for amiga... Plus an experienced artist can very well adapt any gfx to the needed specifications even if the original material (or even concept) is way beyond those (no need to get far, just check any of the conversion projects that are on-going). What I get from your answers is about gfx guys that are total newbies or irrelevant to the retro scene... but that's obviously not the people I'm talking about... I'm checking the forum almost everyday for the past year or so and I've seen far too many cases and real talent lurking around... (take this recent post f.e. : http://eab.abime.net/showthread.php?...ghlight=invent).
There's one more argument that suggests in favor of what I'm claiming: the recent 'boom' in backbone games: Most of the people involved (or willing to do so) have a nice idea of what it's like to make gfx in a reduced environment (or how to do a bit of game design) but have no coding skills. At the same time it's rare to see a coder looking for gfx (or music) help and not getting any -whatsoever-.

Whether this is the case or not one fact remains: I'm claiming that there are enough gfx/music guys willing to help in our community but maybe not enough (or at least) willing coders, while others here may claim otherwise. Perhaps this is the best proof of why the parties and individuals need to get involved and get to know each other better. Thus the need for a better database or subforum or something similar that will help in this direction. Having EAB altogether with all the buzz, projects and discussion going around is obviously a great place to start! But there's always room for improvement, especially if the goal is to elevate the scene and have more team projects and -eventually- more games of a better quality.

Last edited by Tsak; 25 May 2015 at 18:55.
Tsak is offline  
Old 25 May 2015, 19:19   #148
Nibbler
nam nam nam

Nibbler's Avatar
 
Join Date: Jan 2015
Location: Austria
Age: 38
Posts: 567
There is a lot of Homebrew out there, games as well, but to get the most out of it, "Assembler" would be the best choice.

*But how many people today know how to programm in assembler....

* ( the people of sqrxz told me that )

by the way... try the sqrxz games, the are pretty fun, and tuff
Nibbler is offline  
Old 26 May 2015, 01:17   #149
copse
Registered User
 
Join Date: Jul 2009
Location: Lala Land
Posts: 280
Quote:
Whether this is the case or not one fact remains: I'm claiming that there are enough gfx/music guys willing to help in our community but maybe not enough (or at least) willing coders, while others here may claim otherwise. Perhaps this is the best proof of why the parties and individuals need to get involved and get to know each other better. Thus the need for a better database or subforum or something similar that will help in this direction. Having EAB altogether with all the buzz, projects and discussion going around is obviously a great place to start! But there's always room for improvement, especially if the goal is to elevate the scene and have more team projects and -eventually- more games of a better quality.
So, get a forum made and have people post threads like "Gfxer looking for coder" At this point, you can claim whatever you want, but the proof is in the pudding or it's just .
copse is offline  
Old 26 May 2015, 19:52   #150
Jope
-
Jope's Avatar
 
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 37
Posts: 6,354
Send a message via Skype™ to Jope
How about don't start a new forum, we already have plenty. Use the existing ones to recruit talent.
Jope is offline  
Old 26 May 2015, 20:15   #151
saimon69
Bedroom musician

 
Join Date: Apr 2014
Location: los angeles,ca
Posts: 699
@jope

Yup, some sticky might help - AND a separated blitz forum on coder section
saimon69 is offline  
Old 26 May 2015, 21:19   #152
TenLeftFingers
Registered User

TenLeftFingers's Avatar
 
Join Date: Sep 2013
Location: Ireland
Age: 38
Posts: 783
A champion to make some good tutorial vids woyld be a great incentive to attract new coders too. Some tutorials that cover some fundamentals of coding against this system would be a great boon I think. Again, I think this ks sonething the C64 guys have in spades.
TenLeftFingers is offline  
Old 26 May 2015, 21:39   #153
Locutus
Registered User

 
Join Date: Jul 2014
Location: Finland
Posts: 766
Not really for games (but a lot carries over) but Photon of Scoopex has video tutorials for demo coding in 68k/Asmone on youtube which are really good and easy to follow.
Locutus is offline  
Old 28 May 2015, 02:52   #154
saimon69
Bedroom musician

 
Join Date: Apr 2014
Location: los angeles,ca
Posts: 699
@locutus

Yup, seen it: reminds me when me and the guys that fgirst became QUAZAR then coded Powder were learning to code assembler on Seka... however i never went further than btst $bfe001
saimon69 is offline  
Old 29 May 2015, 15:24   #155
invent
pixels

invent's Avatar
 
Join Date: May 2014
Location: Australia
Age: 46
Posts: 168
Maybe we just need to start playing with ideas, a simple scroll routine, or animating elements that have ease in/out effects. Code copper effects, or replicate great effects we have seen in demos. I'd love to see coders write small bits of code and have other play, modify, suggest, and improve techniques.

Possibly for lots of people coding a full game could be too big a task. For me completing two games in the last few years "Dots Adventures" (PC, Mac, iOS) and Lunar Jetman" remake for PC were a lot of fun, in most part because of the people involved in those teams. It certainly required a lot of dedicated time and commitment, and yes it is possible with a full time job and family

I have to say that it is inspiring to see activity on other retro platforms such as the C64, Amstrad and ZX Spectrum.
invent is offline  
Old 29 May 2015, 18:37   #156
zerohour1974
Registered User

 
Join Date: Mar 2015
Location: Swindon UK
Posts: 202
I would like to write a Pocket Trains like game but to be honest have no idea where to start. Have looked at AMOS and Amiblitz. Watched a few of the Scoopex videos.

I would probably need an idiots guide to programming Amiga stuff
zerohour1974 is offline  
Old 29 May 2015, 19:07   #157
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 909
Send a message via Yahoo to Samurai_Crow
@invent
I've been trying to find the time to make a replacement for the MrgCop routine in Graphics.library for use in AROS 68k. That seems to be the prerequisite for merging copper effects together for common use.
Samurai_Crow is offline  
Old 30 May 2015, 06:24   #158
copse
Registered User
 
Join Date: Jul 2009
Location: Lala Land
Posts: 280
Quote:
Originally Posted by zerohour1974 View Post
I would like to write a Pocket Trains like game but to be honest have no idea where to start. Have looked at AMOS and Amiblitz. Watched a few of the Scoopex videos.

I would probably need an idiots guide to programming Amiga stuff
You've got lots of options.

Find the source code of a game written in the language of your choice, and modify it to see what difference bits and pieces make. Start with making small changes, and perhaps even look to make a total conversion to the game you want to make in the long run. As things come up, research them and slowly learn. Always keep running code.

Find a tutorial in the language of your choice, and just start from there. Lots of great games have been made by people who taught themselves programming.

Go to a more modern platform like MacOS or Windows, and find a easy to use programming tool/language for beginners. Flesh out the game you want to make in that, learning the basics of programming and fleshing out your game idea. Then come back and research Amiga tools and techniques, and go from there.

Most of the coders here likely taught themselves when things were a lot more limited in terms of available knowledge, and tools were a lot more primitive.
copse is offline  
Old 02 June 2015, 08:59   #159
saimon69
Bedroom musician

 
Join Date: Apr 2014
Location: los angeles,ca
Posts: 699
@copse

Most of the coders here also taught themselves to code in their teen years or early twenties, while the actual scene is mostly composed of people over 30, and some of the elasticity required to learn fast is partially gone; so having easier to follow tutorials can help to put on track; plus don't forget that, unlike on the 8-bit machines, most amiga users were more consumers of software rather than producers, due to the more complex operating system in my opinion, and for those the leap is even harder;
saimon69 is offline  
Old 02 June 2015, 12:19   #160
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
i think what would really benefit Amiga is a better programming language, aimed at games programming. Simpler machines are already in a games-type environment as soon as you switch them on - i don't mean BASIC i mean you have complete control over everything, with the Amiga you have this multitasking OS to deal with. A lot of early games did just treat the Amiga like a C64 and wrote all over memory wherever they liked and that is the cause of a lot of incompatibility problems. Also loading files from disk requires either using the OS or writing your own track loader. Doing it properly is hard.

i would like some programming environment that gives you features like bobs, sprites, blitting &c, we are continuously re-inventing the wheel just to do these basic functions. Something like AMOS but which doesn't suck. Obviously there is Blitz, i don't know what that's like to program in. Also Amiga E, and likewise, i don't know much about it. but i sometimes think about this sort of thing, about a programming language tailored to the Amiga game developer's needs that is also as fast as possible, giving low level access as well as high level features.
Mrs Beanbag is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
What is the technically most impressive A500 game? mc68060 Amiga scene 67 03 June 2015 23:32
The Tales of Grupp - Another impressive homebrew ZX Spectrum title! Neil79 Retrogaming General Discussion 3 24 February 2015 20:19
New One Of "Homebrew" 68k Amiga Magazine Idea fishyfish Retrogaming General Discussion 6 16 April 2013 09:57
Impressive and Amazing PD Software! Any thoughts? hamster Retrogaming General Discussion 0 18 July 2004 02:42

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 04:37.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.33565 seconds with 12 queries